ERCEMAPI 2011

V Escola Regional de Informtica

Cear Maranho Piau
Teresina, 07 e 08 de novembro de 2011

LIVRO TEXTO DOS MINICURSOS
Edio
Sociedade Brasileira de Computao
Organizadores
Andr Macdo Santana
Pedro de Alcntara dos Santos Neto
Raimundo Santos Moura
Promoo
Sociedade Brasileira de Computao
Patrocnio

Realizao
Universidade Federal do Piau
Instituto Federal de Educao, Cincia e Tecnologia do Piau
Apoio
Fundao de Amparo a Pesquisa do Estado do Piau

Copyright Sociedade Brasileira de Computao
Todos os direitos reservados

i

































Escola Regional de Informtica Cear, Maranho, Piau
(2011: Teresina, PI)

Escola Regional de Informtica Cear, Maranho, Piau: Livro texto
dos minicursos, 07 e 08 de novembro de 2011. [livro eletrnico] /
organizadores, Andr Macdo Santana, Pedro de Alcntara dos Santos Neto,
Raimundo Santos Moura. Teresina: Sociedade Brasileira de Computao
SBC, 2011.
200p. : il. ; livro eletrnico.

Realizao: Universidade Federal do Piau - UFPI.
Promoo: Sociedade Brasileira de Computao SBC.
ISBN 978-85-7669-258-4.



1. Computao; Cincia da Computao; I. Santana, Andr Macdo.
II. Santos Neto, Pedro de Alcntara dos. III. Moura, Raimundo Santos
IV. Ttulo.

CDD 004.1
ii

ERCEMAPI 2011


PREFCIO

Em 2007, quando da primeira edio da Escola Regional de Informtica Cear -
Maranho - Piau (ERCEMAPI) houve muitos questionamentos sobre a continuidade
dessa ideia, que foi inicialmente encabeada por um grupo cearense. Sua segunda
edio (2008), no estado do Maranho, foi bastante tmida e os questionamentos
continuaram. Em 2009, tivemos a consolidao do evento, com uma participao
macia de estudantes do Piau, Cear e Maranho, alm de estudantes de outros
estados. O evento foi pela primeira vez organizado fora das capitais dos estados e
mostrou que a ideia de sua realizao era totalmente vlida e bem aceita pela
comunidade acadmica dos estados pertencentes ento regional Nordeste 3.
Agora em 2011, na sua quinta edio, o Piau teve a honra de sediar o evento
mais uma vez. Houve uma inverso na ordem de organizao, entre Piau e Maranho,
pedido dos representantes maranhenses. A responsabilidade de organizao neste
ano era, maior ainda, dado o sucesso da edio anterior realizada em Sobral-CE.
No entanto, mais uma vez conseguimos superar todas as expectativas e realizar
um evento memorvel, que s estimula a sua ampliao. Houve cerca de 500
participantes nesta edio, um recorde muito difcil de ser batido! Geramos um grande
problema aos nossos colegas maranhenses, que tero que trabalhar bastante para
tentar manter o ritmo crescente do evento. Certamente teremos a dedicao dos
nossos vizinho nessa tarefa, alm do nosso apoio incondicional ao que for necessrio
para tal realizao.
O grande sucesso da edio 2011 deveu-se realizao conjunta do evento
com um evento tradicional no estado, o Simpsio Piauiense de Informtica (InfoPI),
bem como a realizao da Escola de Microeletrnica do Piau e da Escola de Sistemas
Embarcados do Piua. Foi uma avalanche de conhecimento concentrada em uma
semana inteira de palestras, minicursos e apresentaes de trabalho.

iii
O objetivo inicial do evento, quando criado em 2007, era de aproximar os
estados vizinhos nas atividades de ensino e pesquisa. Neste ano, pudemos notar que o
objetivo inicial foi alcanado. Atualmente existem orientaes de trabalhos de
mestrado em conjunto, participao em bancas e desenvolvimento de artigos. Tudo
isso fruto da aproximao propiciada por esse evento, que j faz parte do calendrio
acadmico dos trs estados. Sua fora tanta que, mesmo com a criao de uma
regional da SBC especfica para o estado do Cear, continuaremos juntos nas prximas
edies do ERCEMAPI.
com esse esprito que gostaramos de expressar nosso agradecimento a todos
os que contriburam para tornar a ERCEMAPI um evento de tanto sucesso. Prximo
ano estaremos na "terra das palmeiras para fincar a bandeira do ERCEMAPI em
definitivo tambm nesse estado. Que venha a edio de 2012!

Teresina, novembro de 2011

Andr Macdo Santana
Pedro de Alcntara dos Santos Neto
Raimundo Santos Moura













iv

ERCEMAPI 2011

V Escola Regional de Informtica Cear Maranho Piau

COMISSO ORGANIZADORA

Coordenador Geral: Raimundo Santos Moura

Coordenao do Comit de Programa: Andr Macdo Santana


Comisso Cientfica: Andr Castelo Branco Soares
Erick Baptista Passos
Ivan Saraiva Silva
Comisso Financeira: Fabio de Jesus Lima Gomes
Kelson Rmulo Teixeira Aires

Comisso de Marketing e Divulgao: Adalton de Sena Almeida
Harilton da Silva Arajo
Josel Martins
Pedro de Alcntara dos Santos Neto
Vinicius Ponte Machado

Comisso de Infra-Estrutura: Eduilson Lvio Neves da Costa Carneiro
Rodrigo de Melo Sousa Veras
v

ERCEMAPI 2011

SUMRIO

Captulo 01 Linhas de produto de software: Uma tendncia da indstria
Airton Silva (UFPE), Paulo Anselmo (UFPE), Vinicius Garcia (UFPE) e Patrcia Muniz (RISE)

07
Captulo 02 Planejamento de capacidade de sistemas atravs de Cadeias de Markov
Rubens de Souza Matos Jnior (UFPE), Carlos Julian Arajo (UFPE), Franscico de Souza
(UFPI) e Paulo Maciel (UFPE)

32
Captulo 03 Computao autnomica aplicada a segurana de redes
Ariel Teles (UFMA), Francisco Jos Silva (UFMA) e Zair Abdelouahab (UFMA)

54
Captulo 04 Linked Data: da Web de documentos para a web de dados
Bernadette Lscio (UFPE), Danusa Ribeiro Bezerra da Cunha (UFCE) e Damires Sousa (IFPB)

79
Captulo 05 Desenvolvimento de Aplicaes para Plataforma Google Android
Fabio de Jesus Lima Gomes (IFPI), Manoel Taenan (IFPI) e Rafael Lins (IFPI)

100
Captulo 06 Desenvolvendo aplicaes multi-tenancy para computao em nuvem
Josino Neto (UFPE), Vinicius Garcia (UFPE) e Wilton Oliveira Ferreira (UFPE)

124
Captulo 07 Introduo a agentes autnomos e sistemas multiagentes
Samy S (UFCE), Joo Alcntara (UFCE) e Marcos de Oliveira (UFCE)

141
Captulo 08 Desevolvimento para dispositivos mveis que utilizar a plataforma iOS
Ricardo Freitas (UFPI), Roniel Soares (UFPI), Jos Almi Soares Filho (UFPI),
Kelson Aires (UFPI), Andr Soares (UFPI), Vinicius Machado (UFPI), Laurindo Neto (UFPI)

166
Captulo 09 Desenvolvimento de aplicaes mveis utilizando a linguagem declarativa QML
Ricardo Erikson (UFAM), Adriano Gil (UFAM), Paulo Mendona (UFAM),
Ccero Costa Filho (UFAM) e Vicente Lucena (UFAM)

191
Captulo 10 Tcnicas de Processamento de imagens em diagnstico auxiliado por
computador
Rodrigo Veras (UFPI), Ilis Paula Jr (UFCE) e Ftima Medeiros (UFCE)

216


vi
Captulo
1
Linhas de Produtos de Software: Uma tendncia
da indstria
Francisco Airton Pereira da Silva, Paulo Anselmo da Mota Silveira Neto,
Vinicius Cardoso Garcia e Patrcia Fontinele Muniz
Abstract
Over the past few years a new approach to software reuse has gained attention both by in-
dustry and academia. This approach is known as software product line development wich
is based upon the systematic reuse of software artifacts, through exploiting commonalities
and managing variabilities among products, that are established under a common archi-
tecture. This concept of product lines have been used by the manufacturing industry for
a long time to reduce costs and increase productivity. However, product line practice in
the software industry is a relatively new concept. Studies have shown that organizations
can yield remarkable improvements mainly in productivity by applying this approach. In
this context, this chapter presents some of the most important aspects related to software
product lines, such as variability, development processes and nally presents some tools
to support Software Product Line (SPL).
Resumo
Ao longo dos ltimos anos uma nova abordagem de reuso de software tem ganhado aten-
o tanto pela indstria quanto pela academia. Esta abordagem conhecida como Li-
nhas de Produtos de Software na qual baseada na reutilizao sistemtica de artefatos
de software, atravs da explorao de pontos comuns e a gesto de variabilidade entre os
produtos, que so estabelecidos sob uma mesma arquitetura. Este conceito de linhas de
produtos tem sido utilizado pela indstria de manufatura a anos para reduzir custos e au-
mentar a produtividade. No entanto esta prtica possui um conceito relativamente novo
na indstria de software. Estudos tm demonstrado que as organizaes tm apresentado
melhorias principalmente na produtividade aplicando esta abordagem. Neste contexto,
este trabalho apresenta alguns dos aspectos mais importantes sobre linhas de produtos de
software, tais como variabilidade, processos de desenvolvimento e nalmente mostrando
algumas ferramentas de apoio a Linhas de Produtos de Software (LPS).
7
1.1. INTRODUO
A maneira que os bens de consumo so produzidos mudou signicativamente no decorrer
do tempo. Anteriormente mercadorias eram especicas para clientes individuais. Cada
vez mais, o nmero de pessoas que poderiam ter recursos para comprar vrios tipos de
produto foi aumentando. No domnio dos automveis, isso levou inveno por Henry
Ford da linha de produo, o que permitiu a produo para um mercado de massa muito
mais barata do que a criao de cada produto em uma base artesanal. No entanto, a linha
de produo reduziu as possibilidades de diversicao.
A grosso modo, ambos os tipos de produtos, individual e os produzidos em massa
tambm podem ser identicados no domnio de software: eles so denominados como
software individual e software padro. Geralmente, cada um destes tipos de produtos tem
suas desvantagens. Produtos de software individuais so bastante caros pois exigem um
maior esforo desenvolvendo especidades de um nico produto, enquanto produtos de
software padro (sem muita especicidade) existe a falta de diversicao suciente para
atender bem s expectativas de muitos clientes diferentes.
No incio os clientes estavam satisfeitos com os produtos padronizados em massa
por um tempo, mas nem todas as pessoas queriam o mesmo tipo de carro para qualquer
nalidade. Certos carros so usados para viajar por uma nica pessoa, outros por grandes
famlias por exemplo. Assim, a indstria foi confrontada com uma crescente demanda
por produtos individualizados. Este foi o incio da chamada customizao em massa, o
que signicava atender s exigncias dos clientes dando-lhes o que eles queriam.
Para o cliente a customizao em massa signica a capacidade de ter um produto
individualizado, no entanto para a indstria signica maiores investimentos em tecnologia
que elevam os preos de produtos individualizados e / ou menores margens de lucro para
a empresa. Ambos os efeitos so indesejveis. Assim, muitas empresas, especialmente
na indstria automobilstica, comearam a apresentar plataformas comuns para os seus
diferentes tipos de carros planejando de antemo quais peas seriam usadas em vrios
tipos de carros diferentes.
Ao longo do tempo a plataforma foi sendo trabalhada a m de se tornar cada
vez mais adaptvel a novos componentes. As partes compreendendo a plataforma eram
geralmente mais caras em termos do projeto e os custos de preparao de fabricao.
Porm esta estratgia levou a uma reduo no custo de produo para um tipo de carro
particular [21].
A indstria de automveis passou por esta transformao na forma de produzir
seus produtos e a indstria de software tambm necessita atender ao mesmo requisito de
individualidade e cada vez mais produo em massa. O mercado de desenvolvimento de
software precisa construir os produtos de software com melhor qualidade, reduo de cus-
tos, adaptao rpida s mudanas, e menor tempo de colocao no mercado atendendo s
necessidades dos clientes. Visando estas expectativas vrios esforos em criar processos
e arquituras de sistemas tem sido realizadas ao longo dos anos [16].
Seguindo por este caminho uma nova abordagem para reutilizao de software
tem ganhado considervel ateno tanto pela indstria quanto pela academia. Esta abor-
dagem conhecida como Linha de Produtos de Software (LPS) onde a idia bsica o
8
trabalho sobre um grupo de sistemas compartilhando um conjunto comum e gerenciado
de funcionalidades (features) que satisfazem necessidades especcas de um segmento, e
desenvolvidos a partir de umaglomerado comumde artefatos base e de forma previamente
planejada. Em outras palavras LPS faz uso da reusabilidade para construir sistemas com
menos esforo desde que estes pertenam a uma mesma famlia, ou seja, que possuam
pontos em comum [17].
Este captulo est organizado como segue: na seo 1.2 ser apresentada uma vi-
so geral sobre as peculiaridades sobre Linhas de Produtos de Software, incluindo idias
comparativas entre estas metodologias e o reuso de software tradicional. Na seo 1.3
como as variantes de um produto podem ser gerenciadas. Na seo 1.4 atividades exer-
cidas no desenvolvimento de LPS, mostrando algumas ferramentas. Finalmente na seo
1.5 so apresentadas as concluses.
1.2. VISO GERAL SOBRE LINHAS DE PRODUTOS DE SOFTWARE
Os artefatos mencionados na seo anterior devem ser reutilizados de uma forma consis-
tente e sistemtica, a m de construir aplicativos robustos em LPS. Artefatos reutilizveis
abrangem todos os tipos de artefatos de desenvolvimento de software, tais como modelos
de requisitos, modelos de arquitetura, componentes de software e planos de teste.
A experincia de projetos que fazem uso de reutilizao na dcada de 1990 mos-
traram que, sem planejamento adequado, os custos do projeto com reutilizao pode ser
maior do que para desenvolver os artefatos a partir do zero. Assim, fundamental planejar
com antecedncia os produtos para os quais a reutilizao ser aplicada, juntamente com
as features que caracterizam estes produtos. O planejamento para reutilizao continua
durante todo o processo de desenvolvimento [21].
Para facilitar a customizao em massa a plataforma deve fornecer os meios para
satisfazer as necessidades dos diferentes stakeholders. Para este propsito, o conceito
de variabilidade foi criado, para explorar as caractersticas que variam em relao aos
diversos produtos. Como conseqncia de aplicar este conceito, os artefatos que podem
serem diferentes nas aplicaes da linha de produtos so modelados usando variabilidade
[21].
1.2.1. Processos de Desenvolvimento
O paradigma de linha de produtos de software dividido em dois processos, a saber:
1. Engenharia de Domnio: Este processo responsvel por estabelecer a plataforma
de reutilizao e, assim denir comunalidade e a variabilidade da linha de produtos.
A plataforma consiste em todos as tipos de artefatos de software (requisitos, design,
testes, etc.) tambm chamados de ativos base.
2. Engenharia de Aplicao: Este processo responsvel por derivar aplicaes con-
cretas a partir da plataforma estabelecida na engenharia de domnio. Ela explora a
variabilidade da linha de produtos e assegura sua correta instanciao de acordo
com as necessidades especcas das aplicaes nais.
9
Figura 1.1. Dois ciclos de vida que separam engenharia de domnio e aplicao.
A vantagem dessa diviso que h uma separao de objetivos, para construir uma
plataforma robusta e para construir aplicaes especcas em um curto espao de tempo.
Para ser ecaz, os dois processos devem interagir de uma maneira que seja benca para
ambos.
A Figura 1.1 mostra como estes processos interagem entre si e qual o resultado dos
mesmos atravs de um uxo de informaes. Tanto na engenharia de domnio quanto na
engenharia de aplicao so realizadas atividades de anlise, arquitetura, implementao
e testes para ao nal serem gerados os produtos.
1.2.2. Linha de Produtos de Software e Reuso de Software Tradicional
Desenvolvimento de uma LPS envolve "reuso"e a primeira vista este desenvolvimento
pode parecer apenas um reuso de software tradicional. No entanto desenvolvimento de
uma linha de produtos de software muito mais elaborado do que a reutilizao de soft-
ware tradicional. No reuso de software tradicional, as organizaes possuem repositrios
onde a sada de praticamente todo o esforo de desenvolvimento armazenado. Este repo-
sitrio normalmente contm alguma biblioteca de reutilizao de componentes, mdulos
e algoritmos que desenvolvedores so incentivados a usar. O problema com este tipo de
reutilizao que, geralmente, leva mais tempo para encontrar a funcionalidade desejada
e adapt-la aplicao atual do que para constru-la novamente [7].
Este tipo de reutilizao ad hoc no o que caracteriza o desenvolvimento de
linhas de produtos de software. Em desenvolvimento de linhas de produtos o reuso
planejado, automatizado e sistemtico [20]. O "repositrio de reuso"de uma linha de
10
produtos de software conhecido como ativos base. Estes elementos incluem todos os
artefatos que so os mais caros para desenvolver como modelos de domnio, requisitos,
arquitetura, componentes, casos de teste, etc.
Alm disso, esses ativos so do incio do desenvolvido a m de serem reutilizados
em vrios produtos. Isto signica que a customizao de ativos para o produto atual, nor-
malmente no inclue nenhum cdigo novo como ocorreria em abordagens tradicionais.
Ao invs disto ocorre uma instanciao do produto, utilizando mecanismos de variabili-
dade incorporadas aos ativos base.
Outra abordagem para reutilizao de software que se assemelha a de desenvol-
vimento de software em linhas de produtos conhecido como a abordagem "clone and
own"[20]. Os produtos desenvolvidos por esta abordagem tem um foco no produto indivi-
dual, no ocorre um foco na famlia de produtos de software, e portanto, no implementa
os mecanismos de variabilidade que caracterizam o desenvolvimento da famlia de pro-
dutos.
Portanto quando um projeto novo iniciado por esta abordagem, a equipe de de-
senvolvimento tenta encontrar umoutro produto dentro da organizao que se assemelha o
produto atual, tanto quanto possvel. Eles, ento, copiam tudo o que podem a partir desse
projeto, modicam e adicionam o que necessario para lanar o novo produto. Esta abor-
dagem pode render uma economia considervel em comparao com desenvolvimento de
todos os produtos a partir do zero. No entanto, ao comparar o "clone and own"com a
abordagem de desenvolvimento de linha de produtos, o "clone and own"apresenta algu-
mas desvantagens principais:
1. No desenvolvimento de linha de produtos todos os artefatos de maiores custos do
projeto so reutilizados, no apenas o cdigo que o foco principal da abordagem
"clone and own".
2. No desenvolvimento de linha de produtos todos os ativos base so desenvolvidos
tendo em mente a idia de reutilizao e variabilidade. Na abordagem "clone and
own", tudo desenvolvido com foco no produto individual, onde os recursos no
sero gastos no desenvolvimento de mecanismos de variabilidade que no sero
usados por este produto. Isto implica que o "clone"exigir um esforo consider-
vel de customizao para atender os requisitos do novo produto comparado a outro
dentro de uma linha de produtos. Os ativos base de uma linha de produtos pro-
vavelmente no iro precisar de um alto grau de customizao para atender aos
requisitos de novos produtos, mas sim uma instanciao de mecanismos integrados
de variabilidade anteriormente construdos.
3. Quando "clonamos"um produto j existente, para criar um novo produto, as liga-
es entre estes projetos so inexistentes e futuramente ocorrer manutenes indi-
viduais nos dois produtos. No caso do desenvolvimento de linha de produtos, uma
economia considervel pode ser realizada ao longo do ciclo de vida destes, pois
a manuteno dos ativos base uma responsabilidade compartilhada por todos os
produtos na famlia.
11
1.2.3. Aspectos importantes na adoo de Linhas de Produtos de Software
A adoo de linhas de produtos de software diferente em alguns sentidos em relao a
adopo de outros tipos de tecnologias e processos. Sua adoo requer bastante tempo,
principalmente em estgios iniciais [17]. Isso envolve a mudana na forma de desenvolvi-
mento de sistemas que possui a idia de sistema nico para o desenvolvimento de vrios
produtos a partir de uma plataforma [19].
A adoo envolve ter uma base de ativos base, processos de suporte, e estruturas
organizacionais; desenvolver produtos a partir da base de ativos de uma forma que sejam
atingidos objetivos de negcio; e instituir mecanismos para melhorar e extender o esforo
de produo de software, desde que faa sentido. No entanto, dependendo do cenrio,
atingir as metas de adoo pode tornar-se uma atividade complexa.
A m de evitar complexidades adicionais durante a fase de adoo, Gary [8] argu-
menta que uma organizao que pretende adotar uma abordagem de linha de produto deve
ter objetivos claros em mente. Para atingir seus objetivos, a organizao seleciona um ou
mais estratgias de adoo que especicam como ele sero abraadas as prticas de linhas
de produtos. Em seguida, um plano de adoo mostra em detalhes que atividades devem
ser realizadas para implementar essas estratgias.
Neste sentido, todo o conceito de adoo de linha de produtos se torna muito pes-
soal para a organizao, o contexto especco parece desempenhar um papel signicativo
na deciso de adoo [8]. Portanto, a transferncia deve ser sistematicamente e planejada.
1.2.4. Vantagens em Linhas de Produtos de Software
Teorias relacionadas a linhas de produtos de software pode gerar diversos benefcios clas-
sicados em trs tipos: benefcios organizacionais, os benefcios de engenharia de soft-
ware e os benefcios de negcio.
Os benefcios organizacionais agrupam vantagens como uma melhor compreen-
so do domnio, a maior facilidade de treinar pessoas, um produto de maior qualidade e
consequentemente conana do cliente.
Os benefcios da engenharia de software incluem vantagens como a reutilizao
de requisitos e seus componentes, uma melhor anlise de requisitos, uma outra viso
sobre os requisitos para o cliente, controle de qualidade de software, estabelecimento de
padres de programao.
E por ltimo mas no menos importante, benefcios comerciais dizem respeito
reduo de manu-teno e custos de teste (graas reutilizao entre vrios produtos
semelhantes). Alm disso, as linhas de produtos geram uma melhor ecincia nos pro-
cessos e a possibilidade de aumentar o oramento e melhorar o planejamento do tempo
por ter maior controle dos componentes que fazem parte do produto nal. Uma descrio
detalhada dos benefcios pode ser encontrada na seo "benefcios e custos da linha de
produtos"em [6].
Vrias estatsticas concretas so apresentados para ilustrar as melhorias de custos,
tempo de mercado e produtividade [15].
12
1. Nokia capaz de produzir 25-30 modelos diferentes de celular por ano por causa
da abordagem de linha de produtos.
2. Cummins, Inc., foi capaz de reduzir o tempo que leva para produzir o software de
um motor diesel de cerca de um ano para cerca de uma semana.
3. Motorola observou uma melhoria de produtividade de 400% em uma famlia de
determinado tipo de celular.
4. Hewlett-Packard reportou uma reduo no time to market por um fator de sete e
um aumento na produtividade por um fator de seis, em uma famlia de sistemas de
impressoras.
1.2.5. Desvantagens em Linhas de Produtos de Software
Realizar uma mudana de um modo original de desenvolvimento de software em uma
organizao do ponto de vista de um produto nico para uma abordagem com linha de
produtos envolve uma mudana fundamental para a organizao e para as mentalidades
que pode trazer o que chamamos de resistncia a mudanas.
Outro problema est relacionado ao fato de poucos engenheiros de software te-
rem uma viso global sobre toda a arquitetura de linha de produtos. Nos estudos de caso
apresentados em vrias partes do livro [11], ele enfatiza a necessidade de um especia-
lista na linha de produtos que sabe perfeitamente como funciona o domnio da aplicao,
que tem responsabilidade suciente, autoridade, experincia dentro da empresa, que tem
motivao e compreenso sobre teorias em linhas de produtos de software.
Algumas diculdades podem aparecer, quando uma deciso deve ser tomada para
mesclar ou no um novo produto com a linha de produtos. A evoluo do domnio requer
cautela para xar o alcance da linha de produtos. De fato, um escopo muito amplo torna
a manuteno de ativos base demasiadamente complexa para haver reutilizao de forma
ecaz, e umescopo muito limitado no justica o custo de desenvolvimento e manuteno
do ncleo dos ativos base.
Projetar arquiteturas de linha de produto muitas vezes se torna difcil, devido
falta de diretrizes, representaes maduras de como validar arquiteturas de referncia e
ferramentas integradas para desenvolver e explorar as linhas de produtos de software.
Dado as diculdades apresentadas, Sholom [11] lista alguns problemas diferentes com
base em um questionrio, ressaltando que a resistncia organizacional e de investimento
so os mais crticos dentre todos os problemas (Tabela 1.1).
Quando comparamos o desenvolvimento tradicional de software com o desenvol-
vimento a partir de linhas de produtos (Figure 1.2), podemos salientar que neste ltimo
precisa-se de uma gesto a longo prazo, porque os benefcios visveis no so imediatos.
De fato, nos primeiros estgios em LPS necessrio um investimento inicial considervel
onde o ponto de equilbrio de investimento/retorno seria alcanado geralmente a mdio
prazo. Um nmero suciente de produtos devem ser desenvolvidos a m de apreciar as
vantagens reais .
13
Tabela 1.1. Riscos na adoo de LPS [11]
Risco Porcentagem
Resistencia organizacional 52%
Resistncia da gesto 36%
Resistncia dos desenvolvedores 32%
Preocupaes com grandes investimentos 45%
Falta de pessoal devidamente treinado 29%
Incapacidade de medir o impacto 19%
Preocupao com o tempo de um projeto 18%
Figura 1.2. Comparao de custos entre abordagem tradicional e LPS [11]
1.3. VARIABILIDADE
O conceito de variabilidade est relacionado s possibilidades de mudar ou personalizar
um sistema. A Figura 1.3 ilustra como a variabilidade de um sistema de software limi-
tada durante todo o projeto de construo do mesmo. No incio a quantidade de sistemas
possveis grande pois as restries so mnimas. Durante a execuo do projeto na cons-
truo do sistema as possibilidades diminuem, at que nalmente em tempo de execuo
existe exatamente um sistema apenas. Em cada etapa do desenvolvimento, decises de
design so feitas. Cada deciso restringe o nmero de possveis sistemas
Com a abordagem de LPS as variabilidades so modeladas na arquitectura de
referncia da LPS (atravs da representao dos Pontos de Variabilidade e Variantes res-
pectivos) e resolvidas antes da instalao dos produtos.
Um Ponto de Variabilidade corresponde a um aspecto de variao funcional num
elemento de software base. O ponto de variabilidade dene o conjunto de possveis
variantes, o mecanismo de variabilidade a utilizar para os instanciar e o tempo de
ativao dos variantes, e.g. instanciao da arquitectura de software do produto,
tempo de compilao, execuo.
14
Um Variante corresponde a uma opo do conjunto de possveis instncias de va-
riao que um ponto de variabilidade poder originar.
Figura 1.3. Quantidade de produtos possveis
Em geral h sempre um certo grau de variabilidade difcil de manter em LPS.
Reusabilidade e exibilidade tm sido a fora motriz por trs do desenvolvimento de
tcnicas como orientao a objetos, frameworks orientados a objeto e LPS.
Os Pontos de Variabilidade podem ser apresentados em vrios nveis de abstrao
[4]:
Descrio da Arquitetura. Tipicamente, o sistema descrito usando uma combi-
nao de documentos de alto nvel de design, linguagens de descrio de arquitetura
e documentao textual.
Documentao por Diagramas. A este nvel o sistema pode ser descrito usando
vrias notaes UML.
Cdigo-Fonte. A este nvel, uma descrio completa na forma de cdigo-fonte
criado.
Cdigo Compilado. O cdigo fonte convertido para o cdigo compilado usando
um compilador. Os resultados desta compilao pode ser inuenciada por meio de
directivas de pr-processamento para ento o resultaodo ser combinado.
Cdigo Ligado. Durante a fase de ligao, os resultados da fase de compilao
so combinados. Isto pode ser feito estaticamente (em tempo de compilao) ou
dinamicamente (em tempo de execuo).
15
Cdigo de Execuo. Durante a execuo, o sistema j construdo iniciado e
congurado. Ao contrrio das representaes anteriores, o sistema de execuo
dinmico e muda o tempo todo.
1.3.1. Gerenciando Variabilidades
Ao desenvolver uma LPS, o objetivo nal torn-la exvel o suciente para atender s
novas exigncias. Os pontos de variabilidade mais importantes precisam ser identicados
antecipadamente, a m de alcanar este objetivo. Acontece que muitas vezes muito
difcil de adaptar uma arquitetura existente para suportar um certo ponto de variabilidade.
Segundo Muhammad [4] a gesto da variabilidade consiste nas seguintes tarefas:
Identicando Variabilidades. Na fase inicial de desenvolvimento de uma LPS,
os desenvolvedores so confrontadas com uma srie de requisitos. Eles devem de
alguma forma trabalhar sobre estes requisitos formando uma especicao mais
adequada para a LPS. O objetivo deste processo no chegar a um especicao
completa da LPS, mas sim identicar a diferena entre os produtos (ou seja, onde
as "coisas"tendem a variar) e quais caractersticas so compartilhadas por todos os
produtos. Feature Models apresentam uma excelente forma de representar variabi-
lidades.
Introduzindo a variabilidade no sistema. Uma vez que a variabilidade foi iden-
ticada, o sistema deve ser projetado de tal forma que ela possa ser introduzida.
Existe uma ampla gama de mecanismos e tcnicas para esta tarefa. O mecanismo
escolhido depende do nvel em que a variabilidade introduzida, o tempo que o
sistema ser ligado a um variante particular e a forma como novas variantes (se
houver) sero adicionadas ao sistema.
Agrupando as variantes. Esta fase resulta em um conjunto de variantes associadas
a um ponto de variabilidade. A coleo de variantes pode ser implcita ou explcita.
No caso da implcita o sistema baseia-se no conhecimento dos desenvolvedores ou
usurios para escolherem variantes adequadas quando assim for necessrio. Uma
coleo explcita, por outro lado, implica que o sistema pode, por si s, decidir
qual variante usar. A coleo pode ser fechada, o que signica que nenhuma nova
variante pode ser adicionada, ou ela pode permanecer aberta para novas adies.
Vinculando o sistema a uma variante. Resulta em um sistema onde um ponto de
variabilidade particular associado a uma de suas variantes. Esta vinculao pode
ser feita internamente ou externamente, a partir da perspectiva de sistemas. Uma
ligao interna implica que o sistema possui a capacidade de vincular uma variante
particular, ao passo que se a ligao realizada externamente, o sistema tem que
contar com outras ferramentas, como ferramentas de gerenciamento de congura-
o para executar a vinculao. Relacionando esta com o agrupamento de variantes,
vemos que a gesto de variabilidade pode ser implcita e externa, implcita e interna,
ou explcita e interna. Aseleo de qual variante usar envolve escolher uma variante
dentre o conjunto de variantes.
16
1.3.2. Feature Model
Comunalidade e variabilidade entre produtos de uma linha pode ser expressa em termos
de features. O conceito de feature foi originalmente apresentado pelo mtodo Feature
Oriented Domain Analysis (FODA). De acordo com este modelo uma feature uma ca-
racterstica do sistema visvel ao usurio nal. Uma feature denida como uma unidade
lgica de comportamento que especicada por um conjunto de requisitos funcionais e
de qualidade. Alm disso, o comportamento deve ser relevante para um ou vrios sta-
keholders de um produto [7].
O conceito de feature simplica o trabalho com os requisitos, porque ele pode
ser usado para agrupar um conjunto de requisitos relacionados. Em outras palavras, as
features so uma forma de abstrair os requisitos. importante perceber que existe uma
relao n-para-n entre features e requisitos.
Por esta relao com os requisitos o conceito de feature pode tambm diminuir a
distncia em termos de comunicao entre o usurio nal e o desenvolvedor. Os usurios
podem reportar defeitos ou requisies de uma nova funcionalidade por meio de features e
desenvolvedores podem ento reinterpretar esta representao transformando-a em aes
a serem aplicadas ao ciclo de vida da construo do produto [7].
Deste modo, medida que reunimos em um grco, as features de um sistema
ns construmos um feature model. O feature model procura apresentar uma viso geral
de alto nvel das principais caractersticas comuns e variveis de uma linha de produtos.
1.3.3. Notao F.O.D.A
O mtodo Feature Oriented Domain Analysis (FODA) foi desenvolvido no Software En-
gineering Institute para representar gracametne o feature model. Sua descrio detalhada
do processo de Anlise de Domnio o fez tornar-se um dos mtodos mais populares na
dcada de 1990. Em particular, FODA fez uma contribuio signicativa para a popula-
ridade atual da anlise orientada a modelo: o uso de vrias vises complementares de um
domnio para transmitir informaes mais completas sobre ele [14].
A modelagem de features de maneira explcita a chave para o mtodo FODA, e
base para muitos dos trabalhos posteriores. FODA se posiciona como parte integrante
da engenharia de domnio a m de facilitar a engenharia de aplicao.
O feature model foi introduzido como parte do mtodo FODA, e representa uma
hierarquia de propriedades de conceitos do domnio. uma das tcnicas mais bem su-
cedidas para facilitar a reutilizao de artefactos de software. O feature model uma
representao hierrquica, que visa captar os relacionamentos estruturais entre as features
de um domnio de aplicao. O modelo tambm representa as features comuns e vari-
veis de instncias de conceitos (por exemplo, sistemas de software) e dependncias entre
as features variveis. Um feature model consiste em um diagrama composto de features
e alguma informao adicional, tais como descries semnticas de cada feature, pontos
variveis, prioridades e regras de dependncia.
No contexto das linhas de produto de software, um feature model representa a
prpria linha de produtos. Uma feature pode ser de um dos seguintes tipos:
17
Obrigatria: A feature tem de estar presente em todos os membros da linha de
produtos.
Opcional: A feature pode ou no estar presente em um membro da linha de produ-
tos.
Alternativa: uma feature que composta de um conjunto de features das quais
se escolhe uma ou mais, devendo-se indicar se necessrio escolher apenas uma
ou se se pode escolher mais que uma. Nestas features necessrio fazer a distino
de alternativas OR, que permite mais do que uma feature, e XOR, que mostra a
excluso mtua.
Uma feature obrigatria representada por uma aresta terminada por um crculo
preenchido a preto. Uma feature opcional representada por uma aresta terminada por um
crculo vazio. As features alternativas so representadas por arestas que esto ligadas e
conectadas por um arco. Se o arco for vazio deve-se escolher apenas uma das alternativas
(XOR), se for preenchido permitido escolher mais de uma alternativa (OR) [23].
Czarnecki [13] prope colocar cardinalidade nas features para poder remover am-
biguidades e representar a informao mais facilmente, sendo as diferentes cardinalidades
assim denidas:
0..1 Pode-se escolher uma ou nenhuma feature do conjunto de sub-features.
1 Exatamente uma feature tem de ser escolhida de um conjunto de sub-features.
0..* Um nmero arbitrrio de features (ou nenhuma) tem de ser selecionado do
conjunto de sub-features.
1..* Pelo menos uma feature tem de ser seleccionada do conjunto de sub-features.
Figura 1.4. e-Shop [22]
A Figura 1.4 mostra uma possvel representao para o modelo de features do
Sistema e-Shop [22].
18
Neste modelo so features obrigatrias Catalog, Payment, GUI e Info, so fea-
tures opcionais Security, Banners, Offers, Search. A feature Security possui um grupo
de subfeatures numa alternativa XOR que indica que apenas uma delas escolhida para
a aplicao. No caso da feature Payment, esta composta por duas sub-features numa
alternativa OR (uma ou as duas podem ser escolhidas).
Note que uma feature lha pode aparecer apenas em um produto se sua feature
superior aparecer. A feature raiz parte de todos os produtos dentro da LPS. Adicional-
mente aos relacionamentos parental entre features, pode ocorrer tambm o que chamamos
de cross-tree entre features, que signica que uma feature pode estar relacionada a outra
s que no em uma relao de parentesco, podendo ser dos seguintes dois tipos:
Requires. Se uma feature A requer a feature B, a incluso de A em um produto
implica na incluso tambm de B. No sistema de exemplo pagamento com carto
de crdito deve implementar uma poltica de segurana alta.
Excludes. Se a feature A exclui a feature B, ambas as features no podem fazer
parte do mesmo produto. No sistema de exemplo o produto que implementar uma
interface GUI mobile no deve incluir suporte a banners.
1.3.4. Conguration Knowledge
O feature model, por si s, apenas representa a modelagem do domnio, mas no repre-
senta o modo como os produtos deste domnio sero gerados a partir dos artefatos da linha
de produtos. O mapeamento entre o feature model e os artefatos de implementao o
que se chama de Conguration Knowledge [12].
Os artefatos de implementao podem estar modelados direto no modelo que re-
presenta o conguration knowledge ou em um modelo a parte, neste caso o conguration
knowledge associar os artefatos de um modelo com as features do feature model.
Quando no esto dentro do conguration knowledge, os artefatos de implemen-
tao encontram-se em um modelo que assume diferentes nomes, dependendo da ferra-
menta utilizada, tais como family model, component model, architecture model, etc.
O mapeamento existente no conguration knowledge essencialmente um con-
junto de regras que denem que artefatos de implementao (classes, arquivos de recur-
sos, etc) entram em cada produto da linha. Tomando o E-Shop 1.4 como exemplo em
um ambiente de desenvolvimento orientado a objetos, uma classe chamada Catalog (que
trata dos produtos disponveis na loja) estaria representada no conguration knowledge
como uma regra que diz se a feature Catalog estiver selecionada em um produto, a classe
entraria nesse produto tambm, essencialmente uma relao de implica (feature implica
em artefato de implementao).
Por trs do processo de gerao de produtos de uma linha de produtos de soft-
ware se encontra uma engine de resoluo de expresses lgica, que verica se todas as
restries presentes no feature model foram respeitadas em cada instncia, e, para cada
seleo de features, verica que artefatos de implementao estaro habilitados na ins-
tncia. Uma vez que todas as vericaes tenham sido realizadas, a sada do processo de
19
gerao de produtos vai ter como resultado, para cada produto, uma lista dos artefatos de
implementao habilitados no produto.
Dependendo da ferramenta utilizada, o usurio pode especicar diretamente na
ferramenta o que ser feito com essa lista, como gerar um projeto individual na IDE
utilizada com uma cpia de cada artefato de implementao, ou invocar um sistema de
empacotamento dos produtos que geraria os executveis nais, permitindo assim uma
maior customizao do processo de gerao.
1.4. ENGENHARIA DE LINHA DE PRODUTOS DE SOFTWARE
1.4.1. Atividades Essenciais em Linha de Produtos de Software
Linhas de Produto de Software combinam trs atividades essenciais e altamente interati-
vas que se misturam prticas de negcios e tecnologia. Em primeiro lugar, atividade de
Core Asset Development onde o objetivo no criar o produto nal imediatamente e sim
visa o desenvolvimento de ativos a serem reutilizados em outras atividades posteriores.
Em segundo lugar, vem a atividade denominada Product Development que parte dos ati-
vos base j desenvolvidos anteriormente reusando-os. Finalmente Management Activity,
que inclui gesto tcnica e organizacional [16]. A Figura 1.5 mostra esta trade de ativida-
des essenciais. Cada crculo giratrio representa uma das atividades essenciais. Todos os
trs so ligados entre si e em movimento perptuo, mostrando que todos os trs so essen-
ciais e esto intimamente ligados, podendo ocorrer em qualquer ordem, e so altamente
iterativos [17].
Figura 1.5. Atividades Essenciais [17]
20
1.4.1.1. Desenvolvimento de Ativos Base
Core Asset Development uma atividade na forma de ciclo de vida que resulta em ativos
base que em conjunto compem a plataforma da linha de produto [16]. O objetivo desta
atividade denir os aspectos comuns e a variabilidade da linha de produtos, e, portanto,
obter artefatos reutilizveis para em seguida possuir uma capacidade de produo maior
[21]. A Figura 1.6 mostra o ncleo desta atividade juntamente com suas sadas e insumos
necessrios.
Figura 1.6. Desenvolvimento de Ativos Base [17]
As setas rotatrias na Figura 1.6 sugerem que no h um momento certo de adici-
onar uma restrio ou novos padres no desenvolvimento e estas entradas afetam direta-
mente as sadas no processo. Em alguns contextos os produtos existentes so a base para
os ativos base em outros estes podem ser desenvolvidos do zero para futuro reuso.
Ativos base incluem, mas no esto limitados arquitetura e sua documentao,
especicaes, componentes de software, ferramentas como geradores de componentes
ou aplicao, modelos de desempenho, cronogramas, oramentos, planos de teste, casos
de teste, planos de trabalho e processo descries [17].
Embora possa ser possvel a criao de ativos base que podem ser utilizados em
todos os produtos sem quaisquer adaptaes, em muitos casos, algumas adaptaes so
necessrias para torn-los mais utilizveis no contexto mais amplo de uma linha de pro-
dutos. Logo, mecanismos de variao dos principais ativos base utilizados ajudam a con-
trolar as adaptaes necessrias e suportar as diferenas entre os produtos de software
[5]. Essas adaptaes devem ser planejadas antes do desenvolvimento e facilitada para a
equipe de desenvolvimento do produto sem colocar em risco as propriedades existentes
dos ativos base.
21
1.4.1.2. Desenvolvimento de Produtos
Na atividade de desenvolvimento de produto, os produtos so desenvolvidos a partir dos
ativos base, com base no plano de produo, para satisfazer as exigncias da linha de
produtos de software. Os insumos essenciais da atividade de desenvolvimento de produto
so requisitos, escopo da linha de produtos, ativos base e o plano de produo [3].
De posse do plano de produo, que detalha como os ativos base sero utilizados
para construir um produto, o engenheiro de software pode montar as partes da linha de
produtos. A Figura 1.7 ilustra o produto atividade de desenvolvimento, juntamente com
suas sadas e fatores contextuais.
Figura 1.7. Desenvolvimento de Produtos [17]
Como na Figura 1.5, as setas de rotao na Figura 1.7 indicam iteraes entre as
partes envovidas. Por exemplo, a existncia e a disponibilidade de um determinado pro-
duto pode assim afetar os requisitos de produtos subseqentes. Como outro exemplo de
construo, um produto que tem em comunalidades previamente no reconhecidas em re-
lao a outro produto da linha vai criar a necessidade de para atualizao dos ativos base e
fornecer uma base para explorar essa comunilidade em futuros produtos [17]. Alm disso,
esta atividade tem a obrigao de dar feedback sobre quaisquer problemas ou decincias
encontradas com os ativos base.
1.4.1.3. Atividade de Gesto
A atividade de Management desempenha um papel vital no sucesso da institucionalizao
da linha dentro de uma organizao porque fornece e coordena a sua infra-estrutura neces-
sria. Esta tarefa envolve atividades essenciais realizadas a nvel tcnico e organizacionais
para apoiar o ciclo de vida do processo [3].
A gesto supervisiona a construo dos ativos base e atividades de desenvolvi-
mento do produto, garantindo que os grupos que constroem os ativos base e os grupos que
22
constroem os produtos esto plenamente envolvidos nas atividades individuais, acompa-
nhando o processo denido para a linha de produtos acompanhando seu progresso [17].
Isto representa no apenas os aspectos tcnicos mas tambm aspectos gerenciais e orga-
nizacionais.
O conjunto de ativos base e plano de como eles so usados para construir os pro-
dutos no nascem sem previamente estudar o ambiente, caracterizar o negcio, portanto
deve existir investimento organizacional. Agesto deve dirigir, controlar e garantir a plena
utilizao dos ativos. Linhas de produtos de software est mais relacionado a prticas de
negcios do que prticas tcnicas [17].
Embora as organizaes sejam diferentes em termos da natureza de seus produtos,
de mercado ou misso, objetivos de negcio, estrutura organizacional, cultura e polticas,
as disciplinas de processo de software, e assim por diante, atividades essenciais aqui dis-
cutidas aplicam-se em qualquer situao, uma vez que representam o nvel mais alto de
generalidade, que envolve os aspectos mais importantes sobre o desenvolvimento emLPS.
Em geral, as organizaes realizam essa diviso de responsabilidades em uma
variedade de maneiras. Algumas organizaes tm equipes dedicadas a cada funo e
outros usam as mesmas pessoas para ambas. Depende da disponibilidade oramentria,
estratgia entre outros aspectos. Na verdade, vlido mencionar que no h atividade
primria, isto , em alguns contextos, os produtos j existentes so quebrados em ativos
base, enquanto que em outros, os ativos base podem ser desenvolvidos para uso futuro
[18].
De acordo com Clements e Northrop [17], em muitos casos, a parte da gesto a
atividade responsvel pelo sucesso ou fracasso do produto nal de uma linha de produtos.
1.4.2. Abordagens de Construo de Linha de Produtos de Software
Segundo Chen [10], existem trs abordagens principais de desenvolvimento em linha de
produtos de software (ver Figura 1.8):
Proativa: Com esta abordagem os ativos base so desenvolvidos primeiro para
futuro produtos. Aqui so considerados todos os produtos a serem gerados previa-
mente fazendo-se um planejamento inicial completo.
Reativa: Nesta abordagemos ativos base j existem, bemcomo uma verso da linha
de produtos, o que acontece a evoluo desta linha realizando-se incrementos na
mesma medida que novos requisitos aparecem.
Extrativa: Com esta abordagem, inicialmente so analizados quais os produtos
j existentes e como eles so estruturados de modo a extrair as comunalidades e
variabilidades destes para ento poder se derivar uma verso inicial da Linha de
Produtos.
Dependendo do grau de planejamento, a abordagem proativa pode ser classicada
em abordagem big bang e abordagem incrementa (ver Figura 1.9).
23
Figura 1.8. Abordagens em LPS
Na estratgia big bang, LPS adotada para os novos produtos de uma s vez,
uma mudana drstica. Primeiramente a engenharia de domnio construda completa-
mente e a plataforma modelada e desenvolvida. Quando os ativos base esto prontos a
engenharia de aplicao inicia e as aplicaes so derivadas da plataforma [21].
Com abordagem incremental, os ativos base so gradualmente desenvolvidas para
suporte aos futuros produtos.
J a abordagem reativa pode ser quebrada em trs subcategories (ver Figura 1.9):
Figura 1.9. Subcategorias de abordagens em LPS [10]
baseado em infra-estrutura,
24
baseado em branch-and-unit, e
baseado em bulk-integration.
A abordagem baseada em infra-estrutura no permite que os produtos individuais
estejam desatualizados em relao aos ativos base comuns a vrios produtos, ou seja, a
plataforma deve manter sempre a integridade emrelao aos produtos, exigindo que novas
caractersticas comuns sejam implementadas primeiro nos ativos base que iro compor os
produtos, em seguida, construindo os produtos.
Tanto o branch-and-unit quanto a abordagem bulk-integration permitem um desa-
linhamento temporrio entre ativos base e os produtos individuais. A diferena entre estas
duas sub-abordagens est na quantidade de produtos que se espera ser lanado antes de
atualizar os ativos base.
A estratgia branch-and-unit exige que novas features comuns sejam reintegradas
nos ativos base imediatamente aps o lanamento do novo produto, enquanto que bulk-
integration permite que novas features comuns serem reintegrados aps o lanamento de
um grupo de produtos.
Estas abordagens no so mutuamente exclusivas. Por exemplo, uma linha de
produtos pode ser adotada por meio de um abordagem proativa e, em seguida, evoluir
atravs de uma abordagem reativa.
1.4.3. Ferramentas
Nesta seo iremos abordar algumas ferramentas relacionadas basicamente modelagem
de feature models.
Aguiar [2] realizou um estudo comparativo sobre as principais ferramentas de
apoio a Linha de Produtos de Software e abaixo seguem algumas caractersticas descriti-
vas deste trabalho.
1.4.3.1. fmp
O fmp (Feature Model Plugin) um plugin gratuito para o Eclipse desenvolvido pelo
Generative Software Development Lab, da University of Waterloo [1]. Ele utiliza como
base o Eclipse Modeling Framework, o que, de acordo com os desenvolvedores, reduziu
signicativamente o esforo de desenvolvimento.
O fmp apenas apresenta suporte modelagem do domnio, atravs de feature mo-
dels. Ele no possui nenhuma funcionalidade de conguration knowledge, nem nada que
permita, dentro do prprio fmp, o mapeamento necessrio entre features e artefatos da
linha de produtos para permitir a gerao dos produtos.
Os modelos gerados pelo feature model so gravados no sistema como um arquivo
XML (do ingls Extensible Markup Language), o que pode permitir que geradores, uti-
lizando XSLT (do ingls Extensible Stylesheet Language Transformation), por exemplo,
possam processar o modelo. Por ser um plugin para o Eclipse e possuir uma API bem
denida, possibilita que outras ferramentas se integrem com o mesmo.
25
Figura 1.10. Interface do fmp
O fmp implementa modelagem de features baseada em cardinalidades [13], ou
seja, permite a denio de cardinalidades de feature e de grupo, atributos de feature,
referncias e anotaes denidas pelo usurio.
Cardinalidades de feature e grupo permitem que sejam especicados o nmero
mnimo e mximo de lhos de uma feature que podem ser selecionados, 0 ou mais, 1 a 4,
por exemplo. Atributos de feature permitem que cada feature possua um valor, que pode
ser uma string, um booleano, um inteiro, etc, o que aumenta a expressividade do modelo.
Anotaes denidas pelo usurio permitem que o usurio adicione novas propriedades
as features, alm das bsicas (nome, cardinalidade, valor), permitindo assim uma maior
customizao do modelo.
Para suportar anotaes denidas pelo usurio, o fmp permite que o usurio al-
tere o meta-modelo do feature model, permitindo, por exemplo, que toda feature tenha
um atributo chamado "quantidade"; ou qualquer coisa que o usurio deseje colocar (Ver
Figura 1.10).
1.4.3.2. XFeature
O XFeature um plugin para o Eclipse desenvolvido pela P&P Software, que uma
empresa que se originou no Institute of Automatic Control of ETH (Swiss Federal Institute
of Technology).
26
O XFeature foi criado para demonstrar um conceito de uma ferramenta para au-
tomatizar o processo de modelagem e congurao de artefatos reusveis de software.
A ferramenta se apresenta como inovadora pela possibilidade de customizao do meta-
modelo da famlia de produtos [9].
O XFeature tem suporte modelagem do domnio, atravs de feature models e no
possui a funcionalidade de conguration knowledge, que permite o mapeamento neces-
srio entre features e artefatos da linha de produtos para permitir a gerao dos produtos.
Originalmente o XFeature foi desenvolvido visando o seu uso em aplicaes espa-
ciais (sistemas de controle embutidos para naves espaciais, por exemplo), porm, no h
nenhuma restrio na maneira que foi desenvolvido que no permita o seu uso em outros
contextos.
Em relao implementao, o XFeature foi implementado baseado na verso 3.3
do Eclipse, ao contrrio do fmp, ele no utilizou o EMF para a denio do meta-modelo
de feature model. O seu editor baseado no GEF (Graphical Editing Framework) do
Eclipse.
O XFeature depende fortemente de XML e de transformaes XSL. Scripts Ant
so utilizados para a vericao e gerao de arquivos de congurao da aplicao, tais
como os que customizam o editor dos modelos.
O processo de criao de modelos no XFeature consideravelmente mais com-
plicado do que nas outras ferramentas. Primeiramente se dene qual ser a congurao
utilizada (FD, FMP, SimpliedICSR ou ICSR). Em seguida, criado o que o XFeature
chama de family model, que o meta-modelo do domnio. Aps a validao do family
model sob a congurao utilizada, o usurio deve clicar em um boto que gera dois
meta-modelos: o de aplicao e o de display. O meta-modelo de aplicao o que ser
utilizado como congurao dos modelos que vo conter as instncias da linha de pro-
duto, e o meta-modelo de display dene quais os elementos visuais que aparecero no
editor. Apesar de ser mais complicado, o XFeature permite que o usurio tenha mais con-
trole sobre como so criados os feature models, uma vez que o usurio no ca preso
nica congurao presente nas outras aplicaes.
Uma vez criados os modelos das instncias da linha de produtos, eles podem ser
validados contra seu meta-modelo, que foi denido pelo usurio anteriormente. Quando
os modelos estiverem validados, eles podem ser utilizados como entrada pra outras ferra-
mentas que possuam a parte de conguration knowledge para gerar os produtos nais.
A Figura 1.11 demonstra a interface do XFeature.
O XFeature s possui uma maneira de visualizar e editar os seus modelos, que
em forma de rvore, como demonstrado na Figura 3, onde encontramos feature raiz, no
topo da rvore, features opcionais, pontilhadas, e features obrigatrias, em caixas ama-
relas, assim como o editor de propriedades de features. O XFeature tambm permite a
denio de restries globais sobre o feature model. O usurio cria um modelo de restri-
es, que passa pelo global constraints compiler, que vai gerar um conjunto de arquivos
XSL que permitem a vericao das restries.
27
Figura 1.11. Interface do Xfeature
1.4.3.3. pure::variants
O pure::variants um plugin para o Eclipse desenvolvido pela pure-systems GmbH,
uma empresa que se originou no Institute Otto-von-Guericke-Universitt Magdeburg e
no Fraunhofer Instituts Rechnerarchitektur und Softwaretechnik. A empresa tem como
objetivo o desenvolvimento de softwares para sistemas embarcados, que se baseia no
desenvolvimento de componentes de software e de ferramentas de desenvolvimento de
software.
O pure::variants foi desenvolvido para suportar o desenvolvimento e a implan-
tao de linhas de produtos e famlias de software. O pure::variants prov suporte no
desenvolvimento durante as atividades de anlise, modelagem, implementao e implan-
tao.
O pure::variants apresenta suporte modelagem do domnio, atravs de feature
models e possui a funcionalidade de conguration knowledge, que permite o mapeamento
necessrio entre features e artefatos da linha de produtos para permitir a gerao dos
produtos.
O pure::variants uma ferramenta comercial, logo, requer licena para uso. Ela
possui uma verso gratuita para testes, que no pode ser usada comercialmente e possui
restries no tamanho dos modelos. sabido que o custo do pure::variants varia muito
dependendo da quantidade de licenas adquiridas. Mas sabe-se que normalmente o preo
de uma licena para uma mquina na verso developer custa em torno de 200 euros por
ms.
O custo tambm varia dependendo de qual verso da ferramenta ser utilizada, a
Professional ou a Enterprise. A verso Enterprise possui controle de verses integrado
(utilizando CVS, por exemplo), permite que o usurio desfaa modicaes no modelo
mesmo aps ele ter sido fechado (no apenas quando ele est aberto, como ocorre na
28
Professional), colaborao on-line e gerenciamento de modelos centralizado.
O pure::variants utiliza uma notao baseada em FODA. Ele possui 3(trs) tipos
de modelos diferentes: o feature model: onde so denidas as caractersticas comuns e
variabilidades da linha de produtos, o family model: a parte do conguration knowledge
onde se encontram os componentes que compem os artefatos da linha de produtos, e o
variant model: que o modelo que dene uma instncia da linha de produtos.
A diviso dos 3 modelos clara e consideravelmente mais intuitiva do que os
inmeros meta-modelos e modelos que o XFeature dene, e a denio das instncias em
arquivos separados facilita a organizao da linha. Alm disso, as mudanas no feature
model so sincronizadas automaticamente com os variant models.
Uma vez criados os variant models, eles podem ser validados para determinar
se cumprem as restries do feature model, que foi denido pelo usurio anteriormente.
Uma vez que estes modelos estejam validados, eles podem ser usados juntamente com
o family model e o feature model para a gerao dos produtos da linha, utilizando os
recursos de gerao do pure::variants.
A Figura 1.12 apresenta o Family Model, onde encontramos componentes (as
caixas marrons), restries (as expresses aps a placa com exclamao), classes (as bolas
verdes com um "C"), aspectos (as bolas laranjas com um "A"), arquivos (o papel dobrado
na borda).
Figura 1.12. Interface de Edio do Family Model do pure::variants
29
1.5. Concluses
Ao longo deste captulo foram analizados diversos conceitos sobre LPS, propiciando ao
leitor uma viso geral sobre o assunto. Alm disto foram mostradas caractersticas sobre
a notao F.O.D.A para construo de feature models bem como o que vem a ser uma
Conguration Knowledge, dentre outros conceitos e princpios.
Foi visto que as organizaes podem obter benefcios de negcio considerveis
em termos de reduo de custos, reduo do tempo de colocao no mercado, aumento
na qualidade do produto, etc, aplicando desenvolvimento de linhas de produto. H, po-
rm, riscos e custos associados adopo das empresas para esta adoo que devem ser
avaliados antes de embarcar em uma iniciativa de reutilizao deste tipo.
Organizaes tm colocado projetos ad hoc em "stand by"a m de deixar livre
recursos para construir ativos base de uma LPS. Isto implica em grandes custos, no etando
existem muitas experincias bem sucedidas deste tipo de empreendimento.
Portanto qualquer organizao que desenvolve produtos como sistemas simples,
que tem bons conhecimentos do domnio do negcio e um nvel razoavelmente elevado de
maturidade do processo, deve, pelo menos, fazer um estudo de viabilidade para observar
se o desenvolvimento de uma LPS pode ser benca para eles.
Referncias
[1] GENERATIVE SOFTWARE DEVELOPMENT GROUP.
http://www.sei.cmu.edu/plp/ web-page acessada em 14 de outubro de 2011.
[2] Rogerio Aguiar. Comparacao entre ferramentas para Linha de Produtos de Soft-
ware. Escola Politecnica de Pernambuco. Departamento de Sistemas e Computacao.
http://dsc.upe.br/ tcc/20081/RogeriomonograaFinal.pdf Acessado em 14 de outu-
bro de 2011.
[3] F. Ahmed, P. Campbell, and M.S. Lagharid. Cognitive factors in software product
line engineering. In Computer Modelling and Simulation, 2009. UKSIM 09. 11th
International Conference on, pages 352 355, march 2009.
[4] Muhammad Ali Babar, Lianping Chen, and Forrest Shull. Managing variability in
software product lines. IEEE Software, 27:8991, 94, 2010.
[5] Felix Bachmann and Paul C Clements. Variability in software product lines. Soft-
ware Engineering Institute Pittsburgh USA, (September):46, 2005.
[6] Len Bass, Paul Clements, and Rick Kazman. Software Architecture in Practice.
Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2 edition, 2003.
[7] Jan Bosch. Design and use of software architectures: adopting and evolving a
product-line approach. ACM Press/Addison-Wesley Publishing Co., New York,
NY, USA, 2000.
[8] Stan Buhne, Gary Chastek, Timo Kakola, Peter Knauber, Linda Northrop, and Stef-
fen Thiel. S.: Exploring the context of product line adoption. In In: Proc. 5th Int.
Workshop on Product Family Engineering, 2003.
30
[9] V Cechticky, A Pasetti, O Rohlik, and W Schaufelberger. Xml-based feature mo-
delling. Software Reuse Methods Techniques and Tools, pages 101114, 2004.
[10] Y Chen, G C Gannod, and J S Collofello. A software product line process simulator.
Software Process: Improvement and Practice, 11(4):385409, 2006.
[11] Sholom Cohen. Product line state of the practice report. Technical report, Software
Engineering Institute, Carnegie Mellon University, 2002.
[12] Krzysztof Czarnecki and Ulrich W. Eisenecker. Generative programming: methods,
tools, and applications. ACM Press/Addison-Wesley Publishing Co., New York,
NY, USA, 2000.
[13] Eisenecker U. Czarnecki K., Helsen S. Staged conguration using feature models,
software product lines. International Conference SPLC, 2004.
[14] K Kang. Feature-oriented domain analysis feasibility study. Technical report, SEI
Technical Report, 1990.
[15] Paul C. Clements Len Baas and Rick Kazman. Software Architecture in Practice.
Second Edition. SEI Series in Software Engineering. Addison-Wesley, 2003.
[16] Schmid K. Linden, F. J. v. d. and E. Rommes. Software Product Lines in Action:The
Best Industrial Practice in Product Line Engineering. Springer-Verlag, 2007.
[17] C.A. Long. Software product lines: practices and patterns [book review]. Software,
IEEE, 19(4):131 132, jul/aug 2002.
[18] John D. McGregor, Linda M. Northrop, Salah Jarrad, and Klaus Pohl. Guest editors
introduction: Initiating software product lines. IEEE Softw., 19:2427, July 2002.
[19] Northrop. Software product line adoption roadmap. SEI Technical Note, 2004.
[20] SEI PLP. Framework for Product Line Practice. http://www.sei.cmu.edu/plp/, 2003.
[21] Klaus Pohl, Gnter Bckle, and Frank J. van der Linden. Software Product Line
Engineering: Foundations, Principles and Techniques. Springer-Verlag New York,
Inc., Secaucus, NJ, USA, 2005.
[22] S. Segura, R.M. Hierons, D. Benavides, and Ruiz-Corte. Automated test data gene-
ration on the analyses of feature models: A metamorphic testing approach. pages
35 44, april 2010.
[23] Arie van Deursen and Paul Klint. Domain-specic language design requires feature
descriptions. Journal of Computing and Information Technology, 10, 2001.
31
Captulo Chapter
12
Planejamento de capacidade de sistemas atravs
de Cadeias de Markov
Rubens Matos, Julian Arajo, Francisco Vieira e Paulo Maciel
Resumo
Neste captulo, pretende-se denir formalmente as cadeias de Markov e demons-
trar como elas podem ser utilizadas no planejamento de capacidade de sistemas compu-
tacionais, auxiliando na garantia de mtricas de desempenho e disponibilidade. Sero
mostradas ferramentas que facilitam a anlise de uma grande variedade de sistemas,
dando destaque a avaliao de redes de computadores e alguns tipos de sistemas dis-
tribudos. Sero apresentados exemplos de avaliao de desempenho com mtricas que
normalmente merecem interesse em diversos ambientes: tempo de resposta, taxa de con-
cluso de tarefas (throughput) e nvel de utilizao de recursos. Esses indicadores esto
diretamente relacionados percepo do desempenho do sistema e podem tambm indi-
car a necessidade de mudanas, como atualizao de componentes ou ajustes na con-
gurao.
2.1.1. Introduo
Em muitas atividades industriais, comerciais e humanas, bem como em fenmenos natu-
rais, est presente um alto grau de incerteza ou risco. Neste sentido, modelos matemticos
probabilsticos tm sido utilizados para fazer previses de valores para ajudar nas tomadas
de decises. Dentre os modelos probabilsticos, um que se destaca conhecido como pro-
cesso de Markov
1
que corresponde a um fenmeno constitudo de estados nitos e discre-
tos, e cuja probabilidade de transio entre tais estados, num intervalo de tempo tambm
discreto, depende apenas do estado corrente e do estado seguinte. Uma sequncia de es-
tados seguindo este processo d-se o nome de cadeia de Markov [20, 2, 4, 16, 22, 25]. Os
modelos Markovianos tm sido usados intensivamente na modelagem de desempenho e
dependabilidade desde a dcada de 50 [9]. As reas onde os modelos de Markov podem
ser aplicados se incluem a Administrao, Economia, Meteorologia, Fsica, Qumica e as
Engenharias.
1
Andrei Andrejevitch Markov (1856-1922) - matemtico russo.
32
Markov obteve os primeiros resultados para estes processos em 1906. Uma gener-
alizao para espaos de estados innitos contveis foi feita por Kolmogorov
2
em 1936.
Cadeias de Markov esto relacionadas ao movimento Browniano e hiptese ergdica,
dois importantes tpicos da Fsica nos primeiros anos do sculo XX, mas a motivao de
Markov para o desenvolvimento da teoria parece ter sido estender a teoria dos grandes
nmeros a eventos dependentes.
Alm do desempenho, aspectos de conabilidade merecem grande ateno para a
garantia da qualidade do servio prestado por um sistema. As cadeias de Markov podem
ser utilizadas para capturar o comportamento do sistema e permitir a descrio e previso
de mtricas de conabilidade, como o tempo mdio para falha, assim como a disponibil-
idade e o downtime anuais. A anlise conjunta dos aspectos de desempenho e conabil-
idade, chamada de anlise de performabilidade, tambm ser tratada neste estudo, uma
vez que muitos sistemas podem permanecer funcionais mesmo nas falhas. Alm disso,
sero tambm apresentados os MRMs (Markov Reward Models) e uma introduo aos
modelos de
Neste captulo, pretende-se mostrar como as cadeias de Markov podem ser uti-
lizadas no planejamento de capacidade de sistemas computacionais, auxiliando na garan-
tia de mtricas de desempenho e disponibilidade almejadas. Sero apresentadas ferramen-
tas que facilitam a anlise de uma grande variedade de sistemas. Como exemplos, sero
utilizados estudos de avaliao de desempenho com mtricas que normalmente merecem
interesse em diversos ambientes, como tempo de resposta, taxa de concluso de tare-
fas (throughput) e nvel de utilizao de recursos. Esses indicadores esto diretamente
relacionados percepo do desempenho do sistema e podem indicar a necessidade de
mudanas, tais como upgrade de componentes ou ajustes na congurao.
2.1.2. Fundamentao terica
Para entender o mecanismo das cadeias de Markov e suas aplicaes, essencial o con-
hecimento de conceitos fundamentais sobre probabilidade, diagramas de transio, ve-
tor de probabilidade, matriz de transio, cadeia ergdica, cadeia regular e regime esta-
cionrio. Estes conceitos sero estudados a seguir.
2.1.2.1. Noes de probabilidade
As noes de experimentao, espao amostral e eventos so fundamentais para o estudo
da teoria da probabilidade. Para este estudo a noo de conjunto fundamental. Os
conjuntos podem ser nitos ou innitos. Os conjuntos innitos podem ser enumerveis
ou no-enumerveis. Um conjunto innito enumervel se for possvel construir uma
bijeo entre ele e o conjunto N dos nmeros naturais.
Umexperimento probabilstico alguma ocorrncia similar ao lanamento de uma
moeda ou de um dado, cujos resultados no so determinsticos. No caso do lanamento
de uma moeda, pode aparecer cara (H) ou coroa (T). No caso do lanamento de um dado
podem aparecer qualquer valor entre 1 e 6.
Espao amostral. Dene-se como espao amostral, associado a um experimento, e
2
Andrey Nilolaevich Kolmogorov (1903 - 1987) - matemtico russo.
33
denota-se por S o conjunto de todos os possveis resultados deste experimento, podendo
ser nito, innito enumervel ou innito no enumervel. Qualquer subconjunto do es-
pao amostral conhecido como evento.
No caso do lanamento de uma moeda, S = {H, T}. No caso do lanamento de
um dado, S ={1, 2, 3, 4, 5, 6}. Se o experimento for o lanamento de 3 moedas ao mesmo
tempo, S ={HHH, THH, HTH, HHT, TTH, THT, TTH, TTT}, onde o elemento TTH
diferente do elemento HTT devido posio das caras e das coroas nos dois elementos.
Como um exemplo mais interessante para usurios da computao, pode-se citar
o espao amostral derivado de um experimento que consiste na observao do nmero de
e-mails chegados ao provedor do NPD (Ncleo de Processamento de Dados) da UFPI em
cada dia. Este espao amostral innito enumervel porque pode-se rotular cada e-mail
que chega com um nico nmero natural, n N, ou seja, S ={n | n N}.
Outro exemplo interessante consiste na medida dos tempos de espera em um ponto
de nibus. Neste caso, S innito e cada resultado um nmero real no negativo, ou
seja, S ={t | t 0}.
A denio de eventos como um subconjuntos de um espao amostral S, per-
mite que as operaes e propriedades tpicas sobre conjuntos tambm possam ser a eles
aplicadas. Entre estas operaes e propriedades se incluem a unio, interseo e comple-
mentao, as leis da comutatividade, da associatividade, da distribuio, da identidade, da
idempotncia, da dominao, da absoro e a lei de de Morgan e estas propriedades po-
dem ser vericadas gracamente atravs dos diagramas de Venn. Alm disso, elas podem
ser extendidas para qualquer nmero de eventos [25].
Clculo de probabilidades. A forma clssica de se calcular a probabilidade de um
evento A, que ser denotada por P(A), com m elementos em um espao amostral nito
S = {a
1
, a
2
, a
n
}, onde os n pontos amostrais a
i
(i = 1, 2, , n) devem ter a mesma
probabilidade de ocorrer, ou seja, eles so equiprovveis, dada pela relao entre a quan-
tidade de casos favorveis ao evento A e a quantidade de elementos do espao amostral S,
apresentada como um nmero real ou em percentagem. Ou seja, P(A) =
m
n
.
Exemplo. Ao se retirar aleatoriamente uma carta de um baralho com 52 cartas, todas elas
tm a mesma probabilidade de ser a carta escolhida. Neste caso, a probabilidade ser
1
52
.
No entanto, a probabilidade de que esta carta seja uma dama
4
52
, uma vez que existem 4
damas em um baralho.
Eventos exclusivos. Dois eventos A e B so ditos mutuamente exclusivos ou disjuntos
se a interseo entre eles for vazia, ou seja, se AB = / 0. Se os eventos A e B forem
mutuamente exclusivos, ento no possvel que ambos ocorram no mesmo experimento.
Diz-se que os eventos de uma lista so mutuamente exclusivos se todas as intersees
entre eles resultarem no evento nulo.
Eventos independentes. Diz-se que dois eventos so estatisticamente independentes se a
ocorrncia de um deles no afetar a ocorrncia do outro. Desta forma, dois lanamentos
seguidos de um mesmo dado constituem dois eventos independentes porque o resultado
do primeiro lanamento no tem qualquer inuncia sobre o resultado do segundo, e vice-
versa.
34
Multiplicao de probabilidades. Sendo A
i
eventos independentes, a probabilidade da
ocorrncia conjunta denida pela regra da multiplicao
P(A
1
.A
2
. A
n
) = P(A
1
A
2
A
n
) = P(A
1
).P(A
2
). .P(A
n
)
Exemplo. No lanamento de duas moedas, a probabilidade de se obter duas caras
1
4
= 0, 25 ou 25%. Este mesmo resultado pode ser obtido utilizando o fato dos dois
lanamentos serem independentes fazendo a multiplicao das probabilidades, ou seja,
P{HH} = P(H).P(H) =
1
2
.
1
2
=
1
4
.
Probabilidade condicionada. Se a condio de independncia no for satisfeita, neces-
srio usar uma frmula mais geral, que envolve as probabilidades condicionadas. Neste
caso, sendo dados dois eventos A e B, a probabilidade de que o evento B ocorra, mas com
a informao adicional de que o evento A j ocorreu, denotada por P(B | A), que se l:
probabilidade de B dado que A j ocorreu.
Exemplo. Seja a retirada ao acaso de uma carta em um baralho de 52 cartas e sejam
os eventos A = A carta de paus e B = A carta um 10. A probabilidade da carta
selecionada ser um 10 de paus
1
52
. Porm, a probabilidade da carta ser um 10, mas
j sabendo antecipadamente que o naipe paus, reduz o espao amostral que passa a
ter somente 13 elementos, em vez de 52. Isto signica que a probabilidade com esta
inormao
1
13
.
De um modo geral, dados dois eventos no independentes A e B, a probabilidade
condicionada de A dado que B j aconteceu dada por
P(A | B) =
P(A.B)
P(B)
=
P(AB)
P(B)
Axiomas da probabilidade. Seja S um espao amostral de um experimento randmico.
Se o evento A consistir do nico ponto da amostra, s, ento P(A) = P(s). A funo de
probabilidade P deve satisfazer aos seguintes axiomas devidos a Kolmogorov.
A1 : 0 P(A) 1, para qualquer evento A S.
A2 : P(S) = 1.
A3 : P(A
1
A
2
A
3
) = P(A
1
) +P(A
2
) +P(A
3
) + desde que todos os eventos
A
i
sejam mutuamente exclusivos.
Exerccios resolvidos.
1. Para qualquer evento A, P(A) = 1P(A).
Prova: Como A e A so eventos mutuamente exclusivos, ento S = AA. Pelo
axioma A2, P(S) = 1 = P(A) +P(A), donde P(A) = 1P(A).
2. Sendo / 0 o evento impossvel, ento P(/ 0) = 0.
Prova: Sabe-se que S = / 0. Logo, P(S) = 1P(S) = 11 = 0, pelo axioma A2.
35
Variveis aleatrias. Dado um experimento e um espao amostral S a ele associado,
denomina-se varivel aleatria funo X que associa a cada elemento s de S um nmero
real X(s). Como pode ser notado, a denio de uma varivel aleatria a mesma
denio de funo, o que pode gerar alguma dvida, notadamente aos iniciantes neste
estudo.
Seja X uma varivel aleatria. Se os valores de X formarem um conjunto nito ou
innito enumervel, ento X denominada varivel aleatria discreta. Se, no entanto,
este conjunto for um intervalo ou uma coleo de intervalos, ela denominada varivel
aleatria contnua.
Funo de probabilidade. Seja X uma varivel aleatria discreta. Sejam x
1
, x
2
, x
3
, ,
seus possveis valores. A cada resultado x
i
associamos um nmero real p(x
i
) =P(X =x
i
),
que a probabilidade do ponto x
i
, de forma que:
1. p(x
i
) 0, para todo x
i
e
2.

i=1
p(x
i
) = 1
Esta funo denominada funo de probabilidade da varivel aleatria X.
Lei da probabilidade total. Sendo A e B dois eventos, sabe-se que a interseo de A com
o espao amostral S igual a A e que a interseo de B com seu complemento B
C
o
conjunto vazio, ou seja,
A = AS e BB
C
= S
substituindo a segunda equao na primeira e aplicando-se o Teorema de de Morgan,
encontra-se
A = A(BB
C
) = (AB) (AB
C
)
No entanto, os eventos AB e AB
C
so mutuamente exclusivos e isto pode ser
vericado atravs dos diagramas de Venn para dois conjuntos A e B. Desta forma, pode-se
utilizar o axioma A3 das probabilidades para encontrar
P(A) = P(AB) +P(AB
C
)
Esta equao alm de facilitar os clculos de probabilidade em muitas situaes
pode ainda ser utilizada para qualquer partio de eventos que sejam mutuamente exclu-
sivos. Neste caso, sendo dados n eventos mutuamente exclusivos, B
i
, i = 1, 2, , n de
um espao amostral S e um evento qualquer A, a equao generalizada dada por
P(A) =
n

i=1
P(AB
i
), n 1
que conhecida como a lei da probabilidade total. Esta equao normalmente apresen-
tada sob a forma de probabilidades condicionais, ou seja,
P(A) =
n

i=1
P(AB
i
) =
n

i=1
P(A | B
i
)P(B
i
)
36
Distribuio das probabilidades. Uma distribuio de probabilidades um modelo
matemtico que relaciona o valor da varivel aleatria com a probabilidade de ocorrn-
cia desse valor no espao amostral ou na populao. Estes pontos, na forma (x
i
, p(x
i
))
SR, podem ser plotados em um grco para se vericar a forma como eles se distribuem
ao londo do espao amostral S. Esta distribuio pode ser discreta ou contnua.
Distribuio discreta de probabilidades. Quando o parmetro que est sendo medido s
pode assumir certos valores, como por exemplo valores inteiros 0, 1, 2, . . . , a distribuio
de probabilidades chamada discreta. Por exemplo, o lanamento de um dado s pode
apresentar os resultados 1, 2, 3, 4, 5 e 6. Portanto a distribuio de suas probabilidades
discreta.
Exemplo. Seja encontrar a distribuio discreta das probabilidades da varivel aleatria
discreta que consiste no lanamento de trs moedas. Neste caso o espao amostral S =
{HHH, HHT, HTH, THH, HTT, THT, TTH, TTT} e X ={0, 1, 2, 3} (o nmero de caras).
Ou seja,
X = 0 {TTT}
X = 1 {HTT, THT, TTH}
X = 2 {HHT, HTH, THH}
X = 3 {HHH}
Desta forma, pode-se construir uma tabela como
x
i
0 1 2 3
p(x
i
)
1
8
3
8
3
8
1
8
e plotar os pontos (x
i
, p(x
i
)) em um grco para se ter a noo da forma como a dis-
tribuio se comporta. Isto pode ser visto na Figura 2.1.
0 1 2 3
1/8
3/8
p(x )
i
x
i
Figure 2.1.1. Grco de uma distribuio discreta de probabilidades.
Distribuio contnua de probabilidades. Quando a varivel que est sendo analisada
tem valores em intervalos reais, a distribuio das probabilidades destes valores con-
tnua. Uma funo matemtica cujos valores sejam as probabilidades em cada ponto do
intervalo real, chamada de funo densidade de probabilidade, normalmente denotada
por fdp. A rea sob a curva que expressa a fdp igual a 1 que o valor total das probabil-
idades. Esta forma pode ser vericada no grco da Figura 2.2.
A denio da funo que d a distribuio de probabilidades feita encontrando-
se a funo que passe pelos pontos (x
i
, p(x
i
). Esta tarefa nem sempre fcil de ser real-
izada. Felizmente existem alguns modelos de distribuio de probabilidades que podem
37
1
2
0
p
01
p
00
p
02
p
11
p
12
p
10
p
22
p
21
p
20
1
2
0
0,8
0,2
0,2
0,15
0,7
0,05
0,5 0,3
0,1
a) b)
0,8 0,15 0,05
0,7 0,2 0,1
0,5 0,3 0,2
[ ]
c)
P =
Figure 21.3. Diagrama de transies.
Uma cadeia de Markov dita homognea se para todos os estados i e j
P{X
n+1
= j | X
n
= i} = P{X
n+m+1
= j | X
n+1
= i}
para n = 0, 1, 2, e m 0. A probabilidade de ir para o estado j no passo n+1 e para o
estado k no passo n+2, dado que a cadeia est no estado i no passo n dada por
P{X
n+2
= k, X
n+1
= j | X
n
= i}
= P{X
n+2
= k, X
n+1
= j, X
n
= i}P{X
n+1
= j | X
n
= i}
= P{X
n+2
= k, X
n+1
= j}P{X
n+1
= j | X
n
= i}
= p
jk
(n+1)p
i j
(n)
onde foram usadas inicialmente as propriedades da probabilidade condicional e depois a
propriedade da cadeia de Markov. Uma sequncia de estados visitados por uma cadeia
chamada de caminho da amostra. Assim, p
jk
(n+1)p
i j
(n) a probabilidade do caminho
da amostra i, j, k que inicia no estado i no passo de tempo n.
Exemplo (uma cadeia de Markov no homognea). Seja a cadeia discreta de Markov
{X
n
, n = 1, 2, } com apenas os estados a e b. No passo n a probabilidade de que a
cadeia permanea em seu estado atual dada por p
aa
(n) = p
bb
(n) = 1/n, enquanto a
probabilidade de que ela mude de estado p
ab
(n) = p
ba
(n) = (n1)/n, conforme pode
ser visualizado na Figura 2.4.
(n-1)/n
(n-1)/n
1/n
1/n
a
b
Figure 21.4. Uma cadeia de Markov de dois estados.
A matriz de transies dada por
P(n) =

1/n (n1)/n
(n1)/n 1/n

e as primeiras quatro matrizes de transies so dadas por

P(1) =

1 0
0 1

, P(2) =

1/2 1/2
1/2 1/2

, P(3) =

1/3 2/3
2/3 1/3

, P(4) =

1/4 3/4
3/4 1/4

38
As cadeias de Markov so casos particulares de processos estocsticos Marko-
vianos, em que o nmero de estados possveis nito ou innito enumervel. Na real-
idade, elas so tipos mais simples de processos estocsticos que possuem propriedades
importantes quando o nmero de transies cresce.
As propriedades a seguir so vlidas para as cadeias de Markov.
1. P
i j
0 para quaisquer estados i e j.
2. P
i j
1 para quaisquer estados i e j.
3.

j=0
P
i j
= 1 para todo i = 0, 1, 2,
Matriz de transio. Para efeito deste estudo, as probabilidades de transies dos estados
X
n
= i para os estados X
n+1
= j so conhecidas como probabilidades de transies de
passo nico ou apenas probabilidades de transies das cadeias de Markov, ou seja,
p
i j
= P{X
n+1
= j | X
n
= i}, n
A matriz P formada pelos elementos p
i j
da linha i e da coluna j, para todos os i
e j, chamada de matriz de probabilidades de transies ou apenas matriz de transies.
Assim temos
P(n) =

p
00
(n) p
01
(n) p
02
(n) p
0 j
(n)
p
10
(n) p
11
(n) p
12
(n) p
1 j
(n)
p
20
(n) p
21
(n) p
22
(n) p
2 j
(n)
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
p
i0
(n) p
i1
(n) p
i2
(n) p
i j
(n)
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

Uma maneira simples de visualizar uma cadeia de Markov atravs de uma

mquina de estados nitos ou por meio de um grafo dirigido, onde cada aresta rotu-
lada com as probabilidades de transio de um estado para o outro, sendo estes estados
representados pelos ns, conectados pelas arestas. Vamos introduzir esta idia atravs de
um exemplo.
Exemplo. Considere uma cadeia de Markov que descreve as mudanas climticas dirias
de uma dada localidade. Vamos considerar apenas trs tipos de padro de tempo: chu-
voso (0), nublado (1) e ensolarado (2), onde o tempo observado diariamente. Em um
determinado dia chuvoso, a probabilidade de que vai chover no dia seguinte estimada
em 0, 8 e a probabilidade de que ser nublado de 0, 15, enquanto a probabilidade de que
o dia seguinte seja ensolarado apenas 0, 05. Se um dia est nublado, a probabilidade
de que o dia seguinte tambm seja nublado 0, 2, de que seja chuvoso 0, 7, e de que
seja ensolarado 0, 1. Se um dia ensolarado, a probabilidade de que o dia seguinte seja
tambm ensolarado 0, 2, de que o dia seguinte seja nublado 0, 3 e de que o dia seguinte
seja chuvoso 0, 5. Gracamente, isto pode ser observado na Figura 2.3, onde tambm
est mostrada a matriz de transies.
39
1
2
0
p
01
p
00
p
02
p
11
p
12
p
10
p
22
p
21
p
20
1
2
0
0,8
0,2
0,2
0,15
0,7
0,05
0,5 0,3
0,1
a) b)
0,8 0,15 0,05
0,7 0,2 0,1
0,5 0,3 0,2
[ ]
c)
P =
Figure 21.3. Diagrama de transies.
Uma cadeia de Markov dita homognea se para todos os estados i e j
P{X
n+1
= j | X
n
= i} = P{X
n+m+1
= j | X
n+1
= i}
para n = 0, 1, 2, e m 0. A probabilidade de ir para o estado j no passo n+1 e para o
estado k no passo n+2, dado que a cadeia est no estado i no passo n dada por
P{X
n+2
= k, X
n+1
= j | X
n
= i}
= P{X
n+2
= k, X
n+1
= j, X
n
= i}P{X
n+1
= j | X
n
= i}
= P{X
n+2
= k, X
n+1
= j}P{X
n+1
= j | X
n
= i}
= p
jk
(n+1)p
i j
(n)
onde foram usadas inicialmente as propriedades da probabilidade condicional e depois a
propriedade da cadeia de Markov. Uma sequncia de estados visitados por uma cadeia
chamada de caminho da amostra. Assim, p
jk
(n+1)p
i j
(n) a probabilidade do caminho
da amostra i, j, k que inicia no estado i no passo de tempo n.
Exemplo (uma cadeia de Markov no homognea). Seja a cadeia discreta de Markov
{X
n
, n = 1, 2, } com apenas os estados a e b. No passo n a probabilidade de que a
cadeia permanea em seu estado atual dada por p
aa
(n) = p
bb
(n) = 1/n, enquanto a
probabilidade de que ela mude de estado p
ab
(n) = p
ba
(n) = (n1)/n, conforme pode
ser visualizado na Figura 2.4.
(n-1)/n
(n-1)/n
1/n
1/n
a
b
Figure 21.4. Uma cadeia de Markov de dois estados.
A matriz de transies dada por
P(n) =

1/n (n1)/n
(n1)/n 1/n

e as primeiras quatro matrizes de transies so dadas por

P(1) =

1 0
0 1

, P(2) =

1/2 1/2
1/2 1/2

, P(3) =

1/3 2/3
2/3 1/3

, P(4) =

1/4 3/4
3/4 1/4

40
Como pode ser observado pelas matrizes de transies, as probabilidades de que a
cadeia mude de estado vai aumentando, enquanto as probabilidades de que ela permanea
nos estados anteriores vai diminuindo a medida que o tempo passa. Pode-se observar o
comportamento markoviano, onde cada matriz depende apenas do estado anterior e no
de outros estados. A probabilidade de que seja tomado o caminho que inicia no estado a e
permanea neste estado aps as duas primeiras transies e depois move-se para o estado
b l permanece aps o terceiro e quarto passos dada por
P{X
5
= b, X
4
= b, X
3
= a, X
2
= a | X
1
= a}
= p
aa
(1)p
aa
(2)p
ab
(3)p
bb
(4)
= 11/22/31/4 = 1/12
2.1.3.1. Tipos de cadeias de Markov
Cadeias de Markov podem ser classicadas quanto natureza do tempo de transio entre
os estados, ou seja, discreto (DTMC - Discrete-Time Markov Chain) ou contnuo (CTMC
- Continuous-Time Markov Chain). Nas cadeias de Markov de Tempo Discreto as tran-
sies podem ocorrer somente em intervalos de tempo conhecidos, isto , passo-a-passo.
Este o caso dos exemplos apresentados anteriormente. Sistemas que so bem represen-
tados por DTMCs incluem aqueles onde as transies ocorrem seguindo uma base diria,
como visto na Figura 2.3, e aqueles que seguem um relgio discreto como o escalonador
de tarefas num computador. Se as transies entre estados puderem ocorrer em instantes
de tempo arbitrrios (contnuos) a cadeia de Markov uma CTMC. A propriedade Marko-
viana de ausncia de memria mantida para ambos os tipos de cadeias [2]. No caso da
DTMC, as transies obedecem a uma distribuio geomrica, pois esta a nica dis-
tribuio de tempo discreto que apresenta tal propriedade. No caso da CTMC, o tempo
das transies segue uma distribuio exponencial.
A Figura 2.5 um exemplo simples de cadeia de Markov de tempo contnuo.
Neste caso, a matriz de transio chamada de matriz geradora innitesimal pois, neste
caso, as transies ocorrem com uma taxa, em vez de uma probabilidade, devido na-
tureza contnua desse tipo de modelo. Considerando o modelo da Figura 2.5, a matriz
geradora Q composta por elementos q
ii
e q
i j
, onde i = j e q
i j
=q
ii
, ou seja, em uma
CTMC os elementos da diagonal tm seus valores denidos de forma que a soma de cada
linha da matriz seja igual a 0. Considerando um espao de estados S ={0, 1, 2}, a matriz
Q ser:
Q =

q
00
q
01
q
02
q
10
q
11
q
12
q
20
q
21
q
22

0, 001 0, 001 0
0 2 2
0, 2 0 0, 2

Para calcular o vetor de probabilidade de uma CTMC, usa-se a Equao 1 (no

caso de probabilidades transientes, dependentes do tempo) ou o sistema de Equaes 2
(no caso de probabilidades estacionrias, quando o tempo tende a innito).

(t) = (t)Q, given (0). (1)

41
Figure 21.5. Uma cadeia de Markov de tempo contnuo.
Q = 0,

iS

i
= 1 (2)
Explicaes detalhadas sobre como chegar a essas equaes podem ser encon-
tradas em [2].
Cadeias de Markov tambm podem ser classicadas de acordo com a frequncia
com que seus estados podem ser alcanados ao longo do tempo. Em uma cadeia irre-
dutvel, cada estado pode ser alcaado a partir de qualquer outro estado, de forma que
todos os estados so recorrentes
3
nesse tipo de modelo. Se, uma vez que o sistema deixa
um determinado estado, aquele estado no puder mais ser visitado, a cadeia de Markov
dita acclica. Se uma cadeia no for acclica nem irredutvel, classicada como phase-
type [18]. Ela ir, eventualmente, alcanar um estado absorvente
4
, mas enquanto isso
no acontece, a cadeia passa por um ou mais estados transientes
5
. A Figura 2.6 mostra
exemplos dos trs tipos de cadeias.
Figure 21.6. Tipos de cadeias de Markov de acordo com a frequncia de visitas
aos estados.
3
Um estado chamado recorrente se o sistema capaz de retornar a esse estado inmeras vezes [18].
4
Um estado chamado absorvente se uma vez que ele alcanado, a cadeia no for capaz de sair desse
estado.
5
Um estado chamado transiente se, durante um perodo de tempo nito, o sistema visitar esse estado
um nmero nito de vezes [18].
42
2.1.3.2. Modelos Markovianos com Recompensa
Os modelos Markovianos com recompensa (Markov reward models - MRM) [21] so
usados geralmente para obter mtricas compostas, provendo a anlise integrada de de-
sempenho e conabilidade, por exemplo. Para construir um MRM, uma taxa constante de
recompensa r
i
associada a cada estado i de uma cadeia de Markov. Tambm possvel
associar taxas de recompensa s transies da cadeia [24], e nesse caso elas so conheci-
das como recompensas de impulso (impulse rewards). Em geral, a recompensa associada
a um estado denota o nvel de desempenho
6
obtido pelo sistema enquanto encontra-se
naquele estado [18]. Usando novamente o modelo da Figura 2.5, se as taxas de recom-
pensas forem denidas como um vetor r = (r
1
, r
2
, r
3
) = (5, 0, 2), representando a receita
obtida em cada estado, a taxa de reward instantnea esperada para o tempo t :
E[X(t)] =

iS
r
i

i
(t) = 5
0
(t) +0
1
(t) +2
2
(t). (3)
E[X(t)] pode ser considerado como a receita mdia obtida pela operao do sis-
tema no tempo t. Outros tipos de recompensa podem ser usados, tais como poder com-
putacional, status de disponibilidade do sistema, nalizao de tarefas por unidade de
tempo. Independentemente da taxa de recompensa, r
i
que adotada, a recompensa esper-
ada em estado estacionrio pode ser computada na forma da Equao 4.
E[X] =

iS
r
i

i
(4)
Devido possibilidade de calcular mtricas como ganho mdio em estado esta-
cionrio e ganho total em um determinado intervalo de tempo, os modelos Markovianos
de recompensa tm sido vastamente adotados em estudos de performabilidade, que com-
binam aspectos de performance e dependabilidade como ferramentas unicadas [23].
2.1.3.3. Modelos de gerao automtica
DTMCs e CTMCs permitem a anlise de muitos tipos de sistemas, com acurcia e poder
de modelagem adequados. Outros formalismos de modelagem, tais como as redes de
las [7], redes de Petri estocsticas (SPNs) [15, 10], e redes de Petri determinsticas e
estocsticas (DSPNs) [11], podem ser consideradas tcnicas de especicao de alto nvel
para gerao de cadeias de Markov. Esses formalismos so teis em muitas ocasies,
devido possibilidade de exploso do espao de estados da cadeia de Markov, medida
que aumenta o nmero de componentes e a complexidade das interaes num sistema.
Uma cadeia de Markov de tempo contnuo (CTMC) pode ser associada a uma
rede de Petri temporizada e estocstica. Em redes de Petri (RdP) isso garantido devido
a ausncia de memria no atraso dos disparos das transies (distribuio exponencial)
[14]. Nesse sentido, uma rede de Petri estocstica [8] isomrca ao formalismo da
CTMC.
6
A palavra desempenho aqui usada num sentido amplo, signicando qualquer aspecto mensurvel
do comportamento do sistema.
43
(a) Exemplo de uma rede de Petri.
(1,0,0,0)
(0,1,0,0) (0,0,1,0)
(0,0,0,1)
t0 t1
t3 t2
t4
M0 =
M1 = M2 =
M3 =
M0
(b) rvore de alcanabilidade.
3
0
t0
1 2
t1
t4
t3
t2
(c) Cadeia de Markov.
Figure 21.7. Exemplo da equivalncia entre cadeia de Markov e rede de Petri.
Adicionalmente, para auxiliar na gerao da cadeia de Markov equivalente rede
de Petri estocstica, constri-se a rvore de alcanabilidade. A rvore de cobertura ou
alcanabilidade baseia-se na gerao de uma rvore que possibilite a representao de
todas as possveis marcaes de uma RdP. A Figura 2.7(a) representa um modelo em
RdP, sua representao atravs da rvore de alcanabilidade (Figura 2.7(b)) e a cadeia de
Markov equivalente (Figura 2.7(c)).
A partir da rvore de alcanabilidade, pode-se construir a cadeia de Markov equiv-
alente ao modelo. O espao de estados da cadeia de Markov correspondente rvore de
alcanabilidade de uma rede de Petri estocstica, sendo esta equivalente s marcaes
encontradas. Por conseguinte, na Figura 2.7(b), a rvore de alcanabilidade possui 4 mar-
caes que so equivalentes aos estados da Cadeia de Markov.
44
2.1.4. Modelos clssicos para avaliao de desempenho e disponibilidade
Quando busca-se avaliar aspectos de desempenho e disponibilidade de umsistema, podem
ser gerados diferentes modelos, a depender da habilidade e experincia de quem os cria,
ou do nvel de generalizao utilizado, entre outras questes. Esta seo visa apresentar
exemplos de modelos que servem como base para muitos estudos, dos mais simples aos
mais complexos, envolvendo os aspectos de desempenho e disponibilidade de um sistema.
2.1.4.1. Cadeias de nascimento-morte
Uma cadeia de Markov homognea, irredutvel, de parmetro contnuo denominada
processo de nascimento e morte se as nicas mudanas permitidas, a partir de um deter-
minado estado i do processo, so para seus vizinhos imediatos, ou seja, para os estados
i +1 (nascimento) ou para o estado i 1 (morte). Um nascimento se processa com a taxa

i
e uma morte com a taxa
i
, ou seja, dependem apenas do estado i. Este processo pode
ser visto gracamente na Figura 2.8.
0 1 2 3 4
...........
0

1
2

3

4

1
2
5

Figure 21.8. Diagrama de um processo de nascimento e morte.

Este tipo de cadeia de Markov muito utilizado para representar sistemas que fun-
cionam com base na simples chegada de requisies, que sero atendidas por n servidores.
A chegada de uma nova requisio um nascimento na cadeia e, portanto, acontece com
uma taxa
i
, ocupando um servidor do sistema. J o servio oferecido pelo sistema efe-
tuado a uma taxa
i
, congurando-se como uma morte na cadeia, que libera um servidor
para atender outras possveis requisies.
Aspectos importantes do desempenho do sistema podem ser conhecidos atravs
da probabilidade de se estar em determinados estados da cadeia de nascimento e morte.
Um exemplo a probabilidade do sistema encontrar-se ocioso, que corresponde a
0
. Se
essa probabilidade for calculada para estado estacionrio do sistema, ainda pode-se obter
o tempo mdio (em horas) de ociosidade do sistema ao longo do perodo de um ano. Para
isso, basta multiplicar
0
por 8760 horas, que corresponde ao nmero de horas de 1
ano. De forma semelhante, se o sistema possui somente n servidores e chegarem novas
requisies com uma taxa
n
, que no podero ser atendidas devido a todos os servidores
estarem ocupados, a probabilidade de uma requisio ser rejeitada devido ao sistema estar
completamente ocupado calculada como
n

n
.
Sistemas de la tambm podem ser representados por cadeias de nascimento e
morte, com a nalidade de se obter mtricas como ocupao mdia da la e nvel de
utilizao do sistema. O custo energtico mdio do sistema tambm pode ser calculado,
ao associar recompensas (rewards) referentes energia consumida em cada estado da
cadeia.
45
2.1.4.2. Modelos simples de falha e reparo
Quando se deseja analisar aspectos relacionados a eventuais falhas e reparos de um sis-
tema computacional, um modelo simples como o apresentado na Figura 2.9 pode servir
como base para as construes de outras cadeias mais complexas. Nesse modelo, h
apenas 3 estados possveis para o sistema: Funcionando, Quebrado, ou Em Reparo.
Considerando-se, por exemplo, que o sistema esteja funcionando, uma falha ocorrer
com uma taxa , que deve ser igual ao inverso do tempo mdio para falha do sistema,
conhecido como MTTF (Mean Time To Failure). Se o MTTF do sistema for 1000 horas,
ento o valor de ser 1/1000, ou 0, 001.
Figure 12.9. Diagrama de um modelo simples de falha e reparo.
A ocorrncia de uma falha coloca o sistema no estado Quebrado, espera de
que a equipe de reparo seja acionada e possa efetivamente iniciar o conserto. A taxa
corresponder ao inverso desse tempo gasto desde a falha at o incio do reparo. Se esse
tempo for de 30 minutos, ser igual a 2, pois deve-se considerar o inverso do tempo
em horas (1/0, 5). A partir do instante em que o sistema j se encontra em reparo, caso o
tempo mdio desta atividade seja 2 horas, a taxa ser igual a 0, 5.
Dentre as mtricas mais importantes que se pode obter deste modelo, esto o per-
centual de disponibilidade (ou indisponibilidade) em estado estacionrio (A) e o downtime
(tempo de indisponibilidade) anual (D). O percentual de disponibilidade calculado sim-
plesmente atravs da probabilidade do sistema estar no estado Funcionando,
Funcionando
.
importante citar que o percentual de indisponibilidade (U) pode ser calculado indire-
tamente pelo percentual de disponibilidade, como 1A, ou diretamente atravs da soma
das probabilidades dos estados Quebrado e Em Reparo. J o downtime anual, em horas,
ser igual ao percentual de indisponibilidade multiplicado por 8760, que o tempo em
horas correspondente a um ano. Obtm-se ento D =U 8760.
Cadeias de Markov mais complexas podem ser geradas ao conhecer aspectos de
falhas isoladas em componentes especcos de um sistema, de forma que ele continua
a funcionar mesmo aps a quebra de algumas partes. Em muitos casos, o tamanho da
cadeia de Markov cresce exponencialmente medida que mais componentes do sistema
vo sendo representados, com suas respectivas falhas e reparos independentes. Diante
deste fato, comum utilizar algumas simplicaes que tornam o modelo mais fcil de
ser entendido e diminui o tempo exigido para sua soluo.
46
2.1.5. Ferramenta de apoio modelagem e solues de cadeias de Markov
Nos ltimos anos, diversos trabalhos tm sido desenvolvidos para avaliao e modelagem
de cadeias de Markov. Nesse sentido, algumas ferramentas so acadmicas e comerciais.
Podemos citar Sharpe [3], JMT [3], Isograph [6] e R [17].
SHARPE (Symbolic Hierarchical Automated Reliability and Performance Evalu-
ator) uma ferramenta acadmica para modelagem e avaliao de desempenho,
disponiblidade, conabilidade e performabilidade. A ferramenta suporta a mode-
lagem atravs de rvore de falha, diagrama de blocos de conabilidade, cadeia de
Markov, rede de Petri estocstica generalizada, entre outros.
JMT (Java Modelling Tools) um framework para avaliao de desempenho, plane-
jamento de capacidade e estudos de caracterizao de carga. A ferramenta disponi-
biliza a modelagem de cadeia de Markov, redes de las, entre outros.
Isograph uma ferramenta comercial para modelagem e avaliao de conabili-
dade, predio de conabilidade e manuteno. Alm disso, a ferramenta oferece
anlise atravs de diagrama de blocos de conabilidade, anlise dos efeitos dos mo-
dos de falha, anlise por rvores de eventos e anlise de rvore de eventos e anlise
de Markov.
R um ambiente open source para anlises estatsticas e grcos. Adicionalmente,
a ferramenta suporta a modelagem de cadeia de Markov.
2.1.6. Estudos de casos
Os estudos de caso expostos a seguir ilustram algumas possibilidades de utilizao das
cadeias de Markov, auxiliando na avaliao de cenrios e descrevendo o comportamento
de sistemas que esto sempre exigindo altos nveis de desempenho, conabilidade e
disponibilidade.
2.1.6.1. Planejamento de redundncia em redes de computadores
Este estudo de caso baseado em [12] e apresenta o planejamento de redundncia em
uma rede de computadores, com base na anlise da disponibilidade prevista para cada
arquitetura. Apenas roteadores e enlances entre os roteadores so considerados aqui.
Duas cadeias de Markov de tempo contnuo foram construdas para analisar as
arquiteturas de rede visadas. Na Figura 2.10, a cadeia de Markov representa o cenrio
mais simples, sem redundncia. H somente um enlace, rotulado como L0, conectando
o roteador R0 ao roteador R1. Nesse modelo, a operao normal de um componente
denotada por um rtulo U (up/ativo), e um componente quebrado representado por um
rtulo D(down/inativo). Nessa cadeia de Markov, umestado denido por uma sequncia
de rtulos, representado o roteador R0, roteador R1 e enlace L0, respectivamente.
R0
,

R1
e
L0
so as respectivas taxas de falha de R0, R1 e L0. De modo similar,
L0
,
R0
e
R1
so as taxas de reparo de cada componente do sistema. Uma vez que qualquer
componente (R0, R1, ou L0) tenha falhado, o sistema completo est num estado de falha
e consequentemente nenhuma falha adicional pode ocorrer at que o componente seja
47
reparado. Para esse modelo, o sistema est ativo e funcionando somente no estado UUU.
Todos os outros estados esto acinzentados na Figura 2.10, representando os estados de
falha do sistema.
Figure 12.10. Cadeia de Markov para a disponibilidade de uma rede sem redundncia
A Figura 2.11 mostra a cadeia de Markov para o sistema com redundncia em
nivel de enlace. A notao similar do modelo anteior. A condio ideal para esse
sistema denotada pelo estado UUUU, no qual todos os componentes esto ativos, em
condies normais.
A cadeia mostra que o sistema pode falhar devido quebra de um dos roteadores,
ou falhas em ambos os enlaces. Uma hiptese assumida nesse modelo que h uma
poltica de reparo, que prioriza o enlace L0 sobre o enlace L1, quando ambos falharem.
Figure 12.11. Cadeia de Markov para a disponibilidade de uma rede com re-
dundncia no enlace
Os MTTFs dos componentes usados nas duas arquiteturas so: 131.000 horas para
os roteadores e 11.988 horas para os enlaces. O tempo mdio para reparo (MTTR) igual
a 12 horas, para todos os compoentes. Note que todos os
i
nos modelos so iguais a
1/MTTF
i
e todos os
i
so iguais a 1/MTTR
i
. As taxas so exibidas em vez dos tempos
devido sua forma compacta, que facilita o entendimento dos modelos.
A anlise do modelo sem redundncia, em estado estacionrio, prov um valor de
0,9980 para a disponibilidade desse sistema. Calculando a mesma mtrica com o modelo
48
que possui redundncia de enlace obtm-se 0,9995. Esse aumento na disponibilidade se
traduz em uma reduo do downtime anual de 7,53 horas para 1,88 horas, congurando-se
num ganho importante para empresas e organizaes que precisam manter sua infraestru-
tura de comunicao funcionando de forma ininterrupta, sob pena de degradao da im-
agem corporativa e grandes prejuzos nanceiros por quebras de contrato e/ou perda de
possveis clientes. Alm de servir para comparar as mtricas estimadas para diferentes
arquiteturas candidatas, as cadeias de Markov aqui poderiam ser usadas para vericar at
que ponto aumentos na conabilidade de um determinado componente podem suprir os
requisitos do sistema sem a necessidade de comprar e instalar equipamentos para servir
de rplicas dos servidores e dados crticos presentes no sistema.
2.1.6.2. Avaliao de desempenho e conabilidade de composies de web services
Este estudo de caso aborda inicialmente a anlise de um processo de agente de viagem.
Tal sistema composto de mltiplos servios Web, exigindo passos especcos para com-
pletar a reserva de uma viagem. A Figura 2.12 mostra um diagrama de atividades UML
(Unied Modeling Language) para este processo, adaptado de [19].
Reserva - Hotel
Resp. ao cliente
Inicializao
Reserva - Area
Consulta - Area 2 Consulta - Area 1
Figure 12.12. Processo de agente de viagem.
No incio do processo, o sistema de reserva de viagem busca simultaneamente
por vagas em duas companhias areas. Quando elas respondem, uma escolhida com
base em algum critiro tal como preo ou calendrio. Se uma das linhas areas falhar
em responder, a outra selecionada, e no caso de ambas falharem, o sistema agente de
viagem desiste e aborta. Outros passos incluem a invocao efetiva para reserva do bilhete
da companhia area, a reserva do hotel e a noticao de sucesso para o cliente. Qualquer
um dos web services pode falhar em responder e, neste caso, o sistema tenta se recuperar
atravs de reinicializaes, exceto pela busca em companhias areas concorrentes.
Uma CTMC para esse sistema exibida na Figura 2.13. Esse modelo foi con-
strudo para calcular o desempenho e a conabilidade da composio de Web services e
49
Figure 2.1.13. CTMC para a composio de Web services.
assim planejar possveis mudanas no sistema.
A traduo das atividades do modelo UML para os estados da cadeia de Markov
quase direta, com exceo de poucos estados que foram adicionados. RIni, RAresv,
RHt, e RRep representam os estados de reinicializao do Web service aps uma falha.
Por exemplo, quando o servio de Inicializao falha, o sistema vai para o estado RIni,
de onde h 2 prximos estados possveis: a) Inicializao, se a falha que ocorreu for
coberta, ou seja, se pode ser resolvida com a reinicializao; e b) Falha, se a falha no foi
resolvida pela reinicializao, de forma que o sistema inteiro falha. Os outros estados de
reinicializao tem signicados similares.
Os parmetros mrsp
i
, mrsp
a1
, mrsp
a2
, mrsp
ai
, mrsp
ht
and mrsp
rep
correspondem
ao tempo de resposta mdio dos seguintes web services, respectivamente: inicializao,
consulta companhia rea 1, consulta companhia area 2, reserva da passagem erea
(invocao), reserva do hotel e resposta ao cliente. Os outros parmetros seguem uma
notao similar. Note que algumas taxas de transio so iguais ao inverso do tempo de
resposta mdio do Web service (mrsp
x
), ponderado pela probabilidade de que a transio
ocorra, isto , a conabilidade do respectivo Web service (r
x
).
Se qualquer web service x falhar, a taxa da transio ser igual a
1r
x
mrsp
x
. As taxas
de transio saindo dos estados de reinicializao so iguais ao inverso do tempo mdio
de reinicializao (mr
x
), ponderado pelo fator de cobertura das falhas para aquele Web
service (C
x
), no caso de uma reinicializao com sucesso. Se a reinicializao daquele
web service no obtiver sucesso, o sistema faz uma transio para o estado Falha, com
uma taxa
1C
x
mr
x
.
50
Table 12.1. Valores dos parmetros para o modelo do Agente de Viagem.
Componente Conf. (r) T resp. (mrsp) Cobertura (C) T reinic. (mr)
Inicializao (init) 1,0 1 s 1,0 0,15 s
Consulta - area 1 (a1) 0,9 2 s - -
Consulta - area 2 (a2) 0,9 2 s - -
Invocao - cia. area (ai) 0,9 1 s 1,0 0,15 s
Reserva hotel (ht) 0,9 2 s 0.0 0,15 s
Resp. ao cliente (rep) 1,0 1 s - 0,15 s
Os valores usados como base para a anlise da cadeia de Markov so mostrados
na Tabela 2.1.
Analisando o modelo da Figura 2.13, se obtm, entre outras mtricas, a proba-
bilidade do sistema encontrar-se no estado Completo no instante t (
Completo
(t)). O
valor de
Completo
(t) equivalente probabilidade do tempo de resposta do sistema ser
menor ou igual ao tempo t: P[Resp t]. Supondo que o projetista, ou desenvolvedor,
desse sistema esteja interessado num tempo de resposta de 8 segundos, calculamos ento

Completo
(8) = 0, 5173, ou seja, h 51,83% de probabilidade do sistema responder em 8
segundos ou menos. Calculando essa probabilidade para diferentes valores de tempo t,
obtm-se a curva apresentada na Figura 2.14. Atravs dela, percebe-se que h uma prob-
abilidade prxima a 100% de que o tempo de resposta seja no mximo 25 segundos. Esse
tipo de anlise pode ser utilizada como base para a denio de contratos de nvel de
servio (SLA - Service Level Agreement) entre o provedor da aplicao de Agente de Vi-
agem e seus clientes, fornecendo estimativas concretas sobre o desempenho da aplicao
em questo, j levando em considerao aspectos de conabilidade.
P
r
o
b
a
b
i
l
i
d
a
d
e
0
0,2
0,4
0,6
0,8
1
Tempo de resposta (s)
0 5 10 15 20 25 30
Figure 12.14. Curva de probabilidade de concluso de acordo com o tempo.
2.1.7. Consideraes nais e perspectivas
Este captulo tratou sobre a teoria que envolve as cadeias de Markov assim como sua utili-
dade no planejamento de capacidade de sistemas computacionais. Os exemplos de mode-
los e anlises aqui apresentados servem como uma introduo capaz de guiar a construo
51
e anlise de outros modelos mais sosticados, possibilitando a avaliao do desempenho
e dependabilidade de vrios tipos de sistemas. Espera-se que o leitor possa aproveitar o
mximo do texto, e aplic-lo em ambientes reais, na academia e na indstria, expandindo
o conhecimento e a utilizao deste formalismo e suas ferramentas associadas.
References
[1] BARROS, Mnica; Processos Estocsticos; Papel Virtual Editora; Rio de Janeiro;
2004.
[2] BOLCH, G., GREINER, S., de MEER, H., and TRIVEDI, K. S.; Queuing Networks
and Markov Chains: modeling and performance evaluation with computer science
applications; John Wiley and Sons; 2 ed.; 2001.
[3] BERTOLI, Marco and CASALE, Giuliano and SERAZZI, Giuseppe; JMT: perfor-
mance engineering tools for system modeling; SIGMETRICS Perform. Eval. Rev.
vol36; March, 2009.
[4] GUNTER, B.; GREINER, S.; de MEER, H. and TRIVEDI, K. S.; Queueing Net-
works and Markov Chains: Modeling and Performance Evaluation with Computer
Science Applications; 2nd edition; John Wiley & Sons, Inc.; 2006.
[5] HAVERKORT, B. and MEEUWISSEN, A.; Sensitivity and uncertainty analysis of
Markov-reward models. IEEE Transactions on Reliability, 44(1):147154; 1995.
[6] Isograph; Reliability Workbench 11 http://www.isograph-software.com/. ltimo
acesso em 09 de Outubro de 2011.
[7] KLEINROCK, L. Queueing Systems, volume 1. Wiley, New York; 1975.
[8] MACIEL, P. R. M.. LINS, R. D. and CUNHA, P. R. F.; Introduo s Redes de Petri
e Aplicaes; Sociedade Brasileira de Computao; Campinas, So Paulo. 1996.
[9] MACIEL, P. R. M.; TRIVEDI, K.; MATIAS JR R.; and KIM, D.; Performance
and Dependability in Service Computing: Concepts, Techniques and Research Di-
rections; Dependability Modeling. IGI Global, Hershey, Pennsylvania; 2011.
[10] AJMONE MARSAN, M., CONTE, G., and BALBO, G.; A class of generalized
stochastic petri nets for the performance evaluation of multiprocessor systems. ACM
Trans. Comput. Syst., 2:93122. 1984.
[11] MARSAN, M. A. and CHIOLA, G.; On petri nets with deterministic and expo-
nentially distributed ring times. In Advances in Petri Nets 1987, covers the 7th
European Workshop on Applications and Theory of Petri Nets, pages 132145, Lon-
don, UK. Springer-Verlag. 1987.
[12] MATOS JNIOR, R. de S., GUIMARES, A. P., CAMBOIM, K. M. A., MA-
CIEL, P. R. M., TRIVEDI, K .S.; Sensitivity Analysis of Availability of Redun-
dancy in Computer Networks. In Proceedings of the Third International Conference
on Communication Theory, Reliability, and Quality of Service, CTRQ 2010, pages
115121, Budapest. IARIA. 2011.
52
[13] MENASC, D. A.; ALMEIDA, V. A.; and DOWDY, L. W.; Performance by Design:
Computer Capacity Planning by Example. Prentice Hall PTR.; 2004.
[14] MOLLOY, Michael Karl; On the integration of delay and throughput measures in
distributed processing models; Phd Thesis; University of California, Los Angeles,
1981.
[15] MOLLOY, M. K.; Performance analysis using stochastic petri nets. IEEE Trans.
Comput., 31:913917. 1982.
[16] NORRIS, J. R.; Markov Chains; Cambridge Series in Statistical and Probabilistic
Mathematics; 2009.
[17] R Project Page The R Project for Statistical Computing; http://www.r-project.org/.
ltimo acesso em 10 de Outubro de 2011.
[18] SAHNER, R. A., TRIVEDI, K. S., and PULIAFITO, A. Performance and reliabil-
ity analysis of computer systems: an example-based approach using the SHARPE
software package. Kluwer Academic Publishers, Norwell, MA, USA; 1996.
[19] SATO, N. and TRIVEDI, K. S.; Stochastic modeling of composite web services for
closed-form analysis of their performance and reliability bottlenecks. In ICSOC,
pages 107118; 2007.
[20] SHAMBLIN, James E.; Pesquisa Operacional: uma abordagem bsica; Editora
Atlas, So Paulo, 1979.
[21] SMITH, M. R., TRIVEDI, S. K., and NICOLA, F. V.; The analysis of computer
systems using markov reward processes. Technical report, Durham, NC, USA; 1987.
[22] STEWART, William J.; Probability, Markov chains, queues and simulation: the
mathematical basis of performance modeling. 2009.
[23] TRIVEDI, K. S., MUPPALA, J. K., WOOLET, S. P., and HAVERKORT, B. R.;
Composite performance and dependability analysis. Performance Evaluation, 14(2-
3):197215; 1992.
[24] TRIVEDI, K. S., MALHOTRA, M., and FRICKS, R. M. Markov reward approach
to performability and reliability analysis. In Proceedings of the Second International
Workshop on Modeling, Analysis, and Simulation On Computer and Telecommu-
nication Systems, MASCOTS 94, pages 711, Washington, DC, USA. IEEE Com-
puter Society. 1994.
[25] TRIVEDI, K. S.; Probability and Statistics with Reliability, Queuing, and Computer
Science Applications. John Wiley and Sons, 2nd. edition; 2002.
[26] TRIVEDI, K. S. and SAHNER, R.; SHARPE at the age of twenty two; doi =
http://doi.acm.org/10.1145/1530873.1530884; SIGMETRICS Perform. Eval. Rev.;
vol 36; ACM; March, 2009.
53
Captulo
13
Computao Autonmica aplicada a Segurana de
Redes
Ariel Soares Teles, Francisco Jos da Silva e Silva, Zair Abdelouahab
Abstract
The constant increase in the number of computers networks attacks attempts has pushed
researchers community to devise better security strategies. However, the rapid growth
both in quantity and complexity of components and services offered in todays networks
has increased the difculty of administering these, making approaches based only on hu-
man interventions impracticable. In order to circumvent this problem, a modern appro-
ach called Autonomic Computing (AC) has gained attention from researchers related to
network security management. AC has the essence of self-management and the implemen-
tation of its concepts for network security systems introduces the ability of self-assurance.
This chapter aims to introduce the concepts of AC and shows their applicability to the
context of security in computer networks.
Resumo
O constante aumento no nmero de tentativas de ataques s redes de computadores leva a
uma busca por melhores estratgias de segurana. Porm, o grande crescimento tanto na
quantidade como na complexidade de componentes e servios oferecidos nas atuais redes
tem aumentado a diculdade de administrao destas, tornando cada vez mais invivel
abordagens baseadas apenas em intervenes humanas. Com o objetivo de contornar
esta problemtica, uma moderna abordagem denominada Computao Autonmica (CA)
tem ganho destaque nas pesquisas relativas ao gerenciamento da segurana de redes. CA
tem como essncia o autogerenciamento e a aplicao de seus conceitos segurana de
redes introduz no sistema a capacidade de autosegurana. Este captulo tem como obje-
tivo introduzir os conceitos de CA e mostrar sua aplicabilidade ao contexto de segurana
em redes de computadores.
54
31.1. Introduo
Segurana em redes de computadores compreende a rea responsvel pela proteo dos
dados que a transitam contra alteraes indevidas, acesso no autorizado e indisponibi-
lidade. Desde o surgimento da Internet, a busca por melhores estratgias de segurana
tem aumentado consideravelmente, tendo em vista a grande quantidade de tentativas de
ataques que vem sendo realizados. Esses ataques, quando bem sucedidos, tem causado
prejuzos nanceiros e de imagem para empresas, instituies e pessoas fsicas.
Existem vrios obstculos a serem enfrentados para se alcanar redes realmente
seguras, dentre eles pode-se destacar a existncia de dependncia dos sistemas de segu-
rana por gerenciamento com interveno humana, sendo este um processo que aumenta
continuamente o nvel de diculdade. O fato dos ataques sistemas computacionais esta-
rem se tornando cada vez mais sosticados e as vrias decincias encontradas nos atuais
sistemas de segurana tambm so outros exemplos de obstculos, como sero vistos
neste captulo.
Tudo isso eleva a complexidade do problema da gerncia de segurana e por isso
interessante a utilizao de recursos oferecidos pela Computao Autonmica (CA).
Sistemas de CA so capazes de gerenciarem a si prprios e se adaptarem dinamicamente
s mudanas a m de restabelecer seu equilbrio de acordo com as polticas e os objetivos
de negcio. Para isso, dispem de mecanismos efetivos que os permitem monitorar, con-
trolar e regular a si prprios, bem como recuperarem-se de problemas sem a necessidade
de intervenes externas.
A arquitetura e as propriedades de CA para a implementao de sistemas prope
uma abordagem com muitas vantagens para ser aplicada segurana de redes. Alm
de apresentar caractersticas intrsecas de autogerenciamento, um elemento autonmico
prov outras funcionalidades que podem ser utilizadas para resolver problemas particula-
res segurana de redes, com o uso de tcnicas de aprendizagem e cooperao entre as
aplicaes.
Neste captulo ser discutido os conceitos de CA e mostrado sua aplicabilidade
ao contexto de segurana em redes de computadores. A aplicao dos conceitos de CA
segurana de redes introduz no sistema a capacidade de autosegurana, atravs da qual
servios e funes de gerenciamento da segurana so executados sem a necessidade de
um gerente humano, a partir da denio de objetivos e parmetros iniciais fornecidos
por seus administradores.
O restante deste trabalho est organizado da seguinte forma. Todos os fundamen-
tos de CA so descritos na Seo 2, mostrando suas propriedades, arquitetura e detalhes
do ciclo autonmico. A Seo 3 ir descrever alguns conceitos de segurana em redes e
mostrar os problemas enfrentados por elas neste quesito. A necessidade que a segurana
em redes de computadores tem por mecanismos autonmicos e exemplos de trabalhos j
realizados em segurana autonmica de redes sero detalhados na Seo 4. Para nalizar
o captulo, na Seo 5 sero apresentadas as concluses.
55
31.2. Computao Autonmica
O termo Computao Autonmica surgiu em 2001, com um manifesto publicado por Paul
Horn, pesquisador da IBM, que lanou um desao sobre o problema da crescente com-
plexidade de gerenciamento do software [17]. O termo autonmico vem da biologia e
est relacionado s reaes siolgicas involuntrias do sistema nervoso [25]. No corpo
humano, o sistema nervoso autonmico cuida de reexos inconscientes, isto , de fun-
es corporais que no requerem nossa ateno como a contrao e expanso da pupila,
funes digestivas do estmago e intestino, a frequncia e profundidade da respirao, a
dilatao e constrio de vasos sanguneos, etc. Esse sistema reage s mudanas, ou per-
turbaes, causadas pelo ambiente atravs de uma srie de modicaes, a m de conter
as perturbaes causadas ao seu equilbrio interno.
Em analogia ao comportamento humano, diz-se que um sistema computacional
est em equilbrio quando o seu ambiente interno (formado pelos seus subsistemas e pelo
prprio sistema) est em proporo devida com o ambiente externo. Conforme obser-
varam Parashar e Hariri em [27] e detalhado em [28], se o ambiente interno ou externo
perturba a estabilidade do sistema, ele sempre atuar de modo a recuperar o equilbrio
original. Dessa forma, os sistemas de CA so sistemas capazes de se autogerenciarem
e se adaptarem dinamicamente s mudanas a m restabelecer seu equilbrio de acordo
com as polticas e os objetivos do negcio do sistema [17]. Para isso, devem dispor de me-
canismos efetivos que os permita monitorar, controlar e regular a si prprios, bem como
recuperarem-se de problemas sem a necessidade de intervenes externas.
31.2.1. Propriedades de Sistemas Autonmicos
A essncia da CA o autogerenciamento. Para implement-lo, o sistema deve ao mesmo
tempo estar atento a si prprio e ao seu ambiente. Desta forma, o sistema deve conhecer
com preciso a sua prpria situao e ter conscincia do ambiente operacional em que
atua. Do ponto de vista prtico, conforme Hariri [13], o termo computao autonmica
tem sido utilizado para denotar sistemas que possuem as seguintes propriedades:
Autoconscincia (self-awareness): O sistema conhece a si prprio: seus compo-
nentes e inter-relaes, seu estado e comportamento;
Conscincia do contexto (context-aware): O sistema deve ser ciente do contexto
de seu ambiente de execuo e ser capaz de reagir a mudanas em seu ambiente;
Autocongurao (self-conguring): O sistema deve ajustar dinamicamente seus
recursos baseado em seu estado e no estado do ambiente de execuo;
Auto-otimizao (self-optimizing): O sistema capaz de detectar degradaes de
desempenho e de realizar funes para auto-otimizao;
Autoproteo (self-protecting): O sistema capaz de detectar e proteger seus re-
cursos de atacantes internos e externos, mantendo sua segurana e integridade geral;
Autocura (self-healing): O sistema deve possuir a habilidade de identicar poten-
ciais problemas e de se recongurar de forma a continuar operando normalmente;
56
Aberto (open): O sistema deve ser portvel para diversas arquiteturas de hardware
e software e, consequentemente, deve ser construdo a partir de protocolos e inter-
faces abertos e padronizados;
Capacidade de Antecipao (anticipatory): O sistema deve ser capaz de anteci-
par, na medida do possvel, suas necessidades e comportamentos considerando seu
contexto e de se autogerenciar de forma pr-ativa.
As propriedades de autocongurao, auto-otimizao, autocura e autoproteo
so sucientes para realizar a viso original do termo [25]. Para a incorporao das pro-
priedades de auto-otimizao e autocura, mecanismos de autoconscincia, conscincia de
contexto e autocongurao devem ser requisitos do sistema.
13.2.2. Arquitetura de um Sistema Autonmico
Arquiteturas de sistemas autonmicos visam formalizar um quadro de referncia que
identica as funes comuns e estabelece os alicerces necessrios para alcanar a au-
tonomia. Em geral, essas arquiteturas apresentam solues para automatizar o ciclo de
gerenciamento de sistemas, conforme mostrado na Figura 3.1, o qual envolve as seguintes
atividades:
Figura 13.1. Ciclo de gerenciamento de sistemas [5].
Monitoramento ou Medio: Coleta, agrega, correlaciona e ltra dados sobre
recursos gerenciados;
Anlise e Planejamento: Analisa os dados coletados e determina se devem ser
realizadas mudanas nas estratgias utilizadas pelo recurso gerenciado;
Controle e Execuo: Escalona e executa as mudanas identicadas como neces-
srias pela funo de anlise e deciso.
13.2.2.1. MAPE-K
Em 2003 a IBM props uma verso automatizada do ciclo de gerenciamento de sistemas
chamado de MAPE-K (Monitor, Analyse, Plan, Execute, Knowledge) [17], representado
57
na Figura 3.2. Este modelo est sendo cada vez mais utilizado para inter-relacionar os
componentes arquiteturais dos sistemas autonmicos. De acordo com essa arquitetura,
um sistema autonmico formado por um conjunto de elementos autonmicos.
Um elemento autonmico contm um nico gerente autonmico que representa e
monitora um ou mais elementos gerenciados (componente de hardware ou de software)
[19]. Cada elemento autonmico atua como um gerente responsvel por promover a pro-
dutividade dos recursos e a qualidade dos servios providos pelo componente do sistema
no qual est instalado.
Figura 13.2. MAPE-K: Ciclo de gerenciamento autonmico [16].
No ciclo MAPE-K autonmico (Figura 3.2), o elemento gerenciado representa
qualquer recurso de software ou hardware o qual dado o comportamento autonmico
atravs do acoplamento de um gerenciador autonmico, podendo ser por exemplo um
servidor Web ou banco de dados, um componente de software especco em um aplicativo
(por exemplo, o otimizador de consulta em um banco de dados), o sistema operacional,
um conjunto de mquinas em um ambiente de rede, etc.
Os sensores (sensors) so responsveis por coletar informaes do elemento ge-
renciado. Estes dados podem ser os mais diversos possveis, por exemplo, o tempo de
resposta das requisies dos clientes, caso o elemento gerenciado seja um servidor Web.
As informaes coletadas pelos sensores so enviadas aos monitores (monitors) onde so
interpretadas, preprocessadas e colocadas em um nvel mais alto de abstrao, para ento
serem enviadas para a etapa seguinte no ciclo, a fase de anlise e planejamento (analyze
and planing). Nesta fase, tem-se como produto uma espcie de plano de trabalho, que
consiste de um conjunto de aes a serem executadas pelo executor (execute). O compo-
nente responsvel por fazer as alteraes no ambiente chamado de atuador (effectors).
Somente os sensores e atuadores possuem acesso direto ao elemento gerenciado. Durante
todo ciclo de gerenciamento autonmico, pode haver a necessidade de uma tomada de
deciso, dessa forma, faz-se necessrio tambm a presena de uma base de conhecimento
(knowledge), sendo que esta comumente mais explorada na fase de anlise e planeja-
mento [8].
Isso implementado utilizando dois ou mais ciclos de gerenciamento autonmico,
um ou mais ciclos de controle local e um global. Os ciclos de controle local tratam apenas
58
de estados conhecidos do ambiente local, sendo baseado no conhecimento encontrado no
prprio elemento gerenciado. Por esta razo, o ciclo local incapaz de controlar o com-
portamento global do sistema. O ciclo global, por sua vez, a partir de dados provenientes
dos gerenciadores locais ou atravs de um monitoramento a nvel global, podem tomar de-
cises e atuar globalmente no sistema. No entanto, a implementao das interaes entres
os diversos nveis existentes vai depender das necessidades e das limitaes da aplicao.
13.2.3. Monitoramento
O monitoramento corresponde a primeira fase do ciclo autonmico MAPE-K. Nesta
etapa, sensores so utilizados com a nalidade de obter dados que reitam mudanas
de comportamento do elemento gerenciado ou informaes do ambiente de execuo que
sejam relevantes ao processo de autogerenciamento. Os sensores so dispositivos de hard-
ware ou software que esto diretamente ligados ao componente que se deseja monitorar.
O tipo de informao coletada bem como o modelo do(s) monitor(es) empregados
so especcos para cada tipo de aplicao. Contudo, alguns requisitos so comuns entre
eles, tais como a ltragem, a escalabilidade, a dinamicidade e a tolerncia a falhas [23].
Um monitor deve prover ltragem, pois a quantidade de dados coletados pode crescer
muito rapidamente e consumir recursos de transmisso, processamento e armazenamento.
Grande parte desses dados podem ser de pouca relevncia e, portanto, descart-los no
implicaria em prejuzo. Considerando-se que um sistema pode crescer indenidamente,
contendo inmeros objetos sob monitoramento, a tarefa dos monitores no pode consumir
recursos e reduzir o desempenho do sistema. Em contrapartida, as mudanas no ambi-
ente ou no comportamento do sistema no podem afetar o servio de monitoramento [9].
Alm disso, falhas podem ocorrer e o monitor pode apresentar algum comportamento at-
pico ou mesmo parar de funcionar completamente. Dessa forma, devem ser levadas em
considerao provises como redundncia e mecanismos de recuperao de falhas dos
monitores.
13.2.3.1. Classicao de Sistemas de Monitoramento
Aplicaes autonmicas possuem requisitos de monitoramento diferentes, variando os
elementos que se deseja monitorar. De acordo com as caractersticas deste elementos
podem ser implementadas formas de monitoramento especcas. Em [16], Huebscher e
McCann identicaram dois tipos de monitoramento em sistemas autonmicos, classica-
dos de acordo com o tipo de sensor utilizado:
Monitoramento Passivo: No monitoramento passivo os dados obtidos de moni-
toramento so fornecidos pelo sistema sem necessidade de nenhuma alterao na
aplicao. Por exemplo, no Linux, informaes sobre uso de CPU e memria po-
dem ser coletados do diretrio /proc;
Monitoramento Ativo: No monitoramento ativo para que se possa fazer a captura
de dados necessrio alterar a implementao da aplicao ou sistema operacional.
So exemplo desse tipo de monitoramento, sensores que so inseridos na forma de
bytecodes em aplicaes Java.
59
Conforme observado nos trabalhos de [23] e [16], foi possvel constatar que o
monitor tambm pode ser classicado quanto estratgia utilizada:
Monitoramento orientado eventos: Eventos so aes que acontecem no sis-
tema e podem alterar o seu estado, por exemplo o processo ocioso, processo
em execuo, incio do processo, chegada de uma requisio, etc. Os eventos
acontecem instantaneamente e portanto nesse tipo de monitoramento cada evento
corresponde a um dado que transmitido para o monitor. Essa abordagem pode ser
aplicada nos casos em que a taxa de ocorrncia de eventos muito baixa. A des-
vantagem que o nmero de eventos gerados pode ser muito grande e informaes
redundantes e desnecessrias estariam sobrecarregando os recursos do sistema;
Monitoramento orientado ao tempo: Nessa estratgia, o monitor coleta os dados
de forma peridica, ou seja, um intervalo de tempo denido para que o monitor
consulte as informaes do ambiente em busca de eventos signicativos. A grande
diculdade encontrada nessa estratgia est em denir o melhor intervalo para a
realizao da coleta. A desvantagem nesse caso seria que informaes importantes
seriam perdidas durante esse intervalo;
Monitoramento autonmico: As duas estratgias acima podem ser intercaladas
conforme ocorrem as mudanas no ambiente. Por exemplo, se a taxa de ocorrncia
de eventos est elevada a melhor estratgia seria a orientada ao tempo. O tamanho
do intervalo de tempo na segunda estratgia tambm pode ser renado segundo uma
abordagem autonmica de acordo com as caractersticas do ambiente.
31.2.4. Anlise e Planejamento
A anlise vem aps o monitoramento no ciclo de gerenciamento MAPE-K, tendo como
fase seguinte o planejamento. Em geral estas duas fases so geralmente implementadas
em um nico componente. O processo de anlise e planejamento essencial para auto-
nomia do sistema, pois nele que so geradas as decises sobre quais modicaes sero
realizadas no sistema, que corresponde ao elemento gerenciado.
A fase de anlise e planejamento recebe como entrada os eventos e seus dados
gerados pelo sistema de monitoramento e gera como sada um conjunto de aes, tambm
chamado de plano de aes. Estas aes correspondem s operaes de recongurao
que, de acordo com o mecanismo de tomada de deciso, devem ser executadas no sistema
a m de manter o equilbrio do sistema considerando seus objetivos. Muitas tcnicas
podem ser empregadas na fase de anlise e planejamento, entre as quais se destacam
o uso de funes de utilidade, aprendizado por reforo e regras Evento-Condio-Ao
(ECA). Sendo esta ltima detalhada a seguir.
31.2.4.1. Anlise e Planejamento Baseados em Regras ECA
Regras do tipo evento-condio-ao (ECA Rules) determinam as aes a serem realiza-
das quando um evento ocorre desde que certas condies sejam satisfeitas. De acordo
com [5], ECA rules so especicaes declarativas de regras ou regulamentaes que
60
determinam o comportamento de componentes de aplicaes. Para cada evento so de-
nidos um conjunto de regras que podem gerar uma ou mais aes. Esses eventos tambm
podem satisfazer as condies de diferentes regras e algumas dessas regras podem gerar
aes que conitam entre si. Nem sempre esses conitos podem ser detectados durante a
escrita das regras, sendo muitas vezes descobertos em tempo de execuo.
Em ECA rules o evento especica quando as regras devero ser acionadas. A
condio a parte a ser vericada, podendo esta ser satisfeita ou no. E por m, a ao,
a qual representa a operao a ser realizada caso a condio seja satisfeita. So denidas
da seguinte forma:
on event if condition do action;
Figura 13.3. Denio de uma regra do tipo ECA.
31.2.5. Execuo de Aes de Recongurao
Na etapa de execuo do ciclo MAPE-K so realizadas reconguraes no sistema de
forma a restabelecer seu equilbrio. A nalidade da recongurao permitir que um sis-
tema evolua (ou simplesmente mude) incrementalmente de uma congurao para outra
em tempo de execuo, introduzindo pouco (ou, idealmente, nenhum) impacto sobre a
execuo do sistema. Desta forma, os sistemas (ou aplicaes) no necessitam ser nali-
zados, ou reiniciados, para que haja as mudanas.
A autocongurao (self-conguring) a caracterstica do sistema autnomo que
o permite ajustar-se automaticamente s novas circunstncias percebidas em virtude do
seu prprio funcionamento, de forma a atender a objetivos especicados pelos processos
de autocura, auto-otimizao ou autoproteo [5].
O processo de recongurao realizado pelos executores atravs dos atuadores.
Executores recebem como entrada um plano de aes gerado na etapa de anlise e pla-
nejamento e utiliza os atuadores pertinentes para implementar as aes de recongurao
descritas no plano. As reconguraes devem ser realizadas dinamicamente, sem impor
a necessidade de parar e/ou reiniciar o sistema.
Segundo [24], duas abordagens gerais tm sido utilizadas para atingir adaptao:
adaptao paramtrica e adaptao composicional. A adaptao paramtrica consiste na
alterao de variveis que determinam o comportamento do sistema. J a adaptao com-
posicional (ou estrutural) consiste na substituio de algoritmos ou partes estruturais de
um software, permitindo que este adote novas estratgias (algoritmos) para tratar situa-
es que no foram inicialmente previstas na sua construo.
31.2.5.1. Questes de Projeto de Mecanismos de Recongurao
O desenvolvimento de um mecanismo de recongurao dinmica no algo simples.
Diversos requisitos devem ser considerados a m de manter as caractersticas e funciona-
lidades do sistema [26], entre as quais destaca-se:
61
Separao de responsabilidades: No desenvolvimento de sistemas autonmicos,
a separao de responsabilidades permite que o cdigo funcional da aplicao (res-
ponsvel pelas regras de negcio) seja separado do cdigo responsvel pela adap-
tao. Isto simplica o desenvolvimento, a manuteno e o reuso do cdigo adap-
tativo;
Conabilidade: Um problema quando se modica um sistema em tempo de exe-
cuo a sincronizao entre reconguraes e execuo funcional do sistema.
A recongurao no deve prejudicar a funcionalidade do sistema. Lger et al.,
em [22], deniram um conjunto de propriedades a m de garantir a conabilidade
no contexto das reconguraes dinmicas em sistemas baseados em componen-
tes. Esse conjunto de propriedades foi baseado em transaes e denominado ACID
(Atomicidade, Consistncia, Isolamento e Durabilidade);
Preservao de consistncia: Quando a recongurao do sistema ocorre emtempo
de execuo, importante que a recongurao preserve a consistncia do sistema.
O estado do sistema interno deve ser mantido e as informaes trocadas entre os
componentes no devem ser perdidas;
Custo da recongurao: Em [11] o custo de recongurao denido como
uma medida dos efeitos negativos introduzidos pela recongurao. Esses efeitos
negativos incluem, por exemplo, a indisponibilidade temporria do servio, ou a
perturbao induzida em outros servios aps o possvel aumento do consumo de
recursos de rede durante a recongurao. A relao custo/benefcio deve ser ava-
liada.
31.3. Segurana em Redes de Computadores
O grande crescimento na quantidade de componentes e servios oferecidos nas atuais
redes de computadores tem aumentado o nvel de complexidade no trabalho de gerencia-
mento e administrao destas. Cada vez mais so integrados novos dispositivos s redes,
que requerem conectividade a qualquer momento e em qualquer lugar, alm de se carac-
terizarem por sua heterogeidade que diculta o processo de padronizao das aplicaes.
Ento se faz necessrio aplicar a ideia de CA s Redes de Computadores, atravs
da atribuio da capacidade para gerenciarem a si prprias, denominadas ento como
Redes Autonmicas [3]. Os servios e funes de gerenciamento da rede so executados
sem a necessidade de um gerente humano de maneira transparente para seus usurios,
havendo apenas a necessidade de objetivos e parmetros iniciais, os quais o sistema leva
em considerao. A rede deve ser capaz de aprender com as aes dos seus componentes
atravs da anlise dos resultados obtidos. A capacidade de adaptao e aprendizagem so
as caractersticas das redes autonmicas.
Neste cenrio, no se pode deixar de lado a segurana da informao, que re-
quisito fundamental para o bom funcionamento de qualquer sistema computacional, com-
preendendo o conjunto de medidas que visam preservar e proteger as informaes e os
sistemas de informao. Visto que essas redes esto conectadas quase sempre Internet,
as aplicaes residentes nelas podem sofrer com atividades maliciosas originadas a partir
de qualquer usurio conectado rede.
62
normal que o acesso rede mundial de computadores oferea a possibilidade de
descoberta e explorao de vulnerabilidades de forma bem rpida, quase sempre mais do
que a atualizao das ferramentas de segurana e da emisso de correes pelos fabrican-
tes de softwares. Ento o nmero de incidentes de segurana cresce muito rapidamente
juntamente com a quantidade de danos causados. No entanto, proporcionalmente tem
crescido tambm as pesquisas de novos mecanismos e tcnicas para aumentar o nvel de
segurana. Polticas de acesso, uso de rewalls, sistemas de deteco de intruso, sistemas
de preveno de intruso, honeypots, entre outros, tem sido essas contra medidas.
Em segurana da informao possvel identicar os seguintes propriedades b-
sicas, consideradas tambm os pilares para a segurana de redes [20]:
Condencialidade: Proteo dos dados contra divulgao no autorizada. A infor-
mao s deve estar disponvel para aqueles devidamente autorizados;
Integridade: Proteo dos dados contra modicao no autorizada. A informao
no deve ser destruda ou comprometida e os sistemas devem ter um desempenho
correto;
Disponibilidade: Proteo de acesso aos recursos da rede para que estejam dispo-
nveis quando requisitados pelas entidades autorizadas. Os servios e recursos do
sistema devem estar disponveis sempre que forem necessrios;
Autenticidade: Proteo dos recursos da rede contra acesso no autorizado.
necessrio a identicao dos elementos da transao;
No-repdio: Proteo contra negao falsa de aes que um usurio ou entidade
tenha feito. No possvel negar a existncia ou autoria de uma operao que criou,
modicou ou destruiu uma informao;
Auditoria: Implica no registro das aes realizadas no sistema, identicando os su-
jeitos e recursos envolvidos, as operaes realizadas, seus horrios, locais e outros
dados relevantes.
Essas propriedades guiam para a determinao de um foco no qual uma determi-
nada aplicao deve ser desenvolvida, a m de atender os requisitos de segurana especi-
cados pela prpria necessidade do ambiente em questo. No entanto, no apenas isto
que dita o escopo de uma aplicao para segurana de redes, sendo importante delimiar
a(s) fase(s) de proteo em que ela ir atuar.
31.3.1. Fases para Proteo de Redes
possvel destacar quatro fases para proteger a rede contra ataques [41]: Preveno (Pre-
vetion), Deteco (Detection), Defesa (Defense) e Forense (Forensics), como pode ser
visto na Figura 3.4. A preveno compreende todos os mtodos aplicados para evitar
ataques, a m de garantir a condencialidade e integridade dos dados, com a utilizao de
controles de acesso aos recursos da rede. Isso inclui tcnicas de autorizao e autentica-
o (servios de login), estabelecimento de conana, bem como criptograa e ltragem
63
de trfego (uso de rewall). importate ressaltar que preveno s possvel para ata-
ques conhecidos, mas h trabalhos sendo desenvolvidos no sentido de prever a ocorrncia
de ataques desconhecidos, como em [33] e [37].
Figura 13.4. Quatro fases de proteo [41].
Mecanismos de preveno so considerados sistemas de defesa em primeira linha,
ou seja, so responsveis pela primeira etapa na segurana de uma rede de computadores.
Normalmente essa defesa em primeira linha feita na fase de projeto da rede, a m de
desenvolv-la j de maneira segura e obter melhores resultados quando colocada em ope-
rao. Esses mecanismos so tipicamente implantados para controlar acesso a recursos e
informao que transita na rede.
Se a preveno falhar, deteco a prxima fase a lidar com um incidente. Detec-
o ento o processo de descoberta de um ataque ou da preparao para sua realizao,
ou quaisquer outras atividades maliciosas, desde um port scan at indcios de quebra de
senhas por tcnica de fora bruta. Isso normalmente feito pela anlise de dados cap-
turados por um sniffer, sendo este a interceptao e registro de dados que trafegam pela
rede.
Sistemas de deteco de intruso (IDS - Intrusion Detection Systems) so utili-
zados na fase de deteco. Eles realizam o monitoramente da rede, chamado de NIDS
(Network Based Intrusion Detection System), ou de um dispositivo conectado a ela, bem
conhecido como HIDS (Host Based Intrusion Detection System), com objetivo de en-
contrar a ocorrncia de algum ataque ou atividade maliciosa. Um IDS pode utilizar vrias
abordagens para identicar um ataque, sendo as mais conhecidas: Baseado em Assinatura
(Signature Based) e Baseado em Anomalia (Anomaly Based), como descrito em [18]:
Baseado em Assinatura: Monitora as atividades da rede, ou de um dispositivo
especco, procurando por ocorrncias de alguma intruso que comparada com
uma base de assinaturas, esta ltima contendo informaes de caractersticas de
ataques e atividades maliciosas;
Baseado em Anomalia: Inicialmente montado um perl que representa o com-
portamento normal da rede ou host, fase conhecida como treinamento. Posterior-
mente o sistema entra em fase de monitoramento, no qual utiliza vrias mtricas
para determinar se est havendo algum comportamento diferente do perl inicial,
caracterizando ento uma intruso.
64
Outro mecanismo encontrado na fase de deteco visto atravs das chamadas
Metodologias de Decepo, denidas em [15] como a criao de um ambiente falso para
enganar usurios mal intencionados. Elas so usadas quando aplicadas tcnicas no qual
o atacante interage com um recurso colocado como uma armadilha, propositalmente vul-
nervel, que emula os servios ou sistemas que realmente deveriam ser alvos de sua ao.
Tcnicas bastante utilizadas so com o uso de honeypots, denido por Spitzner [38] como
um recurso de rede cuja funo de ser sondado, atacado ou comprometido. Signica di-
zer que poder ser invadido, sendo uma mquina congurada a m de obter informaes
sobre o invasor. A inteno que o intruso ao realizar uma tentativa de invaso, na qual
a rede possua um honeypot em funcionamento, tenha a sensao de est interagindo com
uma mquina que exerce alguma funcionalidade e poder conseguir algum recurso.
Se umtrfego malicioso detectado, ento iniciado o processo ou fase de defesa.
Para que isso ocorra necessrio que o sistema implemente essas duas fases (deteco e
defesa), integrando mais de uma aplicao de segurana. Um exemplo o Sistema de
Preveno de Intruso (IDS - Intrusion Prevention System), no qual gera alguma resposta
a m de neutralizar o ataque, podendo integrar um IDS e um rewall, por exemplo.
Em alguns casos quando as fases anteriores de preveno e deteco falham e
o ataque foi bem sucedido, se faz necessrio uma anlise de todos os logs, no sentido
de aprender como os mtodos utilizados nos processos de deteco e defesa podem ser
melhorados para futuros incidentes. Sendo esta a fase chamada de forense, que tem
como objetivo realizar uma investigao para descobrir detalhes especcos de ataques,
apresentando resultados que contribuam de alguma maneira para a melhoria da proteo
da rede. Outro objetivo desta fase fornecer provas sucientes para permitir que o autor
do incidente de segurana seja processado. Para Pilli ES et al., em [31], as tcnicas de
forense de rede fornecem recursos para os investigadores rastrearem os atacantes.
Diante destas fases possvel caracterizar a atuao das aplicaes de segurana
de redes. Por sua vez, muitas das aplicaes utilizadas atualmente possuem problemas.
Junto a isso, os ataques redes de computadores vem se tornando cada vez mais sosti-
cados. Esses problemas sero detalhados a seguir.
31.3.2. Problemas Enfrentados
Zseby et al., em [41], arma que a segurana de redes necessita crucialmente de uma
maior ateno por parte do administrador e quase sempre de mais esforos e custos, pois
novos protocolos e aplicaes introduzem novas vulnerabilidades. Infelizmente, os me-
canismos utilizados para aumentar o nvel de segurana atualmente possuem alguns pro-
blemas, a saber:
Estrutura slida: Sistemas desenvolvidos para segurana possuem pouca exi-
bilidade, pois so desenvolvidos apenas para situaes isoladas. No possuem as
caractersticas de um sistema aberto. Tambm no so capazes de se integrar com
outros mecanismos de segurana existentes no ambiente;
Habilidade de defesa baixa: O escopo das atuais aplicaes de segurana limi-
tado. So desenvolvidas apenas para atender alguma das fases de proteo, sem ter
65
a habilidade para prover um mecanismo integrado que fornea maior capacidade de
segurana;
Sem autoadaptao: Aplicaes no tem a capacidade de mudar componentes
internos para se adaptarem s necessidades do ambiente em que se encontram a m
de conseguir prov segurana rede. Todo um processo de recongurao manual
preciso para manter a segurana;
Sem autoaprendizagem: Aplicaes no possuem a habilidade para aprender com
o tempo que se encontram em funcionamento, necessitando de interveno para
se atualizarem. No conseguem aprender com suas prprias aes, vericando os
resultados destas que foram providos rede, para uma anlise e melhorias futuras;
Sem autoevoluo: Alm de no possuirem capacidade para aprenderem, ainda
no implementam meios para que novos conhecimentos sejam agregados s tcni-
cas de defesa.
Para Atay e Masera, em [2], todos os mtodos de anlise de ameaas, vulnera-
bilidades e riscos necessitam atualizarem continuamente os seus conhecimentos sobre as
novas fraquezas encontradas nos ativos da rede. Isso servir para identicar como estas
fraquezas podem ser exploradas, para posteriormente denir e aplicar as contramedidas
necessrias. Esse um ciclo contnuo, pois novas avaliaes sero necessrias ao longo
do tempo.
No entanto, sabe-se que informaes sobre novos ataques no so imediatamente
divulgadas, pelos fabricantes ou pela comunidade que desenvolve o software, devido sua
sensibilidade. Isso ocorre devido essas informaes poderem ser utilizadas para explorar
mais ainda as vulnerabilidades, visto que usurios mal intecionados podem obt-las. Elas
so publicadas ento logo aps os fabricantes liberarem as correes. Os mtodos de
anlise de riscos citado por [2] devem refazer a avaliao de segurana dos sistemas le-
vando em considerao informaes de novos ataques quando forem divulgadas, ou com
a utilizao de tcnicas de inteligncia para deteco antes mesmo da divulgao.
Diante desta situao, Wang et al. [40] arma que a direo correta para o desen-
volvimento de aplicaes de defesa e segurana com a adoo de duas caractersticas: a
integrao e inteligncia. Integrao para possibilitar o gerenciamento de vrios recursos
de proteo em um ambiente de rede distribudo e a inteligncia para prov adaptao
ao ambiente, aumentar a ecincia de proteo baseado em seu conhecimento e no que
adquiriu e, por m, alcanar um equilbrio entre a aplicao de segurana e o ambiente de
rede.
Aliado aos problemas enfrentados pelos atuais sistemas de segurana, os ataques
a sistemas computacionais esto se tornando cada vez mais sosticados, imprevisveis,
frequentes e com uma maior quantidade de origens [2]. Como exemplo destes ataques
pode-se destacar os realizados com a utilizao de Botnets e os ataques de ltimo dia,
detalhados a seguir.
66
31.3.2.1. Botnets
De acordo com Rajab et al., em [35], Botnet uma rede de computadores comprometi-
dos controlados remotamente por um operador humano chamado de botmaster. Um bot
uma aplicao residente em um n integrante de uma Botnet com capacidade de se
autopropagar infectando outros hosts vulnerveis.
Botnets so plataformas de computao distribuda predominantemente usadas
para atividades ilegais com o objetivo de lanamentos de ataques de negao de ser-
vio distribudo (DDoS - Distributed Denial of Service), envio de spam, trojan e e-mails
phishing, distribuio ilegal de mdias e softwares piratas, roubo de informaes e de
recursos computacionais, realizao de fraudes e falsidade de identidade [7].
31.3.2.2. Ataques de ltimo Dia
Um ataque de ltimo dia, do ingls Zero-day Attack ou 0-Day Attack, tambm conhecido
como ataque de dia zero ou zero hora, aproveita vulnerabilidades que atualmente no tem
uma soluo ou ainda no so conhecidas [33] [37]. Normalmente, descoberto um bug
ou um problema em um software depois que ele foi liberado, sendo ento em seguida
oferecida uma correo destinada ao problema original. Um ataque de ltimo dia vai
aproveitar esse problema antes da correo ser criada. Na maioria dos casos, esse tipo
de ataque vai tirar proveito de um problema no conhecido pelos criadores do software e
seus usurios.
importante ressaltar que nem todos os ataques de ltimo dia realmente acon-
tecem antes dos produtores de software estarem cientes da vulnerabilidade. Em alguns
casos eles conhecem a vulnerabilidade, mas o desenvolvimento da correo pode deman-
dar um tempo elevado, em frente a complexidade do problema enfrentado. Neste sentido,
proteo de ltimo dia a capacidade de um sistema de segurana fornecer proteo con-
tra ataques de ltimo dia.
31.4. Segurana Autonmica em Redes de Computadores
Os sistemas de proteo das redes atuais esto baseados no paradigma da computao
interativa, ou seja, ca a cargo dos administradores humanos decidirem o que fazer e
como proteger os sistemas no caso de ocorrncias de ataques maliciosos ou erros em
cascata imprevistos [3]. Os sistemas que incorporam mais de uma fase para proteo de
rede, objetivando aumentar ainda mais o nvel de segurana, so mais complexos. Isso se
deve ao fato de possuirem mais componentes para atenderem os requisitos de cada fase.
Essa complexidade necessita de uma constante interveno humana especializada para a
correta utilizao do sistema.
Dessa maneira, interessante a utilizao de mecanismos autonmicos para auto-
matizar os processos de gerncia. A aplicao dos conceitos da CA segurana de redes
introduz no sistema a capacidade de autosegurana, atravs da qual servios e funes de
gerenciamento da segurana so executados sem a necessidade de um gerente humano, a
partir da denio de objetivos e parmetros iniciais fornecidos por seus administradores.
67
possvel destacar tambm que para tentar propror solues aos problemas des-
critos anteriormente (Seo 1.3.2), a arquitetura de sistemas autonmicos pode ser apli-
cada para o desenvolvimento de software voltado para defesa e segurana. O modelo
MAPE-K (Seo 1.2.2.1) oferece uma viso conceitual de como sistemas autonmicos
podem ser desenvolvidos para atender necessidades de segurana.
Sensores podem ser qualquer programa que verique ocorrncias de trfego ma-
licioso, independente de qual fase de proteo seja, coletando informaes relevantes da
rede para serem enviadas aos monitores. Exemplo de dados coletados podem ser, por
exemplo, o trfego destinado a honeypots, alertas de IDS, logs de rewall, etc. Os moni-
tores iro receber essas informaes e trat-las a m de extrair o que vem a ser relevante,
por exemplo, o endereo ip de origem do intruso, o protocolo utilizado pelo servio no
qual foi realizado o ataque, horrio/data da intruso, etc.
Os monitores enviaro as informaes necessrias para os componentes de anlise
e planejamento, que as utilizaro para seu processamento. Como se sabe, geralmente as
fases de anlise e planejamento so implementadas em um nico componente. O pro-
cessamento realizado por esse componente varia de acordo com a estratgia autonmica
adotada pelo administrador que inseriu os objetivos para o sistema. Um exemplo de pro-
cessamento utilizando ECA rules pode ser visto na Figura 3.5. Neste exemplo, na ocor-
rncia de um alerta de IDS (IDSAlert), se o IP de origem que gerou o alerta no estiver na
lista negra do rewall (BlackList !Contains SrcIpAddr), ser adicionado (Add SrcIpAddr
in BlackList).
on IDSAlert if BlackList !Contains SrcIpAddr do Add SrcIpAddr in BlackList;
Figura 13.5. Exemplo de recongurao.
A base de conhecimento pode ser utilizada pelo componente de anlise e plane-
jamento na adoo de estratgias para, por exemplo, no realizar aes anteriormente j
feitas. Na Figura 3.5 no sero adicionados endereos IP na lista negra que j estiverem
contidos. O componente de anlise e planejamento ter como sada um plano de ao a
ser executado pelo componente executor, que na Figura 3.5 a adio do endereo IP de
origem que gerou o alerta na lista negra.
Oexecutor ir aplicar as aes no elemento gerenciado atravs dos atuadores. Atu-
adores so responsveis por fazerem alteraes de congurao no elemento gerenciado,
ou seja, em alguma aplicao de segurana da rede. O objetivo em realizar as mudanas
nas conguraes aumentar o nvel de segurana. No exemplo da Figura 3.5 o atuador
ir interagir diretamente com a aplicao responsbel pela lista negra, o rewall.
Almda arquitetura de sistemas oferecida pela CA, visando o estado emque se en-
contram os atuais sistemas de segurana e tambm o crescimento e evoluo dos ataques
s redes de computadores, possvel relacionar a necessidade que este tipo de sistema
tem pelas propriedades dos sistemas autonmicos, destacando as propriedades de auto-
proteo (self-protecting), autocura (self-healing), autocongurao (self-conguring) e
autoaprendizagem (self-learning) [30], como visto a seguir.
68
Autoproteo: Refere-se propriedade do sistema de defender-se de ataques aci-
dentais ou maliciosos. Para tanto, o sistema deve ter conhecimento sobre potenciais
ameaas, bem como prov mecanismos para trat-las [5]. Para atingir essa proprie-
dade o sistema deve ter habilidade para antecipar, detectar, identicar e proteger o
elemento gerenciado contra ameaas;
Autocura: Responsvel por identicar e corrigir erros ou falhas. No contexto da
segurana de redes, o sistema autonmico deve ser capaz de detectar, diagnosticar
e consertar problemas resultantes de ataques a ativos de produo da rede. Uti-
lizando conhecimento sobre a congurao dos recursos da rede, o sistema deve
possuir um componente de diagnstico que deve analisar informaes que mostram
a ocorrncia de falhas ou danos causados por um ataque rede, para posteriormente
buscar uma soluo a ser tomada, aplic-la e depois testar se foi satisfatria. Essa
soluo poder ser, por exemplo, a substituio dinmica de recursos por suas rpli-
cas. importante ressaltar que o processo de cura deve ser realizado com mxima
transparncia para usurios legtimos da rede;
Autocongurao: Nesta propriedade fornecido a capacidade para os sistemas se
congurarem e recongurarem automaticamente de acordo com polticas de neg-
cio fornecidas por seus administradores, os quais denem o que deve ser feito e no
como fazer [5]. A m de automatizar o gerenciamento de congurao, um sistema
de segurana deve possuir capacidade de recongurao dinmica com o mnimo
de interveno humana;
Autoaprendizagem: Propriedade que fornece capacidade de aprendizado a partir
de dados sensoriados e tambm atravs de experincias e resultados obtidos em
aes anteriores. Propriedade fundamental para sistemas de segurana, visto que
ela oferece a capacidade para o sistema aprender a se defender de ataques antes
desconhecidos, ou, pelo menos, reconhecer trfego malicioso na rede para poste-
rior defesa. Um exemplo pode ser visto no trabalho desenvolvido em [32] (Seo
1.4.1.5), no qual atualizado a base de assinaturas de um IDS quando so desco-
bertos novos ataques.
Mesmo diante de vrias qualidades oferecidas pela CA, aplic-la s redes de com-
putadores e sua segurana no um processo trivial, h desaos a serem enfrentados para
alcanar o autogerenciamento. Segundo Agoulmine et al., em [1], o desao simpli-
car as tarefas de gerncia para o administrador, automatizando o processo de deciso.
Questes de segurana outro desao para o desenvolvimento de sistemas autonmicos,
visto que o emprego de autoaprendizagem e autoevoluo poder ocasionar a perda do
domnio humano sob a gerncia das decises tomadas pelo prprio sistema, havendo a
possibillidade de desvio dos objetivos iniciais inseridos. Com isso, no processo de de-
senvolvimento de software autonmico a fase de validao deve ser aplicada de maneira
rigorosa.
31.4.1. Sistemas de Segurana baseados em Computao Autonmica
Para dar uma viso com mais alto grau de realismo, sero vistos alguns trabalhos que
utilizam a CA como base para o desenvolvimento de suas propostas ou implementam
69
alguma das propriedades oferecidas pela CA. Inicialmente ser mostrado exemplos de
sistemas que tem fundamentao na CA ou que fornecem algumas propriedades da CA.
31.4.1.1. ISDS
Em [40] foi desenvolvido o ISDS (Intelligent Security Defensive Software), um modelo
de software de segurana baseado em CA. A estratgia do ISDS fazer o processo de
construo do software de segurana fornecendo a ele inteligncia. Em outras palavras,
construir um software utilizando o modelo ISDS fazer com que seus componentes se
modiquem dinamicamente de acordo com a situao de segurana atual da rede. Para
isto, o ISDS fornece conscincia do contexto.
O ISDS um modelo de sistema de defesa distribudo caracterizado por ser ex-
vel e autoadaptativo. Os domnios nos quais ele pode ser aplicado so principalmente no
gerenciamento de segurana em redes locais e na gerncia de segurana da informao na
Internet. A ideia do modelo que o sistema possa analisar as informaes do ambiente
e ajustar sua estrutura e maneira de agir dinamicamente. Ele consiste de alguns compo-
nentes bsicos, so eles: componente de comando, componente de execuo, componente
sensor, componente de polticas, componente de equipamento e outros auxiliares como
visto na Figura 3.6.
Figura 13.6. Framework conceitual do ISDS [40].
O componente de comando a principal parte do ISDS, tendo como funes: a
ativao dos componentes de polticas, sensor e equipamento, a execuo da tomada de
decio baseada no componente sensor, o gerenciamento do conjunto de componentes de
segurana e poltica, atualizao de novos componentes de segurana e polticas, veri-
cando e resolvendo conitos de polticas. J o componente de execuo trabalha como um
canal de comunicao entre as entidades de segurana e o componente de comando. Ele
se encarrega de ltrar, tratar e transmitir a mensagem para todos os outros componentes,
os fazendo trabalharem corretamente.
70
O componente de polticas se encarrega principalmente em fazer a manuteno do
conjunto de polticas, a tomada de deciso das polticas adequadas e tambm a passagem
do resultado da deciso. As informaes do resultado das decises tomadas sero pas-
sadas para o componente de equipamento que ento ir executar alguma ao. Por m,
o componente sensor coleta informaes do ambiente e as envia para o componente de
comando, levando em considerao o custo do sensoriamento de dois modos: emergncia
e timing, sendo o primeiro com maior prioridade em relao ao segundo.
31.4.1.2. Autonomic Security and Self-Protection based on Feature-Recognition with
Virtual Neurons
No trabalho desenvolvido em [6] foi apresentado um mecanismo de segurana auton-
mico baseado em neurnios virtuais e no reconhecimento de caractersticas. Sua abor-
dagem trabalha para detectar automaticamente vrios problemas de segurana que atual-
mente so difceis de realizar defesa. Atravs de simulao e diferentes estudos de caso,
resultados mostram que esta soluo vivel.
Os neurnios virtuais so desenvolvidos de forma anloga aos neurnios dos ani-
mais, como visto na Figura 3.7. A ideia que eles sejam distribudos de maneira a perce-
ber modicaes no ambiente e reagir a estmulos. Esse neurnio virtual na realidade
um simples software com capacidade de cincia de contexto, a m de analisar informa-
es do contexto e estar ciente de eventuais surgimentos de ataques.
Figura 13.7. Neurnio Virtual [6].
No neurnio virtual, o componente Information Collector captura vrias infor-
maes de contexto, tais como uso de memria e processador, status dos processos e
informaes de trfego da rede. So considerados vizinhos os neurnios que se conectam
diretamente, atravs do Neighbor Communicator. Existe um outro componente chamado
de Feature Recognizer, seu funcionamento baseado no conhecimento sobre infomaes
que caracterizam um ataque (baseado em assinaturas). Essas informaes so passados
para o Feature Recognizer pelo Information Collector do prprio neurnio e dos seus vi-
zinhos, atravs do Neighbor Communicator. Os neurnios virtuais podem ser facilmente
distribudos, pois o pacote de instalao compacto (tamanho pequeno), eles exigem
poucos recursos computacionais e so de fcil instalao nos hosts.
71
Esses neurnios virtuais so distribudos em uma arquitetura hierrquica e Par-a-
par (P2P - Peer-to-peer), como visto na Figura 3.8. A estrutura P2P opera baseada nas
relaes com neurnios vizinhos, tendo a comunicao entre eles atravs de passagem de
mensagens. Aarquitetura hierrquica utilizada para aumentar a ecincia na propagao
das mensagens por grupo de neurnios, chamados de clulas. Emcada clula umneurnio
eleito como neurnio-chefe, o algoritmo de eleio leva em considerao os recursos
computacionais e velocidade de comunicao do host.
Figura 13.8. Estrutura de organizao hierarquica e P2P dos neurnios virtuais [6].
Na organizao hierrquica, um neurnio-chefe eleito como o chefe de alto nvel
para outros neurnios-chefes. Este procedimento repetido at existir umnico neurnio-
chefe de maior nvel sobre os demais. Se ocorrer alguma falha em algum neurnio-chefe
de uma clula, um outro neurnio desta mesma clula ir assumir o papel de neurnio-
chefe, atravs de uma nova eleio. Nessa organizao hierrquica as mensagens so
entregues de maneira mais eciente.
O mecanismo de segurana empregado por este sistema distribudo feito na de-
teco de mensagens com dados ou mensagens ilegais. Primeiramente as origens dos
ataques so rastreadas para identicar e localizar o atacante. Depois o trfego ilegal ori-
ginado por ele bloqueado, ou seja, todos os neurnios iro receber mensagens para
descartarem trfego que tenha como origem um usurio malicioso identicado. A recon-
gurao de recursos feita neste momento para realizao da defesa pelo sistema. Para
realizar a deteco e posterior defesa foi desenvolvido um mecanismo (caracterstica ou
assinatura) para cada tipo de ataque, dentre esses: Eavesdropping, Replay, Masquerading,
Spoong e Negao de Servio (DoS - Denial of Service).
31.4.1.3. Self-Conguration of Network Security
Este trababalho [4] apresenta uma abordagem de autocongurao para controlar e ge-
renciar os mecanismos de segurana em redes de grande porte. Nela o sistema automati-
camente congura os mecanismos de segurana e modica as conguraes dos recursos
e suas polticas em tempo de execuo. Para mostrar sua viabilidade foi implementado
o AND (Autonomic Network Defense System). AND um sistema que pode detectar
ataques de rede conhecidos ou desconhecidos (ataques de ltimo dia) e proativamente
prevenir ou minimizar impactos causados em servios da rede.
72
O AND foi desenvolvido sobre o framework AUTONOMIA [13], sendo uma ex-
tenso focada em estratgias e mecanismos para detectar e proteger-se de ataques de rede.
O AUTONOMIA possui dois mdulos de software, so eles: Component Management In-
terface (CMI) e Component Runtime Manager (CRM). O CMI utilizado para especicar
as conguraes e polticas associadas com cada componente (de hardware ou software).
E o CRM que gerencia as operaes dos componentes usando as polticas denidas no
CMI. Mais detalhes sobre o framework AUTONOMIA podem serem vistos em [14].
As principais extenses do AND so os mdulos de Monitoramento Online (On-
line Monitoring), Seleo de Caracterstica (Feature Selection), Anlise de Anomalia
(Anomaly Analysis) e o de Ao (Action Module), como visto na Figura 3.9. poss-
vel observar que essa arquiteura baseada no MAPE-K.
Figura 13.9. Arquitetura do AND [4].
O monitoramento online coleta os dados trafegados na rede e operaes realiza-
das em computadores atravs de ferramentas especcas e arquivos de log gerados por
sistemas operacionais. O modelo de seleo de caracterstica ir ltrar os dados moni-
torados a m de encontrar informaes ou caractersticas relevantes para serem passadas
para o mdulo seguinte. No mdulo de anlise de anomalias executada uma funo
para quanticar se existe um desvio do perl padro da rede ou de algum sistema, caso
haja, considerado uma anomalia e o mdulo de ao ir executar aes adequadas. O
mdulo de ao ir, resumidamente, restringir o acesso aos recursos atacados e poste-
riosmente tentar desinstalar cdigos maliciosos que esto executando em computadores
comprometidos da rede.
31.4.1.4. Qualidade de Proteo
Trabalho iniciado em [10] teve como resultado um novo termo em [12] chamado de Qua-
lidade de Proteo (QoP - Quality-of-Protection). Ele um framework proativo para
defesa de redes que pode ser integrado com os j existentes protocolos de Qualidade de
Servio (QoS - Quality-of-Service). O objetivo prov servios diferenciados para uxos
de trfegos de acordo com seu grau de anormalidade.
Para isso foi criado uma nova mtrica chamada de Distncia de Anormalidade
(DA), como visto na Figura 3.10, que pode ser usada para classicar o trfego em nor-
mal, incerto (trfego suspeito) e anormal (trfego malicioso). Existe uma funo Delta
73
que mostra o quanto mais prximo o trfego est de normal ou anormal, podendo ser
classicado ento como provavelmente normal ou provavelmente anormal.
Figura 13.10. Distncia de Anormalidade [10].
A ideia que a mtrica AD seja usada em conjunto com protocolos de QoS para
aumentar a prioridade de trfegos considerados normais e diminuir a prioridade de tr-
fegos anormais. Testes foram realizados com ataques de DDoS e propagao de Worms.
Com isso foi possvel demonstrar o quanto a abordagem proposta pode detectar e reduzir
o impacto causado pelos ataques.
31.4.1.5. Propriedades de Computao Autonmica em Sistemas de Segurana
Alguns trabalhos se cacterizam por fornecer alguma(s) das propriedades autonmicas de
maneira isolada, mesmo no tendo como base a CA. Ou seja, foram desenvolvidos sem
seguir os conceitos da CA, mas provem algum mecanismo que se qualica dentre alguma
das propriedades autonmicas. Sistemas como estes no so considerados autonmicos.
Foi desenvolvido em [39] um esquema de segurana para atualizao de regras
de rewall baseado no trfego de uma honeynet (autocongurao e autoaprendizagem).
Para [38] honeynets so mltiplos honeypots juntamente com um rewall para limitao
e log de trfego. No esquema h um mdulo de anlise de dados que oportunamente
descobre novos ataques. Este mdulo analisa o trfego gerado pelos logs da honeynet e
com a utilizao de minerao de dados ele cria dinamicamente novas regras de rewall
passando-as para o mdulo de aprendizagem de regras, que as ltra eliminando incoe-
rncias entre as regras e, por m, ele as aplica. Dessa maneira o rewall continua enri-
quecendo suas estratgias melhorando sua capacidade para se defender de novos ataques,
inclusive ataques de ltimo dia.
A ferramenta Honeycomb [21] tem como objetivo automatizar a gerao de as-
sinaturas de ataques para sistemas de deteco de intruso a partir de logs gerados por
honeypots (autoaprendizagem). Na verdade esta ferramenta trata-se de um plugin a ser
utilizado junto ao honeyd [34], que um framework de honeypots de baixa interatividade
[38]. A implementao do Honeycomb gera assinaturas no formato Bro [29] e Snort [36].
Sua inteno ser utilizado para criar as assinaturas de ataques em tempo de execuo
74
(autocongurao), atividade que normalmente realizada manualmente por especialistas
de segurana aps o registro das atividades maliciosas nos logs.
No caso do SweetBait [32], foi desenvolvido um sistema automatizado de prote-
o que utiliza honeypots de baixa e alta interatividade para reconhecer e capturar trfego
malicioso. Com base nos logs gerados, aps descartar padres da lista branca, ele auto-
maticamente cria assinaturas de ataques (autoaprendizagem), componente implementado
utilizando o Honeycomb. Para prov um baixo tempo de resposta ao ataque ele distribui
imediatamente assinaturas para IDSs (autocongurao), aps sua gerao. Paralela-
mente a isto, as assinaturas so renadas continuamente a m de aumentar sua preciso
e diminuir falsos positivos (auto-otimizao). Este trabalho extendido e surge ento o
Argos [33] que emprega uma caracterstica mais ampla, a propriedade de autoproteo,
por reagir proativamente contra ataques.
31.5. Concluso
Em 2001 a IBM produziu um manifesto no qual alertou a diculdade de gerenciamento
dos sistemas computacionais atuais e apontou a autonomia dos sistemas como a alter-
nativa para a soluo deste problema. Neste captulo foi apresentado a denio e as
principais caractersticas de uma nova abordagem para o desenvolvimento de sistemas
que provem autonomia, a Computao Autonmica. Na qual envolve uma mudana no
modo de projetar sistemas computacionais.
A ideia por traz dessa abordagem desenvolver software autogerencivel, tendo
pouca ou nenhuma interveno humana para manter-se, baseado apenas em polticas de
alto nvel denidas pelo supervisor e no conhecimento adquirido ao longo do tempo.
Uma srie de propriedades autonmicas so utilizadas por esta abordagem para diminuir
ou eliminar a interveno humana sob a gerncia dos sistemas computacionais, tais como:
autocura, autoproteo, auto-otimizao, autoaprendizagem, autocongurao, etc. Neste
sentido ser colocado sob responsabilidade das prprias mquinas a tarefa de gerencia-
mento.
Foi mostrado tambm neste captulo que as redes de computadores so cenrios
onde a CA pode ser facilmente aplicada, principalmente pelo crescimento resultante da
Internet. Em particular, apresentou-se a aplicabilidade de CA em um ambiente bem espe-
cco, a gerncia da segurana de redes. Para isto foi explicitado a necessidade da segu-
rana de redes por mecanismos autonmicos e maneiras de como possvel implement-
los. Trabalhos j realizados dentro da temtica foram descritos a m de oferecer uma
viso mais prtica.
Finalizando, pesquisas mostram que a direo correta para as aplicaes de segu-
rana a adoo de integrao e inteligncia, ento isso mostra que os recursos fornecidos
pela CA o caminho mais vivel para solucionar problemas existentes nas redes de com-
putadores e de maneira mais especca, como visto, na segurana destas.
Agradecimento: O desenvolvimento deste trabalho foi viabilizado pelo apoio
nanceiro concedido pela Fundao de Amparo Pesquisa e ao Desenvolvimento Cien-
tco e Tecnolgico do Maranho (FAPEMA).
75
Referncias
[1] Agoulmine, N., Balasubramaniam, S., Botvich, D., Strassner, J., Lehtihet, E. e Don-
nelly, W. (2006), Challenges for Autonomic Network Management, In 1st IEEE
International Workshop on Modelling Autonomic Communications Environments -
MACE.
[2] Atay, S. e Masera, M. (2009), Challenges for the security analysis of Next Genera-
tion Networks, In Proceedings of the Sixth International Conference on Broadband
Communications, Networks, and Systems - BROADNETS.
[3] Braga, T. R. M., Silva, F. A., Ruiz, L. B., and ao, H. P. A. (2006), Redes Au-
tonmicas, In XXIV Simpsio Brasileiro de Redes de Computadores e Sistemas
Distribudos - SBRC, Sociedade Brasileira de Computao (SBC).
[4] Chen, H., Al-Nashif, Youssif B., Qu, G. e Hariri, S. (2007), Self-Conguration of
Network Security, In Proceedings of the 11th IEEE International Enterprise Distri-
buted Object Computing Conference, p. 97-108.
[5] Corra, S. e Cerqueira, R. (2009), Computao Autnoma: Conceitos, Infra-
estruturas e Solues em Sistemas Distribudos, In XXVII Simpsio Brasileiro de
Redes de Computadores e Sistemas Distribudos - SBRC, Sociedade Brasileira de
Computao (SBC).
[6] Dai, Y., Hinchey, M., Qi, M. e Zou, X. (2006), Autonomic Security and Self-
Protection based on Feature-Recognition with Virtual Neurons, In Proceedings
of the 2nd IEEE International Symposium on Dependable, Autonomic and Secure
Computing.
[7] Feily, M., Shahrestani, A. e Ramadass, S. (2009), A Survey of Botnet and Botnet
Detection, In Third International Conference on Emerging Security Information,
Systems and Technologies.
[8] Gonalves, J. F. (2010), Introduo Computao Autonmica e sua Aplicao em
Ambientes Computacionais Distribudos, Graduate thesis, Universidade Federal do
Maranho, Bacharelado em Cincia da Computao.
[9] Goodloe, A. e Pike, L. (2010), Monitoring distributed real-time systems: A survey
and future directions, NASA Langley Research Center.
[10] Guangzhi Qu, Hariri, S., Jangiti, S., Rudraraju, J., Seungchan Oh, Fayssal, S.,
Guangsen Z. e Parashar, M. (2004), Online Monitoring and Analysis for Self-
Protection against Network Attacks, In Proceedings of the International Conference
on Autonomic Computing, p. 324-325.
[11] Hallsteinsen, S. (2010), Madam-theory of adaptation, Technical report, SINTEF
ICT.
[12] Hariri, S., Guangzhi Qu, Modukuri, R., Chen, H. e Yousif, M. (2005), Quality-of-
Protection (QoP) - An Online Monitoring and Self-Protection Mechanism, IEEE
Journal on Selected Areas in Communications, v. 23, n. 10, p. 1983-1993.
76
[13] Hariri, S., Khargharia, B., Chen, H., Yang, J., Zhang, Y., Parashar, M. e Liu, H.
(2006), The autonomic computing paradigm, Cluster Computing, Springer, v. 9,
p. 5-17.
[14] Hariri S., Xue L., Chen, H., Zhang, M., Pavuluri, S. e Rao, S. (2003), AUTONO-
MIA: an autonomic computing environment, In Proceedings of the IEEE Internati-
onal Performance, Computing, and Communications Conference, p. 61-68.
[15] Hongli, Z. e Qassrawi, Mahmound T. (2010), Deception Methodology in Virtual
Honeypots, In Second International Conference on Networks Security, Wireless
Communications and Trusted Computing, Wuhan, China, p. 462-467.
[16] Huebscher, Markus C. e McCann, Julie A. (2008), A survey of autonomic compu-
ting - degrees, models, and applications, ACM Computing Surveys, v. 40, n. 3.
[17] IBM (2003), An architectural blueprint for autonomic computing, IBM Press
Prentice-Hall.
[18] Kabiri, P. e Ghorbani, Ali A. (2005), Research on Intrusion Detection and Res-
ponse: A Survey, International Journal of Network Security, v. 2, n. 1, p. 84-102.
[19] Kephart, J.O. e Chess, D.M. (2003), The Vision of autonomic computing, Com-
puter, IEEE Computer Society, p. 41-50.
[20] Krause, M. and Tipton, H. F. (1999), Handbook of Information Security Manage-
ment, Auerbach Publications, http://www.cccure.org/Documents/HISM/.
[21] Kreibich, C. e Crowcroft, J. (2004), Honeycomb - Creating Intrusion Detection Sig-
natures Using Honeypots, SIGCOMM Computer Communication Review, ACM,
v. 34, ed. 1.
[22] Lger, M., Ledoux, T. e Coupaye, T. (2007), Reliable dynamic recongurations in
the fractal component model, In Proceedings of the 6th international workshop on
adaptive and reective middleware: held at the ACM/IFIP/USENIX International
Middleware Conference - ARM, New York, NY, USA, p. 1-6.
[23] Mansouri-samani, M. (1995), Monitoring of Distributed Systems, PhD thesis,
University of London, Imperial College of Science, Technology and Medicine.
[24] McKinley, P. K., Sadjadi, S. M., Kasten, E. P. e Cheng, B. H. C. (2004), Composing
adaptive software, IEEE Computer Society, p. 56-64.
[25] Murch, R. (2004), Autonomic computing, IBM Press Prentice-Hall.
[26] Palma, N. D., Laumay, D. P. e Bellissard, L. (2001), Ensuring dynamic recon-
guration consistency, In 6th International Workshop on Component-Oriented Pro-
gramming - WCOP, p. 18-24.
[27] Parashar, M. e Hariri, S. (2005), Autonomic computing: An overview, Unconven-
tional Programming Paradigms, Springer Verlag, p. 247-259.
77
[28] Parashar, M. e Hariri, S. (2007), Autonomic computing: concepts, infrastructure,
and applications, CRC Press.
[29] Paxson, V. (1999), Bro: A System for Detecting Network Intruders in Real-Time,
Computer Networks, v. 31, n. 23-24, p. 2435-2463.
[30] Poslad, S. (2009), Autonomous Systems and Articial Life, Ubiquitous Compu-
ting: Smart Devices, Environments and Interactions, John Wiley & Sons, Ltd., p.
317-341.
[31] Pilli, E. S., Joshi, R.C. e Niyogi, R. (2010), Network forensic frameworks: Survey
and research challenges, Digital Investigation, Elsevier, p. 1-14.
[32] Portokalidis, G. e Bos, H. (2007), SweetBait: Zero-hour worm detection and con-
tainment using low- and high-interaction honeypots, Computer Networks, Elsevier,
v. 51, ed. 5, p. 1256-1274.
[33] Portokalidis, G., Slowinska, A. e Bos, H. (2006), Argos: an Emulator for Finger-
printing Zero-Day Attacks for advertised honeypots with automatic signature gene-
ration, In Proceedings of the EuroSys, p. 15-27.
[34] Provos, N. (2004), A virtual honeypot framework, In Proceedings of the 13th con-
ference on USENIX Security Symposium, v. 13, Berkeley, CA, USA.
[35] Rajab, M., Zarfoss, J., Monrose, F. e Terzis, A. (2006), A multifaceted approach to
understanding the botnet phenomenon, In Proceedings of the 6th ACM SIGCOMM
Conference on Internet Measurement - IMC, p. 41-52.
[36] Roesch, M. (1999), Snort: Lightweight Intrusion Detection for Networks, In Pro-
ceedings of the 13th Conference on Systems Administration, p. 229-238.
[37] Song, J., Kwon, Y. e Takakura, H. (2008), A Generalized Feature Extraction
Scheme to Detect 0-Day Attacks via IDS Alerts, In International Symposium on
Applications and the Internet - SAINT, Turku, Finlndia.
[38] Spitzner, L. (2002), Honeypots: Denitions and Value of Honeypots, SANS An-
nual Conference.
[39] Wang, B., Zhu, P., Wen, Q. e Yu, X. (2009), A Honeynet-based Firewall Scheme
with Initiative Security Strategies, In International Symposium on Computer
Network and Multimedia Technology - CNMT, p. 1-4.
[40] Wang, K., Wang, J., Shen, L. e Han, Z. (2010), An Intelligent Security Defensive
Software Scheme and Realization, In Third International Symposium on Intelligent
Information Technology and Security Informatics - IITSI, p. 793-796.
[41] Zseby, T. Pfeffer, H. e Steglich, S. (2009), Concepts for Self-Protection, Autono-
mic Computing and Networking, Springer Science, p. 355-380.
78

Captulo
4

Linked Data: da Web de Documentos para a
Web de Dados
Danusa R. B. Cunha, Bernadette F. Lscio, Damires Souza
Abstract
The term Linked Data refers to a set of best practices for publishing and connecting
structured data on the Web with the purpose of creating a Web of Data. Recently, a
significant number of datasets have been published adhering to the Linked Data
principles and numerous efforts are underway to build applications for exploit this
Web of Data. In this context, during this course, we present the fundamental
concepts of Linked Data, as well as the theoretical basis of how to publish and to
consume data available on the Web of Data. We also present some applications for
visualization and consume of Linked Data and we discuss the main difficulties and
challenges in this research area.

Resumo
O termo Linked Data refere-se a um conjunto de prticas para publicar e conectar
dados estruturados na Web, com o intuito de criar uma Web de Dados.
Recentemente, um grande volume de dados denidos de acordo com o padro Linked
Data tem sido publicado, com isso, muitos esforos esto sendo feitos para construir
aplicaes com o objetivo de facilitar a explorao de tais dados. Neste cenrio, este
minicurso apresenta os conceitos relacionados ao termo Linked Data, bem como
prov aos participantes um embasamento prtico de como publicar e consumir
dados na Web de Dados. Alm disso, so apresentadas as aplicaes usadas para
visualizao e consumo dos dados Linked Data e, por fim, discute as principais
dificuldades e desafios nessa rea de pesquisa.
79


4.1 Introduo
A Internet contempornea, nos moldes da World Wide Web, vive um constante
processo de evoluo e tem revolucionado a forma como criamos contedo e
trocamos informaes. A Web organiza as informaes disponveis na Internet por
meio de hipertexto e torna a interao do usurio com a rede mundial mais amigvel.
Com isso, possibilita um ambiente de compartilhamento de documentos oriundos de
diversas reas do conhecimento. Entretanto, tais contedos geralmente seguem regras
apenas sintticas, com objetivos de apresentao, no permitindo que se consiga
facilmente extrair semntica dos mesmos, sem que para isso seja feito um grande
esforo de implementao. Considerando isso, a Web atual pode ser classificada
como sinttica e o processo de interpretao dos contedos disponibilizados fica
geralmente a cargo dos usurios [Costa & Yamate 2009].
Em sua maior parte, os dados na Web ainda so organizados para serem lidos
ou compreendidos por humanos e no por agentes de software. Para que um agente
de software possa entender e interpretar um dado, necessrio processar a semntica
envolvida naquele dado, num determinado contexto. Neste escopo, semntica diz
respeito atribuio de significado a elementos, dados ou expresses que precisam
ser interpretados numa dada situao [Souza 2009]. No cenrio da Web, isso
representa atribuir significado aos dados interligando-os com outros conjuntos de
dados ou outros domnios de conhecimento, conseguindo, assim, criar uma relao
de significncia entre os contedos publicados na Internet de modo que seja
perceptvel tanto pelo usurio quanto pelos agentes de software. Essa nova viso da
Web vem sendo denominada de Web Semntica (Semantic Web) [Lee et al. 2001].
A Web Semntica considerada uma extenso da Web atual cujo objetivo
principal facilitar a interpretao e integrao dos dados na Web. Como parte do
desenvolvimento da Web Semntica, surgiu o conceito de Linked Data (dados
ligados) que pode ser definido como um conjunto de boas prticas para publicar e
conectar conjuntos de dados estruturados na Web, com o intuito de criar uma Web
de Dados [Bizer et al. 2009]. Estas prticas so fundamentadas em tecnologias
Web, como HTTP (Hypertext Transfer Protocol) e URI (Uniform Resource
Identier), com o objetivo de permitir a leitura dos dados conectados
semanticamente, de forma automtica, por agentes de software. A Web de Dados
cria inmeras oportunidades para a integrao semntica de dados, motivando o
desenvolvimento de novos tipos de aplicaes e ferramentas, como navegadores e
motores de busca.
Este captulo apresenta os conceitos bsicos para publicao e consumo de
dados na Web de acordo com os padres de Linked Data e est organizado como
segue. A seo 2 traa um paralelo entre a Web clssica e a Web de Dados. A Seo
3 apresenta uma viso geral sobre o tema Linked Data, introduzindo os princpios
que regem esse conjunto de prticas. Alm disso, so explicados os seguintes
aspectos: (i) a nomeao de recursos atravs de URIs; (ii) como possvel utilizar
URIs para prover navegao entre os recursos; (iii) como disponibilizar os dados
atravs do modelo RDF, mostrando os benefcios oriundos desse modelo e (iv) como
links entre os recursos so criados e identificados. A Seo 4 discute os aspectos
bsicos que devem ser considerados para a publicao de dados segundo os
80

princpios do Linked Data. Para tal, aborda questes de formatao e estruturao de
dados e, por fim, apresenta um conjunto de padres e diretrizes a serem seguidos
com o intuito de tornar possvel a publicao e interligao dos dados. A Seo 5
apresenta exemplos de aplicaes existentes e, finalmente, a Seo 6 tece
consideraes sobre o tema exposto, apontando benefcios de seu uso e dificuldades
ainda existentes.

4.2. Web de Documentos versus Web de Dados
Para um melhor entendimento sobre a Web de Dados, pode-se estabelecer um
paralelo entre a Web de Documentos (a Web atual) e a Web de Dados. A primeira
faz uso de navegadores HTML (HyperText Markup Language) para acessar dados na
enquanto que na segunda os dados so acessados a partir de navegadores RDF. Na
Web de Documentos hiperlinks so usados para navegar entre as pginas, enquanto
que na Web de Dados os links RDF so usados para acessar dados de diversas fontes.
A Web de Documentos baseada em um conjunto de padres, incluindo:
um mecanismo de identicao global e nico, as URIs; um mecanismo de acesso
universal, o HTTP e um formato padro para representao de contedo, o HTML.
De modo semelhante, a Web de Dados tem por base alguns padres, como: o
mesmo mecanismo de identicao e acesso universal usado na Web de
documentos (as URIs e o HTTP); um modelo padro para representao de dados,
o RDF e uma linguagem de consulta para acesso aos dados, a linguagem SPARQL.
A seguir esses padres so apresentados.
URIs Uniform Resource Identiers
URI uma cadeia de caracteres compacta usada para identificar ou denominar um
recurso na Internet, onde um recurso pode ser um documento html, uma figura ou
uma pessoa. O principal propsito desta identificao permitir a interao com
representaes do recurso atravs de uma rede, tipicamente a Web, usando
protocolos especficos. Uma URI pode ser classificado como um localizador URL
(Uniform Resource Locator) ou um nome URN (Uniform Resource Name), ou
ainda como ambos. O URN define a identidade de um item, enquanto que o URL
nos d um mtodo para encontr-lo. Tecnicamente URL e URN funcionam como
IDs de recursos, no entanto, muitos conjuntos no podem ser categorizados como
somente um ou outro, por que todas as URIs podem ser tratados como nomes, e
alguns conjuntos integram aspectos de ambas ou de nenhuma das categorias.
No contexto Linked Data, URIs so usadas para identicar objetos e
conceitos, permitindo que eles sejam dereferenciados para obteno de informaes
a seu respeito. Assim, o dereferenciamento de uma URI resulta em uma descrio
RDF do recurso identicado. Por exemplo, a URI
http://www.w3.org/People/Berners-Lee/card#i identica o pesquisador Tim
Bernes-Lee.
HTTP HyperText Transfer Protocol
HTTP um protocolo de aplicao responsvel pelo tratamento de pedidos e
respostas entre cliente e servidor na Web. Ele surgiu da necessidade de distribuir
informaes pela Internet e, para que essa distribuio fosse possvel, foi
81

necessrio criar uma forma padronizada de comunicao entre os clientes e os
servidores da Web. Com isso, o protocolo HTTP passou a ser utilizado para a
comunicao entre computadores na Internet e a especificar como seriam realizadas
as transaes entre clientes e servidores, atravs do uso de regras bsicas.
O HTTP utiliza o modelo cliente-servidor, como a maioria dos protocolos
de rede, baseando-se no paradigma de requisio e resposta. Um programa
requisitante (cliente) estabelece uma conexo com um outro programa receptor
(servidor) e envia-lhe uma requisio, contendo a URI, a verso do protocolo, uma
mensagem contendo os modificadores da requisio, informaes sobre o cliente e,
possivelmente, o contedo no corpo da mensagem. O servidor responde com uma
linha de status (status line) incluindo sua verso de protocolo e com os cdigos de
erro informando se a operao foi bem sucedida ou no, seguido pelas informaes
do servidor, informaes da entidade e possvel contedo no corpo da mensagem.
Aps o envio da resposta pelo servidor, encerra-se a conexo estabelecida.
RDF Resource Description Framework
A utilizao de um modelo padro para representao de dados, como o RDF, torna
possvel a implementao de aplicaes genricas capazes de operar sobre o espao
de dados global [Heath & Bizer 2011]. O modelo RDF baseado no conceito de
grafo, extensvel e possue um alto nvel de expressividade, facilitando, dessa
forma, a interligao entre dados de diferentes fontes.
Em RDF, um recurso pode estar relacionado com dados ou com outros
recursos atravs das sentenas, as quais so estruturadas no formato sujeito +
predicado + objeto, onde:
Sujeito: Tem como valor o recurso sobre o qual se quer escrever uma sentena.
Todo recurso deve ser capaz de ser identificado unicamente.
Predicado: Especifica um relacionamento entre um sujeito e um objeto. O
predicado especificado por meio de propriedades, que so relaes binrias
geralmente nomeadas por um verbo e permitem relacionar um recurso a dados ou
a outros recursos. Uma propriedade tambm um recurso e, portanto, deve ter um
identificador nico.
Objeto: Denomina o recurso ou dado que se relaciona com o sujeito. O valor de
um objeto pode ser um recurso ou um literal, que pode ser um valor numrico ou
uma cadeia de caracteres.
A Figura 4.1 mostra alguns exemplos de triplas RDF.


Figura 4.1. Triplas RDF.
82

As triplas representadas na Figura 4.1 contm informaes sobre dois recursos.
A primeira tripla informa que o recurso p91002043177 possui nome Berna Farias.
A segunda tripla descreve um segundo recurso CK120, cujo nome Banco de
Dados I. A terceira tripla descreve um relacionamento entre os dois recursos criados
atravs do predicado EnsinadoPor. Cada tripla faz parte da Web de Dados e pode
ser usada como ponto de partida para explorar esse espao de dados. Triplas de
diferentes fontes podem ser facilmente combinadas para formar um nico grafo.
Alm disso, possvel usar termos de diferentes vocabulrios para representar os
dados. O modelo RDF ainda permite a representao de dados em diferentes nveis
de estruturao, sendo possvel representar desde dados semiestruturados a dados
altamente estruturados.
SPARQL
Assim como os sistemas de bancos de dados relacionais fazem uso do SQL para
consultar registros nas suas bases de dados, SPARQL a linguagem de consulta
padro recomendada pelo W3C para recuperao de informaes contidas em
grafos RDF. Apesar de existirem outras linguagens de consulta (SeRQL, RQL,
etc..) mais antigas, maduras e com maior poder de expressividade que o SPARQL,
estas ou foram projetadas para se trabalhar em um domnio especfico ou so
interpretadas apenas por algumas poucas ferramentas, o que acaba resultando em
uma baixa interoperabilidade.
Semelhante ao SQL, o SPARQL possui uma estrutura Select-From-Where
onde:
Select: Especifica uma projeo sobre os dados como a ordem e a quantidade de
atributos e/ou instncias que sero retornados.
From: Declara as fontes que sero consultadas. Esta clusula opcional.
Quando no especificada, assumimos que a busca ser feita em um documento
RDF/RDFS particular.
Where: Impes restries na consulta. Os registros retornados pela consulta
devero satisfazer as restries impostas por esta clusula.
O resultado de uma consulta SPARQL pode ser encarado como um subgrafo
resultante da execuo da consulta sobre o grafo que representa o modelo.
Considere por exemplo o grafo apresentado na Figura 4.2 extrado de [Allemang &
Hendler 2008].
83


Figura 4.2. Representao das instncias de um domnio

O grafo da Figura 4.2 representa a relao entre as instncias de uma
ontologia cujo domnio focado na descrio e formalizao de escritores. O
subgrafo destacado em negrito pode ser encarado, por exemplo, como o resultado
de uma consulta que retorna o escritor que escreveu o livro King Lear e casado
com AnneHathaway.

4.3. Princpios Linked Data
O termo Linked Data refere-se ao conjunto de melhores prticas para a publicao
de dados estruturados na Web. Essas prticas foram introduzidas por Tim Berners-
Lee em [Lee et al 2006] e resumem-se em quatro princpios bsicos:
1.Usar URIs como nome para recursos.
2.Usar URIs HTTP para que as pessoas possam encontrar esses nomes.
3.Quando algum procura por uma URI, garantir que informaes teis
possam ser obtidas por meio dessa URI, as quais devem estar representadas no
formato RDF.
4.Incluir links para outras URIs de forma que outros recursos possam ser
descobertos.
O primeiro princpio defende o uso de referncias URI para identificar, no
apenas documentos Web e contedos digitais, mas tambm objetos do mundo real e
conceitos abstratos.
84

O segundo princpio defende o uso de URIs HTTP para identificar os objetos
e os conceitos abstratos definidos pelo princpio 1, possibilitando essas URIs serem
dereferenciveis sobre um protocolo HTTP. Neste contexto, dereferenciar o
processo de recuperar uma representao de um recurso identificado por uma URI,
onde um recurso pode ter vrias representaes como documentos HTML, RDF,
XML entre outros.
A fim de permitir que uma ampla gama de aplicaes diferentes possam
processar dados disponveis na Web, importante que exista um acordo sobre o
formato padro para disponibilizao dos dados. O terceiro princpio Linked Data
defende o uso de RDF como modelo para a publicao de dados estruturados na Web
[Klyne et al. 2004]. Com o RDF, possvel descrever significado sobre recursos,
habilitando agentes de software a explorar os dados de forma automtica, muitas
vezes, agregando, interpretando ou mesclando dados.
O quarto princpio diz respeito ao uso de hiperlinks para conectar no apenas
os documentos da Web, mas qualquer tipo de recurso. Por exemplo, uma ligao
pode ser fixada entre uma pessoa e um lugar, ou entre um local e uma empresa. Em
contraste com a Web clssica onde os hiperlinks so em grande parte no tipados,
hiperlinks que conectam os recursos em um contexto de Linked Data so capazes de
descrever a relao entre eles. Hyperlinks no contexto de Linked Data so chamados
de links RDF, a fim de distingui-los dos hiperlinks existentes na Web convencional
[Heath & Bizer 2011].
O exemplo mais visvel da adoo e aplicao dos princpios Linked Data
tem sido o projeto Linking Open Data
1
fundado em janeiro de 2007 e apoiado pelo
W3C Semantic Web Education and Outreach Group
2
. O objetivo principal desse
projeto identificar conjuntos de dados disponveis sob licenas abertas e convert-
los para RDF de acordo com os princpios Linked Data.
Os participantes nas fases iniciais do projeto foram os pesquisadores e
desenvolvedores de laboratrios universitrios e empresas de pequeno porte. Desde
ento, o projeto tem crescido consideravelmente, conseguindo um envolvimento
significativo de grandes organizaes como a BBC
3
. Este crescimento possvel
graas natureza aberta do projeto, onde qualquer um pode participar, sendo
necessrio apenas publicar um conjunto de dados de acordo com os princpios Linked
Data e interlig-lo aos conjuntos de dados j existentes. Na Figura 4.3 podem-se
observar os diversos conjuntos de dados publicados no contexto do projeto Linking
Open Data.

1
http://www.w3.org/wiki/SweoIG/TaskForces/CommunityProjects/LinkingOpenData
2
http://www.w3.org/2001/sw/sweo/
3
http://www.bbc.co.uk/
85


Figura 4.3. Viso geral de conjuntos de dados publicados e seus relacionamentos em Setembro de
2011.
No grafo da Figura 4.3, cada n representa um conjunto de dados publicado
seguindo os princpios Linked Data, os quais esto interligados com outros
conjuntos de dados na nuvem. O tamanho de cada n corresponde ao nmero de
triplas RDF do conjunto de dados. As setas indicam a existncia de pelo menos 50
ligaes entre dois conjuntos, podendo ser unidirecionais, indicando que um certo
conjunto contem triplas RDF de um outro conjunto, ou bidirecionais, indicando que
ambos os conjuntos contem triplas RDF um do outro.
O contedo da nuvem possui natureza diversa, incluindo dados sobre
localizaes geogrficas, empresas, livros, publicaes cientficas, filmes, msica,
televiso e rdio, ensaios clnicos, comunidades online, dados estatsticos entre
outros [Heath & Bizer 2011].

4.4. Diretrizes para Publicao de dados em Linked Data
De acordo com [Heath & Bizer 2011], a adoo das melhores prticas de publicao
de dados ligados facilita a descoberta de informaes relevantes para a integrao de
dados entre diferentes fontes. A seguir so apresentados alguns passos para publicar
dados na Web de Dados, como definido em [Heath & Bizer 2011].
4.4.1. Criao de URIs adequadas
Como mencionado anteriormente, recursos so nomeados a partir de URIs. Dessa
forma, ao publicar dados Linked Data preciso fazer um esforo para criar boas
URIs para identificao dos recursos. Para isso, devem ser feitas algumas
consideraes, incluindo:
Usar URIs HTTP para tudo, tornando-as passveis de serem dereferenciadas.
Evitar URIs com detalhes de implementao ou do ambiente em que esto
publicadas. Por exemplo, a URI http://www.lia.ufc.br:8080/~danusarbc
86

/index.php um exemplo do que deve ser evitado, pois possui detalhes da porta
8080 usada em seu ambiente de publicao e do script implementado em PHP
necessrio para sua execuo.
Manter as URIs estveis e persistentes, pois a alterao das URIs pode levar
quebra de links j estabelecidos, criando um problema para a localizao de
recursos. Para evitar esse tipo de alterao, recomenda-se um planejamento das
URIs que sero usadas e tambm que o responsvel pela publicao detenha a
propriedade do espao de nomes
Muitas vezes ser preciso usar algum tipo de chave primria dentro das URIs,
para se certificar de que cada uma delas nica. Se possvel, usar uma chave que
significativa dentro do domnio para o qual est sendo criada a URI. Por
exemplo, quando se trata de livros, pode-se usar o ISBN como identificador
nico.
Essas so apenas algumas caractersticas desejveis para serem consideradas
quando se for criar uma URI. Maiores detalhes podem ser encontrados no tutorial
Cool URIs for the Semantic Web
4
disponibilizado pela W3C.

4.4.2. Usar URIs dereferenciveis
Qualquer URI HTTP deve ser capaz de ser dereferenciada, o que significa que
clientes HTTP podem procurar por uma URI usando um protocolo HTTP e recuperar
uma descrio do recurso que identificado pela URI.
A recuperao da representao mais adequada para o usurio feita por
meio da negociao de contedo. Assim, clientes HTTP enviam, por meio dos
cabealhos HTTP (Get, Head, Post, Put, Delete, Trace, Options, Connection), o
pedido para indicar qual tipo de contedo deseja obter. Aps isso, ao receber uma
requisio, o servidor analisa o cabealho e seleciona a resposta adequada. H duas
estratgias para fazer URIs serem dereferenciveis: 303 URI e Hash URI.
303 URI : 303 um cdigo de status de redirecionamento no qual o servidor pode dar
a localizao de um documento que contm informaes sobre um recurso. Por
exemplo, a Figura 4.4 mostra como ocorre o dereferenciamento quando um usurio
deseja obter informaes sobre a cidade de Berlin da fonte DBpedia
5
. Primeiramente,
em 1, especicado que o contedo desejado no formato RDF/XML atravs do
comando Accept: text/html;q=0.5, application/rdf+xml. Aps isso, em 2, o servidor
enviar para o cliente uma URI http://dbpedia.org/data/Berlin, mostrando a
localizao exata do contedo requerido e o cdigo 303 See Other, indicando que a
requisio ser redirecionada para essa URI. Com essa URI em mos, em 3, o cliente
reenvia sua solicitao e, por fim, em 4, recebe do servidor um arquivo RFD com o
contedo conforme solicitado.


4
http://www.w3.org/TR/cooluris/
5
http://dbpedia.org/
87


Figura 4.4. Dereferenciamento de URI utilizando a estratgia 303 URI .

Hash URI : Nessa estratgia, a URI contm um fragmento, uma parte especial que
separada do resto da URI pelo smbolo #. Quando um cliente deseja recuperar uma
hash URI, ele remove tudo que vem aps o smbolo # e envia o restante da URI para
o servidor. Como resposta, o cliente recebe um documento completo com o contedo
solicitado. Para um melhor entendimento, a Figura 4.5 mostra como ocorre o
dereferenciamento utilizando Hash URI para o seguinte exemplo: suponha um
arquivo que contm um vocabulrio definido para uma empresa fictcia chamada
Small and Medium-sized Enterprises representado pela seguinte URI:
http://biglynx.co.uk/vocab/sme. As seguintes URIs foram criados para identificar
termos distintos que podem ser encontrados no documentos previamente criado:
http://biglynx.co.uk/vocab/sme#Small MediumEnterprise e
http://biglynx.co.uk/vocab/sme#Team. Para dereferenciar qualquer uma dessas duas
URIs, o cliente remover o fragmento especial (#Team por exemplo) e ento enviar
sua requisio para o servidor, especicando que o contedo desejado no formato
RDF/XML atravs do comando Accept: application/rdf+xml conforme visto em 1.
Em seguida, o servidor retornar como resposta, em 2, um documento contendo todo
o contedo expresso em http://biglynx.co.uk/vocab/sme.
88


Figura 4.5. Dereferenciamento de URI utilizando a estratgia Hash URI .

4.4.3. Criao de links RDF
De modo a permitir a navegao entre as fontes de dados, devem ser criados links
para outras fontes, seja de forma manual ou automatizada. Links no contexto de
Linked Data fazem referncia aos de links RDF. Links RDF podem ser classificados
em dois tipos: links RDF internos e externos. O link RDF interno conecta recursos
dentro de uma nica fonte de dados Linked Data. Links externos conectam recursos
os quais so provenientes de diferentes fontes de dados Linked Data. No caso de
links externos, as URIs referentes ao sujeito e predicado do link pertencem a
diferentes namespaces (os quais so URIs que referenciam o esquema do qual o
elemento faz parte). Links externos so cruciais para a Web dos Dados visto que eles
permitem juntar as fontes de dados dispersas em um espao global de dados [Heath
& Bizer 2011].
A Figura 4.6 apresenta dois exemplos de links RDF. O primeiro exemplo
interliga o perl FOAF
6
do pesquisador Tim Berners-Lee localizado em um arquivo
RDF ao recurso que o identica na fonte de dados do DBLP
7
. No segundo exemplo,
o recurso que identica Tim Berners-Lee na fonte DBpedia
8
tambm ligado ao
recurso na fonte DBLP que o identica. A propriedade
http://www.w3.org/2002/07/owl#sameAs dene que os recursos interligados
representam a mesma entidade do mundo real.

Sujeito: http://www.w3.org/People/Berners-Lee/card#i

6
http://www.foaf-project.org/
7
http://www.informatik.uni-trier.de/~ley/db/
8
http://dbpedia.org/About
89

Predicado: http://www.w3.org/2002/07/owl\#sameAs
Objeto: http://www4.wiwiss.fu-berlin.de/dblp/resource/person/100007
Sujeito: http://dbpedia.org/resource/Tim\_Berners-Lee
Predicado: http://www.w3.org/2002/07/owl\#sameAs
Objeto: http://www4.wiwiss.fu-berlin.de/dblp/resource/person/100007
Figura 4.6. Exemplos de Links RDF.

Ao se criar links RDF preciso estabelecer relaes entre os termos dos
vocabulrios entre as fontes que esto sendo interligadas. Embora no haja restries
para seleo de vocabulrios, considerada uma boa prtica o reuso de termos de
vocabulrios RDF amplamente usados para facilitar o processamento de dados
ligados pelas aplicaes clientes. Novos termos s devem ser denidos se no forem
encontrados em vocabulrios j existentes. Alguns vocabulrios bastante conhecidos
so: Friend-of-a-Friend (FOAF), Semantically-Interlinked Online Communities
9

(SIOC), Simple Knowledge Organization System
10
(SKOS), Description of a
Project
11
(DOAP), Creative Commons
12
(CC) e Dublin Core
13
(DC). Propriedades
como: owl:equivalentClass, owl:equivalentProperty, rdfs:subClassOf,
rdfs:subPropertyOf podem ser usadas para estabelecer equivalncias entre os termos
dos vocabulrios citados. Maiores detalhes sobre as linguagens OWL e RDFS podem
ser encontrados em [Filho & Lscio 2009].

4.4.4. Explicitar formas de acesso adicional aos dados
Para acessar os dados das fontes Linked Data preciso realizar consultas SPARQL
sobre as fontes. Para enviar consultas e recuperar resultados atravs da linguagem
SPARQL usado o protocolo SPARQL
14
. Fontes Linked Data tipicamente fornecem
um SPARQL endpoint que um servio Web com suporte ao protocolo SPARQL.
Esse servio possui uma URI especca para receber requisies HTTP com
consultas SPARQL e retornar os resultados dessas consultas em diferentes formatos
como XML, JSON
15
, texto, RDF/XML, NTriples
16
, Turtle
17
ou N3
18
e HTML
[Magalhes et al 2011]. O framework Jena
19
disponibiliza duas implementaes de
SPARQL endpoints: o Joseki
20
e o Fuseki
21
. Ambos suportam o protocolo e a
linguagem SPARQL, permitem a realizao de consultas sobre arquivos RDF e RDF

9
http://sioc-project.org/
10
http://www.w3.org/2009/08/skos-reference/skos.html
11
http://trac.usefulinc.com/doap
12
http://creativecommons.org/
13
http://dublincore.org/
14
http://www.w3.org/TR/rdf-sparql-query/
15
http://www.json.org/
16
http://www.w3.org/2001/sw/RDFCore/ntriples/
17
http://www.w3.org/TR/turtle/
18
http://www.w3.org/TeamSubmission/n3/
19
http://incubator.apache.org/jena/
20
http://www.joseki.org/
21
http://openjena.org/wiki/Fuseki
90

Triple Stores, e implementam SPARQL Update
22
(linguagem para atualizar RDF
store). A diferena principal entre eles que o Fuseki mais simples de congurar e
usar, alm de j possuir a RDF Store Jena TDB
23
embutida. No entanto o Fuseki
um projeto mais recente, iniciado em 2011, que ainda possui limitaes quanto ao
gerenciamento de mltiplas fontes de dados e tambm quanto ao uso de mecanismos
de segurana prprios [Magalhes et al 2011].

4.4.5.Padres para Publicar Dados Linked Data
Para a publicao de dados RDF podem ser usadas ferramentas especficas de
converso de planilhas, arquivos CSV, arquivos XML, dados relacionais e outros
documentos para o formato RDF como, por exemplo, a ferramenta ConvertToRDF
24
.
Aps a gerao do arquivo em formato RDF, os dados podem ser carregados em um
banco de dados que armazena as triplas RDF, chamado de RDF Store. A publicao
de dados de uma RDF Store, seguindo os princpios Linked Data, tipicamente
envolve a disponibilizao de uma interface para acesso ao dados Linked Data e de
um SPARQL endpoint para acesso aos dados. Uma vantagem de se converter dados
para o formato RDF a melhoria de desempenho que pode ser obtida ao usar formas
de armazenamento especicamente otimizadas para realizar a persistncia de triplas
RDF. No entanto, o armazenamento das triplas requer espao extra em relao aos
dados originais. Alm disso, a converso demanda um certo tempo para ser realizada
e os dados em RDF podem car desatualizados em relao aos dados originais.
Um outra forma de acessar dados que no esto no modelo RDF consiste em
fornecer uma viso RDF. Isso feito atravs de um RDF Wrapper. Nesse caso, a
converso realizada por um RDF Wrapper por meio de mapeamentos estabelecidos
entre o modelo nativo e o modelo RDF, devendo haver um wrapper especfico para
cada tipo de modelo. Um RDF Wrapper tambm pode prover uma viso RDF para
dados que precisam ser acessados atravs de uma Web API. Criar uma viso RDF
tende a ter um desempenho inferior converso de dados para RDF devido s
tradues dinmicas entre os modelos que deve ser realizada a cada uso da viso
RDF. No entanto, o uso de RDF Wrappers traz algumas vantagens, pois como o
acesso ocorre sobre os dados originais, a viso RDF no requer espao de
armazenamento extra e no corre o risco de apresentar dados desatualizados.
Um exemplo comum de utilizao de vises RDF a publicao de dados
armazenados em banco de dados relacionais. O RDB-to-RDF
25
Wrappers uma
soluo que cria vises RDF a partir de mapeamentos entre as estruturas relacionais e
os grafos RDF. A plataforma D2RQ
26
um exemplo de RDB-to-RDF Wrappers, que
fornece toda a infraestrutura necessria para acessar bancos de dados relacionais
como grafos RDF virtuais. Esta plataforma possui os seguintes componentes:
Linguagem de mapeamento D2RQ uma linguagem declarativa para descrever
as correspondncias entre o modelo relacional e o modelo RDF. Os mapeamentos
escritos em D2RQ so documentos RDF.

22
http://www.w3.org/Submission/SPARQL-Update/
23
http://openjena.org/TDB/
24
http://www.w3.org/wiki/ConverterToRdf
25
http://www.w3.org/TR/r2rml/
26
http://www4.wiwiss.fu-berlin.de/bizer/d2rq/spec/
91

Mecanismo D2RQ um plug-in para os frameworks Jena e Sesame que usa os
mapeamentos escritos na linguagem D2RQ para converter chamadas s APIs
desses frameworks em consultas SQL ao banco de dados para obteno dos
resultados.
Servidor D2R
27
um servidor HTTP que usa o mecanismo D2RQ para prover
uma interface Linked Data e um SPARQL endpoint sobre o banco de dados
relacional [Bizer & Cyganiak 2006].
Alm do D2R, duas outras ferramentas destacam-se como RDB-to-RDF
Wrappers: o Virtuoso RDF Views [Erling & Mikhailov 2006] e o Triplify [Auer et al.
2009]. Este ltimo um plugin para aplicaes Web que permite mapear os
resultados de consultas SQL em RDF e JSON. Depois disso, os dados podem ser
compartilhados e acessados na Web de dados.
Aps gerar os dados no modelo RDF, necessrio verificar se o resultado
est de acordo com os princpios Linked Data. Essa verificao pode ser feita atravs
de ferramentas de validao como, por exemplo, Sindice Web Data Inspector
28
,
Eyeball
29
e W3C Validation Service
30
.
A prxima seo apresentar uma srie de aplicaes Web que vem sendo
desenvolvidas para consumir os dados publicados nos padres Linked Data.

4.5. Consumo de dados ligados
Nos ltimos trs anos, um nmero significativo de dados vem sendo disponibilizado
de acordo com os princpios Linked Data. Como resultado, uma srie de aplicaes
Web esto sendo desenvolvidas para explorar a Web de Dados. Segundo [Bizer et al
2009], essas aplicaes podem ser classificadas em trs categorias: browsers,
motores de buscas e aplicaes para domnios especficos. Essa seo examinar
cada uma dessas categorias.
4.5.1. Browsers Linked Data
Assim como os tradicionais browsers da Web clssica permitem aos usurios
navegarem por pginas HTML, os browsers Linked Data permitem aos usurios
navegar por fontes de dados seguindo os links expressos nas triplas RDF. Por meio
destes browsers possvel percorrer os links RDF, explorando e descobrindo novas
informaes na Web. A seguir, sero apresentados alguns exemplos de browsers
usados para acessar dados ligados.
Tabulator
31
permite ao usurio percorrer a Web de Dados e expor parte dos
dados de uma forma controlada, onde o usurio pode dividir a informao por
tpicos. Os resultados das consultas podem ser analisados atravs de vrios mtodos,
que vo desde a apresentao de dados de maneira convencional at a apresentao
por meio de mapas. A utilizao do modo de explorao inicia a partir da submisso
de uma URI. Depois disso, o Tabulator obtm informaes sobre o recurso e as

27
http://www4.wiwiss.fu-berlin.de/bizer/d2r-server/
28
http://inspector.sindice.com/
29
http://jena.sourceforge.net/Eyeball/
30
http://www.w3.org/RDF/Validator/
31
http://www.w3.org/2005/ajar/tab
92

exibe como um grafo RDF em uma viso de rvore. A expanso de um n permite a
obteno de mais informaes sobre ele. Para passar ao modo de anlise, o usurio
pode selecionar predicados para denir um padro e requisitar que o Tabulator
encontre todos os exemplos daquele padro. Os resultados podem ser exibidos
atravs das vises de tabela, mapas, calendrios ou linhas de tempo. Pode-se iniciar
uma nova explorao pela seleo de um detalhe de uma das vises. O Tabulator
pode ser usado como um complemento do navegador Firefox ou como uma aplicao
Web que atualmente compatvel apenas com o Firefox [Lee et al. 2006].
Marbles
32
um aplicativo do lado do servidor que formata o contedo da
Web Semntica para clientes XHTML. Pontos coloridos so usados para
correlacionar a origem dos dados apresentados com as fontes de dados de onde foram
encontrados. Os dados so recuperados de mltiplas fontes e integrados em um nico
grafo que mantido atravs das sesses do usurio. Alm de dereferenciar a URI,
Marbles consulta os mecanismos de busca Sindice e Falcons em busca de fontes que
contenham informaes sobre o recurso referenciado pela URI dada como entrada
para a busca. Alm disso, os predicados owl:sameAs e rdfs:seeAlso so seguidos para
obteno de informaes adicionais sobre o recurso. A Figura 4.7 apresenta
como o Marbles disponibiliza os dados para o usurio aps uma consulta. Os pontos
coloridos indicam as fontes de dados que forneceram os dados para o usurio. Dessa
forma, o usurio pode clicar sobre as fontes e encontrar mais informaes para a sua
busca.


Figura 4.7. Visualizao de Informaes sobre recursos do Browser Marbles.

32
http://marbles.sourceforge.net/
93


Disco Hiperdata Browser
33
uma aplicao Web usada como navegador
simples para visualizar informaes sobre um recurso por meio de uma pgina
HTML. Para iniciar a navegao, o usurio digita a URI do recurso em uma caixa de
texto e pressiona o boto Go. A partir da, o browser recupera as informaes
sobre o recurso e as exibe em uma tabela contendo propriedades, valores e as fontes
das quais os dados foram recuperados. Os links exibidos permitem a navegao entre
os recursos, de modo que ao selecionar um novo recurso, o navegador
dinamicamente recupera informaes sobre ele atravs do dereferenciamento de sua
URI. medida que a navegao feita, Disco armazena os grafos RDF recuperados
em um cache de sesso. Ao clicar sobre o link Display all RDF graphs, uma nova
janela aberta contendo a lista dos grafos RDF recuperados e das URIs que no
foram dereferenciadas com sucesso. Disco pode ser usado de forma online ou
executado localmente.
Alm das aplicaes descritas acima, destacam-se: Dipper
34
, Piggy Bank
35
,
URI Burner
36
, LinkSailor
37
e Graphite RDF Browser
38
como browsers simples e
rpidos para obter detalhes sobre uma determinada URI aps dereferenci-la.

4.5.2. Motores de Busca Linked Data
Um grande nmero de motores de busca tem sido desenvolvido para rastrear dados
no padro Linked Dados. Esses mecanismos de busca permitem localizar recursos de
diferentes fontes por meio de palavras-chave. A consulta pode ser realizada pelo
usurio atravs de uma interface Web ou atravs de servios Web oferecidos pelos
mecanismos de busca. A seguir so apresentados alguns dos motores de busca mais
utilizados.
Falcons permite tanto uma busca por palavras-chave, como oferece ao
usurio a opo de buscar objetos, conceitos e documentos, possibilitando uma
apresentao dos resultados um pouco diferente dos demais motores de busca. A
busca por objeto adequado para a busca por pessoas, lugares e outros itens
considerados concretos, enquanto que a busca por conceito orientada para a
localizao de classes e propriedades em ontologias publicadas na Web. O recurso de
pesquisa por documento segue uma abordagem mais tradicional, onde os resultados
apontam para documentos RDF que contm os termos de pesquisa especificados
[Cheg & Qu 2011].
Sindice
39
coleta dados estruturados na Web (RDF, RDFa e microformatos) e
os indexa por URIs, propriedades funcionais inversas (IFPs) e palavras-chave,
oferecendo uma interface Web para que os usurios possam fazer buscas a partir dos
itens indexados. Sindice tambm fornece um SPARQL endpoint que permite a
realizao de consultas sobre todos os seus dados e uma API que permite a utilizao

33
http://www4.wiwiss.fu-berlin.de/rdf_browser/
34
http://api.talis.com/stores/iand-dev1/items/dipper.html
35
http://simile.mit.edu
36
http://linkeddata.uriburner.com
37
http://linksailor.com/
38
http://graphite.ecs.soton.ac.uk/browser/
39
http://sindice.com/
94

de seus servios por outras aplicaes [Oren et al 2008]. Na Figura 4.8 pode-se
observar como o motor de busca Sindice apresenta o resultado de uma consulta ao
usurio.


Figura 4.8. Resultado mostrado pelo Sindice sobre a pesquisadora Bernadette Farias Lscio.

Sig.ma
40
busca dados estruturados a partir de uma palavra-chave e os exibe
em uma nica pgina, integrando os dados de mltiplas fontes. A viso criada pelo
Sig.ma baseia-se em resultados fornecidos pelo Sindice. O usurio pode aprovar,
rejeitar ou acrescentar fontes para estabelecer uma viso dos dados relevantes. Ao
selecionar uma entidade da lista de resultados, uma nova viso apresentada ao
usurio. Um link permanente pode ser criado para futuros acessos ou
compartilhamento dessa viso. Os filtros aplicados nas fontes pelos usurios ajudam
a classicar melhor a relevncia das fontes e aperfeioar a qualidade dos resultados
futuros. Alm da interface Web do usurio, Sig.ma ainda fornece uma API destinada
aos desenvolvedores de aplicaes. A Figura 4. 9 ilustra o resultado de uma consulta
sobre a pesquisadora Damires Yluska envolvendo trs fontes nas quais ela
referenciada.

40
http://sig.ma/
95


Figura 4.9. Viso criada pelo Sig.ma sobre a pesquisadora Damires Yluska.
Watson
41
e Swoogle
42
so mecanismos de busca mais voltados para a
descoberta de informaes sobre ontologias. Podem ser usados, por exemplo, para
obter ontologias que possuem determinados conceitos e descobrir relacionamentos
entre termos. Yahoo e Google tambm deram incio ao uso de Linked Data. Yahoo
prov acesso aos dados atravs da BOSS API
43
, enquanto o Google usa os dados para
a Social Graph API
44
.

4.5.3. Aplicaes para Domnios Especficos
Enquanto os browsers Linked Data e motores de busca descritos anteriormente
fornecem funcionalidades muito genricas, uma srie de servios, chamadas de
Linked Data Mashups, foram desenvolvidos com o objetivo de prover
funcionalidades mais especficas e de acordo com determinados domnios de dados.
A seguir descreveremos algumas dessas aplicaes [Lee et al 2006].
Revyu
45
uma aplicao Web para crtica e classicao de qualquer item
passvel de avaliao. Revyu tambm disponibiliza uma API e um SPARQL endpoint
para serem usados pelos desenvolvedores de aplicaes.
DBpedia Mobile
46
uma aplicao cliente para dispositivos mveis
consistindo de uma viso com um mapa e do navegador Linked Data Marbles.
Baseado na localizao geogrca de um dispositivo mvel, a aplicao exibe um
mapa indicando localizaes prximas a partir de dados extrados das fontes
DBpedia, Revyu e Flickr. O acesso ao Flickr realizado atravs de um Wrapper. O
usurio pode explorar informaes sobre essas localizaes e navegar em conjuntos
de dados interligados. Tambm possvel a publicao de informaes como Linked
Data, de modo que possam ser usadas por outras aplicaes [Becker & Bizer 2008].
Talis Aspire
47
uma aplicao Web voltada para que alunos e professores e
possam encontrar os principais recursos educacionais em universidades do Reino

41
http://watson.kmi.open.ac.uk/WatsonWUI/
42
http://swoogle.umbc.edu/
43
http://developer.yahoo.com/search/boss/boss_api_guide/
44
http://code.google.com/intl/pt-BR/apis/socialgraph/
45
http://revyu.com/
46
http://beckr.org/DBpediaMobile/
47
http://www.talisaspire.com/
96

Unido. O servio gratuito e prov ferramentas para criar e editar listas de leitura,
alm da produo e publicao de materiais educativos. Quando o usurio publica
contedo, a aplicao cria triplas RDF em uma RDF store. Itens publicados so
interligados de forma transparente a itens correspondentes de outras instituies.
BBC Programmes
48
e BBC Music
49
so projetos desenvolvidos pela BBC
Audio and Music Interactive. A aplicao Web BBC Programmes disponibiliza
informaes detalhadas sobre tipos, sries e episdios de todos os programas de TV e
rdio transmitidos pela BBC. BBC Music fornece informaes sobre artistas,
vinculando-os aos programas da BBC. Assim possvel escolher um artista e obter
todos os episdios de programas relacionados a ele. As aplicaes mencionadas
usam Linked Data como tecnologia de integrao de dados, inclusive fazendo uso de
vocabulrios amplamente conhecidos como DBpedia e MusicBrainz
50
.
LinkedDataBr um projeto brasileiro que visa construir uma infra-estrutura
de suporte criao de repositrios de dados governamentais pblicos utilizando os
padres de Linked Data. A ideia consiste em utilizar e ligar dados governamentais
disponveis na Web, gerados a partir das iniciativas de e-gov e open-government, de
forma a possibilitar a publicao padronizada e o acesso por parte dos cidados e
organizaes [Campos 2010].
4.6. Consideraes Finais
O imenso emaranhado de documentos acessveis na Web composto de dados e
informaes de praticamente todas as reas do conhecimento humano. Contudo,
ainda rdua a tarefa de prover meios eficientes que permitam aproveitar todo esse
contedo, que pode ser composto tanto por dados estruturados, como os dados
provenientes de bancos de dados relacionais, quanto por dados no estruturados,
como textos e dados multimdia. No cenrio da Web atual, o grande volume de
dados e a falta de metadados dificultam o acesso informao til, especfica e
relevante.
Neste contexto, espera-se que o uso dos princpios do Linked Data possibilite
a transformao de uma Web na qual os recursos so documentos HTML para uma
Web de Dados, onde os dados estaro interligados atravs de metadados. O tema
Linked Data traz novos desafios para o desenvolvimento de aplicaes Web de uma
maneira geral, bem como para o gerenciamento da grande nuvem de dados que vem
se formando como resultado da crescente adoo dos princpios do Linked Data.
Tendo em vista a relevncia deste assunto para a comunidade de Computao e o
grande potencial de pesquisa desta rea, Linked Data tem sido o foco de diversas
conferncias internacionais, bem como o foco de estudo de diversos grupos de
pesquisa. Dessa forma, torna-se de fundamental importncia que este tema seja
amplamente abordado e discutido por pesquisadores, alunos e profissionais da rea
de Computao.

48
http://www.bbc.co.uk/programmes
49
http://www.bbc.co.uk/music
50
http://musicbrainz.org/
97

Referncias
[Allemang & Hendler 2008] Allemang, D., Hendler, D. (2008) Semantic Web for the
Working Ontologist, 1
st
edition. Morgan Kaufmann publ., Amsterdam,
Netherlands.
[Auer et al. 2009] Auer, S., Dietzold, S., Lehmann, J., Hellmann, S., and Aumueller,
D. (2009) Triplify: Light-weight linked data publication from relational
databases. In Quemada, J., Len, G., Maarek, Y. S., and Nejdl, W., editors,
Proceedings of the 18th International Conference on World Wide Web, WWW
2009, Madrid, Spain, April 20-24, 2009, pages 621630. ACM.
[Becker & Bizer 2008] Becker, C., Bizer, C. (2008) DBpedia Mobile: A Location-
Enabled Linked Data Browser. In Linked Data on the Web (LDOW2008).
[Bizer & Cyganiak 2006] Bizer, C., Cyganiak, R. (2006) D2R Server Publishing
Relational Databases on the Semantic Web. In 5th International Semantic Web
Conference.
[Bizer et al 2009] Bizer C., Heath T., Berners-Lee T. (2009) Linked data - the story
so far. Int. J. Semantic Web Inf. Syst., 5(3):122, 2009.
[Campos 2010] Campos M. L. (2010) GT-LinkedDataBR Exposio,
compartilhamento e conexo de recursos de dados abertos na Web (Linked Open
Data). Disponvel em http://www.rnp.br/pd/gts2010-2011/gt_linkeddatabr.html
[Cheg & Qu 2011] Cheng, G., Qu, Y. (2011) Searching Linked Objects with
Falcons: Approach, Implementation and Evaluation. International Journal on
Semantic Web and Information Systems, Special Issue on Linked Data.
[Costa & Yamate 2009] Costa A., Yamate F. (2009) Semantic Lattes: uma
ferramenta de consulta baseada em ontologias. Trabalho de Grduao em
Engenharia de Computao - Escola Politcnica. IME/USP.
[Erling & Mikhailov 2006] Erling, O., Mikhailov, I. (2006) Mapping Relational
Data to RDF in Virtuoso. http://virtuoso.openlinksw.com/dataspace/dav/wiki/
Main/VOSSQLRDF.
[Filho & Lscio 2009] Filho, F. W. B. H , Lscio B. F. (2009) Web Semntica:
Conceitos e Tecnologias. In Anais do ERCEMAPI (Escola Regional de
Computao Cear Maranho Piau).
[Freitas 2003] Freitas, F. L. G. (2003) Ontologias e a Web Semntica. XXIII
Congresso da Sociedade Brasileira de Computao. JAI. Campinas, So Paulo,
Junho de 2003.
[Gruber 1995] Gruber T. (1995) Toward principles for the design of ontologies used
for knowledge sharing. 1995. International Journal Human-Computer Studies Vol.
43, Issues 5-6, November 1995, p.907-928.
[Heath & Bizer 2011] Heath, T., Bizer, C. (2011) Linked Data: Evolving the Web
into a Global Data Space (1st edition). Synthesis Lectures on the Semantic Web:
Theory and Technology, 1:1, 1-136. Morgan & Claypool, 2011.
98

[Klyne et al 2004] Klyne, G., Carroll, JJ., McBride., B. (2004) Resource description
framework (RDF): Concepts and abstract syntax. Disponvel em:
http://www.w3.org/TR/rdf-concepts/
[Lee et al 2006] Lee, B. T., Chen, Y., Chilton, L., Connolly, D., Dhanaraj, R., Hol-
lenbach, J., Lerer, A., and Sheets, D. (2006) Tabulator: Exploring and Analyzing
Linked Data on the Semantic Web. In In Procedings of the 3rd International
Semantic Web User Interaction Workshop (SWUI06, page 06.
[Lee et al 2001] Lee, B. T., Hendler J., Lassilia O. (2001) The semantic web.
Scientific American, 284(5):3444, Mai 2001.
http://dx.doi.org/10.1038/scientificamerican0501-34DOI:
10.1038/scientificamerican0501-34
[Magalhes et al 2011] Magalhes, R. P., Macedo, J. A. F., Vidal, V. M. P. (2011)
Linked Data: Construindo um Espao de Dados Global na Web. In Anais do
XXIV Simpsio Brasileiro de Banco de Dados. Outubro de 2011.
[Oren et al 2008] Oren, E., Delbru, R., Catasta, M., Cyganiak, R., Stenzhorn, H., and
Tumma-rello, G. (2008) Sindice.com: a document-oriented lookup index for open
linked data. Int. J.Metadata Semant. Ontologies, 3:3752.
[Souza 2009] Souza D. (2009) Using Semantics to Enhance Query Reformulation in
Dynamic Distributed Environments. PhD Thesis, Federal University of
Pernambuco (UFPE), Recife, PE, Brazil.


99

Captulo
5

Desenvolvimento de Aplicaes para Plataforma
Google Android
Fbio de Jesus Lima Gomes, Manoel Taenan Ferreira de Souza, Rafael
Madureira Lins de Arajo
Abstract
Com a evoluo da tecnologia mvel, os dispositivos mveis tornaram-se uma
importante fonte de transmisso e recepo de informaes, gerando a necessidade de
sistemas operacionais mais robustos e uma considervel demanda para o
desenvolvimento de servios e aplicaes. A plataforma Google Android surgiu para
preencher esta lacuna. Dessa forma, este mini-curso pretende disseminar conceitos
envolvidos no desenvolvimento de servios e aplicaes para a plataforma Google
Android. Tambm ser abordado como aplicaes para dispositivos mveis podem
consumir servios web atravs da arquitetura REST.
Resumo
With the evolution of mobile technology, mobile devices have become an important
source of transmission and reception of information, creating the need for more robust
operating systems and a considerable demand for the development of services and
applications. The Google Android platform was created in order to fill this gap. Thus,
this mini-course aims disseminate concepts about developing services and applications
for the Google Android platform. Also we will describe how mobile applications can
consume web services via REST architecture.
5.1. Introduo
O Google Android OS, tambm chamado apenas de Android, um sistema operacional
de cdigo aberto para dispositivos mveis e utiliza uma verso modificada do Sistema
Operacional Linux. Permite a desenvolvedores criarem aplicaes Java que controlam o
dispositivo atravs de bibliotecas desenvolvidas pela Google. O Android tambm prov
uma infra-estrutura robusta de execuo de aplicaes Java. Apesar de ser recente (seu
100

lanamento foi em 2008), o Android foi adotado rapidamente por diversos fabricantes
de dispositivos mveis e atualmente a plataforma que mais cresce no mundo.
Atualmente, a plataforma Google Android mantida pela OHA (Open Handset
Alliance), um grupo formado por mais de 40 empresas que se uniram para inovar e
acelerar o desenvolvimento de aplicaes e servios para dispositivos mveis, trazendo
aos consumidores uma experincia mais rica em termos de recursos e menos onerosa
financeiramente para o mercado. Pode-se dizer que a plataforma Google Android a
primeira plataforma completa, aberta e livre para dispositivos mveis. O Android SDK
o kit de desenvolvimento que disponibiliza as ferramentas e APIs necessrias para
desenvolver aplicaes para a plataforma Google Android, utilizando a linguagem Java.
Este mini-curso visa abordar conceitos envolvidos sobre desenvolvimento de
aplicaes para a plataforma Google Android, apresentando os principais aspectos do
desenvolvimento de aplicaes para dispositivos mveis, com enfoque para o
desenvolvimento de aplicaes que consomem servios web utilizando a linguagem
Java. Pretende-se capacitar os participantes no desenvolvimento de aplicaes Java para
plataforma Google Android com base no Android SDK e demonstrar a arquitetura
REST (Representational State Transfer) de desenvolvimento de aplicaes web. O
curso procura explorar as funcionalidades dessas tecnologias atravs do
desenvolvimento passo a passo de aplicaes-exemplos.
5.2. Arquitetura do Google Android
Android uma pilha de software para dispositivos mveis que inclui sistema
operacional, middleware e aplicaes-chave. Esta pilha possui 4 nveis (Google, 2011):

Figura 5.1 Arquitetura da Plataforma Google Android (Google, 2011)
101

1. LINUX KERNEL: a base da pilha o kernel. O Google usou a verso 2.6 do Linux
para construir o kernel do Android, que inclui servios essenciais do sistema, tais
como, gerenciamento de memria, gerenciamento de processos, gerenciamento de
energia, configuraes de segurana, configuraes de rede e drivers. O kernel
tambm atua como uma camada de abstrao entre o hardware do dispositivo e os
outros nveis da pilha de software.
2. RUNTIME ANDROID e LIBRARIES: acima do kernel esto as bibliotecas do
Android e o android runtime. Android runtime consiste de um conjunto de
bibliotecas que fornece a maioria das funcionalidades disponveis nas principais
bibliotecas da linguagem de programao Java e de uma Mquina Virtual Dalvik
(DVM). Uma aplicao Android roda em seu prprio processo, com a sua prpria
instncia da mquina virtual Dalvik. Dessa forma, nenhuma aplicao dependente
de outra; se uma aplicao pra, ela no afeta quaisquer outras aplicaes
executando no dispositivo e isso simplifica o gerenciamento de memria. Dalvik
foi escrito de modo que um dispositivo possa executar vrias VMs eficientemente.
Android possui um conjunto de bibliotecas C/C ++ usado por diversos
componentes da plataforma. As principais bibliotecas so listadas abaixo:
System C library uma implementao da biblioteca padro C (libc), derivada
do sistema operacional BSD, alterada para dispositivos embarcados baseados no
Linux;
Media Libraries baseada no OpenCORE da PacketVideo; estas bibliotecas
suportam reproduo e gravao de muitos formatos populares de udio, vdeo e
imagem, tais como, MPEG4, H.264, MP3, AAC, AMR, JPG, e PNG.
Surface Manager gerencia acesso ao sub-sistema de exibio e compe as
camadas grficas 2D e 3D para as aplicaes.
LibWebCore um moderno engine para um navegador web que alimenta o
navegador do Android.
SGL engine de grficos 2D.
3D libraries uma implementao baseada nas APIs OpenGL ES 1.0; estas
bibliotecas usam acelerao de hardware 3D (quando disponvel) ou o software
embutido no sistema.
FreeType renderizador de bitmap e fontes vetorizadas.
SQLite engine leve e poderoso de banco de dados relacional para as aplicaes.
3. APPLICATION FRAMEWORK: O prximo nvel o framework de aplicao que
consiste nos programas que gerenciam as funes bsicas do telefone, tais como,
alocao de recursos, aplicaes de telefone, mudana entre processos ou
programas e informaes sobre a localizao fsica do aparelho. Os
desenvolvedores de aplicaes tm acesso total ao framework de aplicao do
Android. Isso possibilita tirar vantagem das capacidades de processamento e do
suporte de recursos do Android.
102

4. APPLICATIONS: No topo da pilha esto as aplicaes em si. Aqui se encontram as
funes bsicas do dispositivo, como fazer chamadas telefnicas, acessar o
navegador web ou acessar sua lista de contatos. Esta a camada do usurio comum,
que utiliza a interface de usurio. Apenas os programadores do Google, os
desenvolvedores de aplicao e os fabricantes de hardware acessam as camadas
inferiores da pilha. O Android contm um conjunto de aplicativos, implementados
em Java, como um cliente de e-mail, programa para SMS (Short Message Service),
calendrio, mapas, navegador e gerenciador de contatos.
5.3. Componentes de uma aplicao Android
As aplicaes Android podem ser divididas em quatro tipos de componentes bsicos
que so definidos pela prpria arquitetura (ABLESON,2007), so eles:
5.3.1. Activities
Funcionam como mediadores que definem como as informaes sero apresentadas ao
usurio, alm de controlar o fluxo da aplicao. Elas podem interagir com o usurio e
trocar informaes com outras activities ou services (MEIER,2009).
A maioria do cdigo que escreveremos para uma aplicao Android ir executar
no contexto de uma activity. Activities normalmente correspondem a telas: cada activity
mostra uma tela para o usurio. Quando esta no est em execuo, o sistema
operacional pode elimin-la para liberar memria.
5.3.1.1. Ciclo de vida de uma Activity
Ao longo de sua criao at o momento de sua eliminao da memria, uma activity
atravessar seis estados, podemos referenciar cada estado pelos mtodos:
OnCreate
chamado quando a activity criada. Ela obrigatria e chamada apenas uma vez,
deve referenciar a tela que ser apresentada ao usurio.
OnStart
chamado quando a activity est ficando visvel e j tem uma tela definida.
OnResume
chamado quando a activity foi parada temporariamente e est retornando execuo.
OnPause
chamado quando a activity est sendo tirada do topo da execuo. Geralmente
utilizado para salvar o estado da aplicao.
OnStop
chamado quando a activity no est mais visvel e est em segundo plano.
OnDestroy
Executa os ltimos processamentos antes da activity ser literalmente encerrada.
103


Figura 5.2. Ciclo de vida de uma Activity.
5.3.2. Services
So programas que executam em segundo plano. No interagem diretamente com o
usurio e podem ficar executando por tempo indefinido.
5.3.3. Broadcast e Intent Receivers
So componentes que ficam aguardando a ocorrncia de um determinado evento, pode-
se entender como evento a inicializao do sistema operacional, uma chamada de voz, a
chegada de um SMS, um evento disparado por uma aplicao (MEIER,2009).
Intents so elementos chave no Android, porque facilitam a criao de novas
aplicaes a partir de aplicaes j existentes. Precisaremos utilizar Intents para
interagir com outras aplicaes e servios que proporcionaro informaes necessrias
para nossa aplicao.
5.3.4. Content Providers
So os compartilhadores de contedo entre as aplicaes, uma aplicao pode requisitar
informaes de outra, por exemplo, uma aplicao pode receber dados da lista de
contatos que nativa do Android, e com base nesses dados, realizar algum
processamento (LECHETA,2010).

104

5.4. Android SDK e seus pacotes para implementao de aplicaes
O SDK um conjunto de ferramentas utilizadas para desenvolver aplicaes para a
plataforma Android. Possui um emulador para simular o dispositivo mvel e uma API
completa para a linguagem Java, com todas as classes necessrias para desenvolver as
aplicaes (BURNETTE, 2008).
Existem atualmente trs verses do SDK para atender a maior parte dos
desenvolvedores: verso para Windows, Linux e Mac OS.
O ambiente de desenvolvimento que nos utilizaremos nos exemplos seguintes
composto, alm do JDK e Android SDK, pelo Eclipse IDE verso Galileo e o Android
Development Plugin (ADT), um plugin que ajudar na integrao da IDE com o
emulador.
Os componentes do ambiente de desenvolvimento podem ser encontrados nos
links a seguir:
JDK: http://www.oracle.com/technetwork/java/javase/downloads/index.html
Android SDK: http://developer.android.com/sdk/
Eclipse IDE: http://www.eclipse.org/downloads/
ADT: http://developer.android.com/sdk/eclipse-adt.html
5.4.1. Conceitos bsicos do Android
5.4.1.1 Criando uma Activity
A classe android.app.activity utilizada para criar uma tela na aplicao. Essa tela
composta de vrios elementos visuais, os quais no Android so representados pela
classe android.view.View (LECHETA, 2010).
A classe android.view.View pode representar algo simples como um boto, um
checkbox ou imagem, como tambm pode representar algo complexo como um
gerenciador de layout, a qual pode conter vrias views aninhadas para organizar na tela.



Figura 5.3. Exemplo de uma Activity.
O mtodo setContentView(view) o que faz a ligao entre a activity e a view e
recebe como parmetro a view que ser exibida na tela.
105

5.4.1.2 A classe R
A classe R criada automaticamente pelo ADT e no pode ser alterada manualmente.
Nela existem constantes para os recursos do projeto. Cada constante nomeada com o
nome do recurso, que deve ser escrito com letra minscula e sem espao, e recebe um
valor inteiro.
5.4.1.3 O arquivo AndroidManifest.xml
Toda aplicao Android deve ter um arquivo AndroidManifest.xml em seu diretrio raiz.
Esse arquivo apresenta informaes essenciais sobre a aplicao para o sistema
operacional, que deve possuir informaes do sistema antes que possa executar qualquer
solicitao do cdigo do aplicativo (MEDNIEKS,2009).
Ele armazena informaes como o nome do pacote da aplicao, descreve os
componentes da aplicao, determina qual processo da aplicao vai armazenar os
componentes, declara de que formas as solicitaes devem ter permisses para acessar
partes protegidas da API e interagir com outras aplicaes. Declara tambm as
permisses que os outros processos sero obrigados a ter, fim de interagir com os
componentes da aplicao, enumera classes e perfis e fornece outras informaes sobre
como a aplicao ser executada, declara qual o nvel mnimo da API que o aplicativo
exige e enumera bibliotecas que estaro relacionadas com a aplicao.

Figura 5.4. Exemplo de arquivo AndroidManifest.xml
5.4.1.4 Criao de uma interface visual
O Android fornece um sofisticado e poderoso modelo, baseado em componentes, para
construir sua interface, baseado no esquema de classes fundamentais:
android.view.View e android.view.ViewGroup, e inclui tambm as suas classes filhas
chamadas de widgets e layouts respectivamente(LECHETA, 2010).
Podemos citar alguns exemplos de widgets como Button, TextView, EditText,
ListView, CheckBox, RadioButton, Gallery, Spinner, e outros.
Podemos citar, tambm, exemplos de layouts como LinearLayout, FrameLayout,
RelativeLayout entre outros.
Para exemplificar a criao da interface visual criaremos uma tela de login, a
qual conter os campos de nome de usurio e senha, e um boto para submet-los.
106












Figura 5.5. Representao grfica da tela de login.


Figura 5.6. Cdigo da tela de login
107

Podemos observar que foram utilizados trs tipos de widgets e um layout. Dois
TextView que so utilizados para renderizar strings na tela e dois EditText que so
caixas para receber texto. Foi utilizado, tambm, um Button para enviar os dados e
um LinearLayout para organiz-los na tela.
Podemos observar, tambm, alguns atributos como o id que serve como
identificador de cada componente, o text que tem o funcionamento semelhante ao value
do HTML e o atributo password que esconde os caracteres digitados no nosso EditText.

5.4.1.5 O mtodo findViewById()
Ao construir uma tela usando um arquivo XML de layout, surge a necessidade de
recuperar os objetos definidos no arquivo dentro do cdigo-fonte da aplicao para obter
seus valores ou definir atributos (LECHETA, 2010).
Podemos recuperar um objeto de viso atravs do seu identificador nico
(android:id), passando-o como parmetro no mtodo findViewById(id). Esse mtodo
recebe o id do componente desejado e retorna uma subclasse de android.view.View,
como as classes Button, TextView e EditText.
Na figura a seguir mostrado como recuperar a senha inserida pelo usurio
atravs do mtodo findViewById(id) e uma pequena ajuda da classe R.

Figura 5.7. Exemplo da utilizao do mtodo findViewById()

5.4.2 Intent
Uma intent representa uma inteno da aplicao em realizar alguma ao. Ela envia
uma mensagem ao sistema operacional chamada de broadcast. Ao receber essa
mensagem, o sistema operacional tomar as decises necessrias (LECHETA, 2010).
108

Uma intent representada pela classe android.content.Intent e pode ser
utilizada para enviar uma mensagem ao sistema operacional, abrir uma nova tela da
aplicao, utilizando o mtodo startActivity(intent), solicitar ao sistema operacional que
ligue para determinado nmero de celular, abrir o browser em um determinado endereo
da internet, exibir algum endereo, localizao ou rota no Google Maps dentre outros.
5.4.2.1 Navegao entre telas com passagem de parmetros
Existem dois mtodos de se iniciar uma nova tela (activity), atravs dos mtodos
startActivity(intent) e startActivityForResult(intent,codigo) que apenas inicia uma nova
activity ou inicia uma nova activity e cria um vnculo para ser utilizado ao retornar
respectivamente (PEREIRA, 2009).
Para que o sistema operacional possa reconhecer nossa nova activity,
necessrio adicionar seu endereo no arquivo AndroidManifest.xml.

Figura 5.8. Trecho do arquivo AndroidManifest.xml que contm a nova activity.
Podemos enviar informaes para outras telas atravs de uma intent.
Figura 5.9. Exemplo de passagem de parmetro e troca de tela atravs de uma intent
Podemos observar na figura 5. 8, que criada uma intent com a activity da tela-
alvo, passado como parmetro atravs do mtodo putExtra() o texto contido no
EditText referente ao usurio para a prxima tela, e finalmente, a nova activity
iniciada atravs do mtodo startActivity(intent).
109


Figura 5.10. Cdigo da classe SegundaTela.
Observando essa classe, vemos que a intent capturada atravs do mtodo
getIntent() e recebemos o parmetro do login atravs do mtodo getStringExtra(string).
O contedo da tela apenas um TextView com uma mensagem de boas vindas.
5.4.2.2 Intents Nativas do Android
Vimos no exemplo anterior que possvel iniciar uma nova activity atravs das intents.
O Android possui alguns tipos de intents pr-definidas que podemos utilizar para enviar
mensagens ao SO, porm, algumas delas necessitam de permisses para executar, tais
permisses precisam ser registradas no arquivo AndroidManifest.xml (PEREIRA,2009).
Vrias intents como a ACTION_VIEW, que serve para iniciar o navegador, a
ACTION_CALL, que utilizada para realizar chamadas, a ACTION_PICK, que serve
para visualizar todos os contatos, dentre outras, so utilizadas em aplicaes Android.
A seguir veremos um exemplo de como chamar o navegador atravs de uma
intent pr-definida no Android.



Figura 5.11. Exemplo da iniciao do navegador atravs de uma Intent.
O exemplo demonstra a utilizao da intent ACTION_VIEW, mas, para usar
essa intent necessria a permisso INTERNET que deve ter sido registrada
previamente.

Figura 5.12. Inserindo a permisso INTERNET no arquivo AndroidManifest.xml
110

5.4.3 Intent Filter
Podemos utilizar intents para enviar mensagens ao sistema operacional, definindo uma
ao que identifique essa intent. Ento quando a mensagem for enviada ao sistema
operacional ela seja identificada por essa ao, e somente uma activity que esteja
mapeada para aquela ao ser executada (MEDNIEKS, 2009).
Esse tipo de rotina bem prtica quando queremos que mais de um programa
esteja configurado para receber uma ao (LECHETA, 2010).
Para definir essa ao, basta criar uma Intent usando seu construtor, que recebe
uma string que identifica a ao, como, por exemplo:



Figura 5.13. Exemplo de uma chamada de ao por uma Intent.
Logicamente, algum tem que responder por essa ao. Para isto, precisamos
mapear um Intent Filter no arquivo AndroidManifest.xml, para escutar esse chamado e
delegar a execuo uma activity.

Figura 5.14. Cdigo fonte da classe SegundaTela.





Figura 5.15. Exemplo de mapeamento de uma Intent Filter.
5.4.4 BroadcastReceiver
A classe BroadcastReceiver utilizada para responder a determinados eventos enviados
por uma intent. Ela sempre executada em segundo plano durante pouco tempo,
normalmente dez segundos. No deve ter interface grfica ou interao com o usurio
(LECHETA, 2010).
111

utilizada normalmente para executar algum processamento sem que o usurio
perceba, em segundo plano.
Assim como uma activity, devemos declar-lo no arquivo AndroidManifest.xml
atravs da tag <receiver>, deve ser declarada, tambm, um Intent Filter para o broadcast,
ou podemos registr-lo dinmicamente, utilizando o mtodo
registerReceiver(receiver,filtro), que tem como parmetros uma classe-filha de
IntentReceiver e uma instncia da classe IntentFilter que possui a configurao da ao e
a categoria (LECHETA, 2010).
O mtodo para enviar uma mensagem para um broadcast diferente do utilizado
para uma intent que chama uma activity. O mtodo utilizado o sendBroadcast(intent)
que envia uma mensagem para todas as aplicaes instaladas no celular.
Para implementar um BroadcastReceiver deve-se extender a classe
BroadcastReceiver e implementar o mtodo onReceive() que ser executado assim que o
IntentFilter receber a mensagem.

Figura 5.16. Utilizando o mtodo sendBroadcast(intent).

112

Figura 5.17. Exemplo de um BroadcastReceiver.
Apenas por motivos didticos foi utilizado a classe Toast para verificar o funcionamento
do BroadcastReceiver. Recomenda-se que no tenha nenhum tipo de interao com o
usurio.

Figura 5.18. Exemplo do mapeamento de um BroadcastReceiver.
5.4.5 Notification
A classe Notification utilizada para exibir informaes ao usurio sem que este seja
interrompido se estiver executando alguma atividade. O usurio pode escolher visualizar
as informaes neste momento, ou depois (LECHETA, 2010).
A notificao exibida na barra de status do celular para chamar a ateno do
usurio. Ao ser visualizada, a intent configurada pode uma abrir uma nova activity ou
pode ser usada para iniciar um servio por exemplo (MEIER, 2009).
Um exemplo de notificao a recepo de uma nova SMS, onde usurio pode
decidir visualiz-la ou no.
Para criar uma notificao necessrio capturar um servio do Android chamado
de NOTIFICATION_SERVICE, ser necessrio, tambm utilizar a classe PendingIntent
que criar uma intent que ficar pendente at o usurio decidir visualizar a notificao:
113


Figura 5.19. Exemplo da criao de uma notificao.
Podemos observar, que o construtor da classe Notification recebe trs
parmetros: o cone que dever ser exibido, o ttulo da notificao e a hora que
aparecer do lado da notificao.
Observamos, tambm, que deve-se informar atravs do mtodo
setLatestEventInfo, a mensagem que aparecer na barra de status assim que a
notificao for reconhecida pelo servio de notificaes do android, o ttulo da
notificao e a intent que dever ser chamada quando o usurio visualizar a notificao.

Figura 5.20. Classe que ser instanciada quando a notificao for visualizada.
A figura anterior mostra a classe que ser instanciada quando o usurio
visualizar a notificao. Capturamos o servio de notificaes do android, e pedimos
114

para que a notificao no aparea mais na barra de status atravs do mtodo cancel(int)
que recebe como parmetro o id da notificao.
5.4.6 Service
Tm as mesmas caractersticas dos servios dos sistemas operacionais de computador.
So utilizados quando queremos executar algo por tempo indeterminado em
segundo plano e que exija um alto consumo de recursos, memria e CPU (LECHETA,
2010).
Geralmente so iniciados por um BroadcastReceiver para executar algum
processamento demorado, pois um BroadcasReceiver tem um tempo determinado para
executar (PEREIRA, 2009).
interessante que os servios tenham suas prprias threads para que fiquem
independentes do programa hospedeiro. Eles tambm possuem um ciclo de vida prprio,
semelhante ao de uma Activity, mas possuem apenas trs estgios: o onCreate, onStart e
onDestroy, que desempenham o mesmo papel que o de uma Activity.
Para iniciar um servio necessrio criar uma activity que chame o mtodo
startService(intent). Para parar um servio existem duas maneiras: a primeira chamar o
mtodo stopService(intent), a mesma intent utilizada para iniciar o servio deve ser
usada para par-lo, e a segunda forma o prprio servio chamar o mtodo stopSelf().

Figura 5.21. Chamando um servio.
Para implementar um servio necessrio estender a classe android.
115


Figura 5.22. Exemplo de um servio.
Para exemplificar o funcionamento de um servio, utilizamos esta classe, que
quando iniciada, cria uma srie de logs. Podemos observar que mesmo fechando a
aplicao que iniciou o servio, ele continua criando logs at chamar o mtodo
stopSelf().
necessrio mapear o servio no arquivo AndroidManifest.xml e configurar um
IntentFilter com a ao que iremos passar como parmetro pela nossa Intent.
116


Figura 5.23. Exemplo do mapeamento de um servio.
5.4.7 AlarmManager
So eventos agendados no sistema operacional para serem executados no futuro
(LECHETA, 2010).
utilizado quando necessrio executar algo uma vez em determinado horrio
ou ficar repetindo de tempos em tempos.
Quando agendados, ficam ativos no sistema at que sejam explicitamente
cancelados, ou o sistema for reiniciado.
Para agendar um alarme, primeiro temos que definir uma intent com o
BroadcastReceiver que ir responder pelo nosso alarme. Depois temos que capturar o
servio do Android responsvel pelo gerenciamento dos alarmes, o AlarmManager.

Figura 5.24. Agendando um alarme.
117


Figura 5.25. BroadcastReceiver que ser chamado pelo nosso alarme.
5.5. Arquitetura REST de desenvolvimento de aplicaes Web
Vivemos hoje uma febre de Apps pequenos aplicativos auto-contidos que tem uma
nica funo e comumente so interfaces para sistemas Web. A maioria desses
aplicativos extremamente dependente de dados para serem teis e esses dados podem
vir dos mais variados lugares por exemplo, a plataforma Android disponibiliza ao
desenvolvedor uma pequena base dados SQLite onde ele pode criar suas tabelas,
armazenar e buscar dados, mas cada vez mais esses dados vm de servios web.
A Web uma plataforma orientada a recursos. Um Recurso pode ser definido
como qualquer coisa que exposta a Web atravs de um identificador e que possamos
manipular (ler e/ou escrever) (WEBBER; PARASTATIDIS, 2010)..
Desde sua formalizao REST
1
vem sendo um termo e, mais adequadamente,
uma arquitetura de software de sistemas Web cada vez mais utilizado, estudado e
discutido. Esta arquitetura foi proposta pelo Dr. Roy T. Fielding em 2000 e desde ento
vem sendo adotada em vrios sistemas de grande porte como Twitter, Facebook, Flickr
e todas as APIs de servios pblicos do Google como Google Agenda, Google Health,
Google Data e Google Maps.
Veremos a seguir o que REST e, em seguida, formas de se trabalhar com
REST em Java.
5.5.1 Definio
O protocolo HTTP, e consequentemente servidores HTTP, um protocolo simples e
sem muitos recursos. Em sua primeira verso ele apresentou endereamento e
statelessness: duas caractersticas de seu projeto que o tornou um avano perante seus
rivais e que ainda o mantm escalvel mesmo nos mega-sites de hoje (RICHARDSON;
RUBY, 2007).
Sistemas com esta arquitetura so sistemas Clientes-Servidores comuns,
entretanto suas requisies e respostas so construdas ao redor da transferncia da
representao de recursos. Recursos so os blocos fundamentais de sistemas baseados
na web, ao ponto que a Web considerada como orientada a recursos (WEBBER;
PARASTATIDIS, 2010). A abstrao chave de informao do REST so os recursos.
Qualquer informao que pode ser nomeada pode ser um recurso: documentos, imagens,
informaes sobre o tempo, uma pessoa, e assim sucessivamente (FIELDING, 2000).

1
Representational State Transfer Transferncia de Estado Representacional
118

Um dos recursos mais comuns da Web so pginas HTML, que em sistemas so
comumente a representao de um recurso interno do sistema, por exemplo, uma pgina
de exibio de um vdeo do YouTube a representao do recurso vdeo do sistema.
Um mesmo recurso pode ter vrias representaes diferentes. Utilizando o
exemplo do vdeo do YouTube, uma representao a pgina HTML onde mostrado o
vdeo, comentrios, etc. outra representao vista quando o vdeo incorporado em
outra pgina. Nessa representao vemos apenas um player que carrega o vdeo em
questo. Outra representao, um pouco menos conhecida, a representao em XML
2

ou mais recentemente JSON
3
, ambas tecnologias de transio de dados hierrquicos.
Devido a essas caractersticas REST tambm requer que as aplicaes faam
total distino entre cliente e servidor atravs da implementao das seguintes
caractersticas:
1. Cliente-Servidor: Clientes so separados dos Servidores por uma interface
uniforme. Essa diviso faz com que o cliente no se preocupe com, por exemplo,
armazenamento de dados ao passo que o servidor no se preocupa com interface
com o usurio;
2. Stateless (Sem Estado): A comunicao cliente-servidor ocorre sem que nenhum
contexto relativo ao cliente seja armazenado no servidor entre as requisies.
Cada requisio de cada cliente contm toda informao necessria para atender
aquela requisio e a reposta deve conter toda a informao para satisfazer a
requisio;
3. Cache: Como comum na Web, o cliente pode manter um cache das respostas do
servidor, portanto recomendado que as respostas contenham informaes sobre
se podem e como deve ser feito o cache a fim de evitar que clientes requisitem um
mesmo recurso repetidamente. Um bom cache elimina vrias interaes cliente-
servidor desnecessrias o que proporciona escalabilidade e performance;
4. Camadas: Um cliente no pode normalmente distinguir se ele est ou no
conectado ao servidor final ou apenas a um intermedirio. Um sistema com vrios
servidores permite o balanceamento de carga, caches compartilhados e ajudam a
manter uma boa segurana;
5. Cdigo sob demanda (opcional): Servidores podem ser capazes de estender a
funcionalidade de um cliente transferindo lgica para que ele execute. Exemplos
disso so componentes compilados como Applets Java ou scripts no lado cliente
como JavaScript;
6. Interface uniforme: Todo cliente obedece ao mesmo formato de requisio e
recebe o mesmo formato de resposta.

2
XML eXtensible Markup Language Linguagem de marcao extensvel.
3
JavaScript Object Notation Notao de Objetos JavaScript.
119

A arquitetura REST est fundamentada sob o protocolo HTTP e seus mtodos.
Clientes que acessam recursos informando sua inteno atravs do mtodo que
executam sob o recurso. A maioria dos sistemas hoje em dia segue a seguinte conveno
de mtodos HTTP, concebidos para simular operaes de CRUD:
GET: Leitura;
POST: Escrita;
PUT: Alterao ou Atualizao;
DELETE: Remoo.
Muitas aplicaes novas esto utilizando os princpios REST a fim de obterem
um bom nvel de escalabilidade. Normalmente essas aplicaes disponibilizam a seus
usurios uma API dos mtodos REST disponveis, suas entradas e suas sadas.
Para compreender melhor, vejamos a API de um sistema referncia em
tecnologia REST: o Twitter.
O Twitter disponibiliza em seu website uma extensa e detalhada documentao
da API de seu sistema
4
. uma plataforma de apoio aos desenvolvedores que desejam criar
clientes para o Twitter com pginas de ajuda onde so descritos os mtodos da API, um
guia ao desenvolvedor e ferramentas para ajud-lo.
Chamadas a alguns mtodos da API podem ser feitas, para testes, atravs de um
navegador web qualquer.
Durante a escrita deste texto, a API do Twitter aceita a seguinte chamada:
http://api.twitter.com/1/users/show.xml?screen_name=fat. Para
chamar este mtodo da API basta abrir esta URL em qualquer navegador web.
Ao abrir esta URL em um navegador, o que feito uma chamada a API atravs
do mtodo HTTP GET. Chamadas a qualquer API REST na Web so compostas de 3
partes:
1. A URL correspondente ao mtodo da API
http://api.twitter.com/1/users/show
2. Os parmetros da chamada ao mtodo
screen_name = fat
3. O mtodo HTTP utilizado para chamada aquela URL
Por padro, toda transao HTTP dos navegadores atuais utiliza o mtodo GET.
A URL uma chamada ao mtodo 1/users/show da API do Twitter. Uma
particularidade dessa API a possibilidade de escolha do formato de representao do
recurso: XML ou JSON, representado pela extenso do arquivo na URL.

4
Disponvel em http://dev.twitter.com/ - Acesso em 12 outubro 2011
120


5.5.2. REST em Java
Em Java chamadas a APIs REST so feitas utilizando chamadas HTTP simples,
normalmente com objetos java.net.URL e java.net.HttpURLConnection.
Nos exemplos a seguir utilizaremos a API do Twitter como exemplo.
A forma mais simples de se executar uma chamada a seguinte:
String apiCall = "<url de chamada a API>";
URL url = new URL(apiCall);
HttpURLConnection conn;
conn = (HttpURLConnection) url.openConnection();
Ao invocar o mtodo openConnection() uma requisio HTTP GET feita
a URL especificada em apiCall. Aps essa chamada, importante verificar o cdigo
de resposta dado pelo servidor. Normalmente um cdigo de resposta 200 significa que
tudo ocorreu como esperado. Outros cdigos de resposta podem ser especificados pela
API.
if (conn.getResponseCode() == 200) {
// Tudo ocorreu como esperado.
}
Dessa forma podemos tomar alguma providncia caso ocorra algum erro, e
garantir um bom funcionamento da aplicao.
Aps a confirmao do sucesso da chamada o prximo passo ler os dados da
resposta do servidor. necessrio um cuidado especial com o tipo de dado esperado
pois a resposta da API pode ser uma imagem, ou um documento, ou at mesmo um
Stream de dados. Vamos considerar que a resposta a nossa chamada est em formato
textual, caso qual podemos utilizar a seguinte tcnica para captar o resultado num
formato mais cmodo para manipulao:
BufferedReader reader = new BufferedReader(new
InputStreamReader(conn.getInputStream()));
StringBuilder str = new StringBuilder();
String line;
while ((line = reader.readLine()) != null) {
str.append(line);
}
reader.close();
Aps o recebimento da resposta, uma boa prtica sempre fechar a conexo
junto ao servidor invocando o mtodo disconnect():
conn.disconnect();
Dessa forma podemos fazer chamadas a quaisquer API REST utilizando Java.

121

5.5.2.1 Interpretando Respostas
Em Java podemos quase sempre considerar um recurso disponibilizado pelo servidor
com um Objeto. Comumente recebemos respostas em XML o qual uma serializao
de um objeto que est no servidor.
Devido a isso um ponto que requer especial ateno a interpretao das
respostas. APIs REST utilizam representaes do estado de um recurso (um Objeto) do
sistema. Nestes casos a forma mais comum de representao textual, segundo um
padro determinado pela API, XML ou JSON.
Existem vrias bibliotecas disponveis para se trabalhar com os formatos XML e
JSON, algumas bastante sofisticadas e simples de usar. Para XML temos, por exemplo,
uma biblioteca chamada jDOM
5
que interpreta XML e d ao desenvolvedor uma
representao do documento XML na forma de um grafo de objetos com uma interface
nativa Java que podem ser facilmente percorridos e manipulados. Para JSON h uma
biblioteca chamada Gson
6
disponibilizada pelo Google que pode transformar Objetos
Java em sua representao JSON e vice-versa:
Gson gson = new Gson();
String json = gson.toJson(meuObjeto);
MeuObjeto obj = gson.fromJson(json, MeuObjeto.class);
Atravs do uso de bibliotecas auxiliares possvel criar objetos concretos Java a
partir de representaes textuais dos mesmos.
A utilizao de JSON recomendada nestes casos pois grande parte dos sistemas
REST atuais so voltados para a interatividade entre sistemas de Websites, os quais so
em sua maioria feitos utilizando JavaScript, linguagem-me da notao JSON e que d
suporte nativo a interpretao e construo de objetos a partir de sua representao
textual e vice-versa.

Referncias bibliogrficas
ABLESON, W. Frank; Unlocking Android - A Developers Guide. Ed. Manning, 2007.
BURNETTE, Ed.Hello, Android:Introducing Google`s Mobile Development Plataform.
Pragmatic Bookshelf, 2008.
Google Android. Disponvel em <http://developer.android.com/guide/basics/what-is-
android.html>. Acesso em 12 outubro 2011.
LECHETA, Ricardo R. Google Android. So Paulo: Novatec, 2010, 2 ed.
MEDNIEKS, Zigurd; MEIKE, Blake. Desenvolvimento de Aplicaes Android. So
Paulo: Novatec, 2009, 1 ed.
MEIER, Reto. Professional Android Application Development. Indianapolis: Wiley
Publishing, 2009, 1. ed.

5
http://www.jdom.org/ - Acesso em 12 outubro 2011
6
http://code.google.com/p/google-gson/ - Acesso em 12 outubro 2011
122

PEREIRA, Lcio C. Oliva. Android para Desenvolvedores. So Paulo: Brasport, 2009,
1 ed.
WEBBER, Jim; PARASTATIDIS, Savas; ROBINSON Ian. REST in Practice:
Hypermidia and Systems Architecture. OReilly Media, 2010.
RICHARDSON, Leonard; RUBY Sam. RESTful web services. OReilly Media, 2007.
FIELDING, Roy; Architectural Styles and the Design of Network-based Software
Architectures. Dissertao de Doutorado, University of California, 2000.
123

Captulo
6

Desenvolvendo aplicaes multi-tenancy para
computao em nvem
Josino Rodrigues Neto, Vincius Cardozo Garcia e Wilton dos Santos
Oliveira
Abstract
This course focuses on presenting the main concepts of multi-tenancy and use a
practical approach to demonstrate the implementation of an application based on a
multi-tenancy architecture. Thus, this chapter presents the definitions and key
characteristics of cloud computing, SaaS service model and a multi-tenancy approach
for SaaS.
Resumo
Este minicurso tem como foco principal apresentar os principais conceitos de multi-
tenancy e utilizar uma abordagem prtica para demonstrar a implementao de uma
aplicao baseada em uma arquitetura multi-tenancy. Assim, este captulo apresenta as
definies e as caractersticas essenciais da computao em nuvem, o modelos de
servio SaaS e uma abordagem multi-tenancy para SaaS.

6.1 Introduo
Com o ritmo de desenvolvimento da sociedade humana moderna, servios bsicos e
essenciais so quase todos entregues de uma forma completamente transparente.
Servios de utilidade pblica como gua, eletricidade e telefone tornaram-se
fundamentais para nossa vida diria e so explorados atravs de um modelo de
pagamento baseado no uso. As infraestruturas existentes permitem entregar os servios
em qualquer lugar e a qualquer hora, de forma que possamos simplesmente acender a
luz, abrir a torneira ou fazer uma ligao para qualquer lugar. O uso desses servios
cobrado de acordo com as diferentes polticas para o usurio final. A mesma idia de
124

utilidade tem sido aplicada na rea da informtica e uma mudana consistente neste
sentido tem sido feita com a disseminao da computao em nuvem.
Segundo o NIST, Cloud Computing(Computao em nvem) composta por
cinco caractersticas essenciais: self-service sob demanda; amplo acesso a rede; pooling
de recursos; elasticidade rpida. Ainda segundo o NIST, Cloud Computing dividido
em trs modelos de servio: Software como servio (SaaS); Plataforma como servio
(PaaS); Infraestrutura como Servio (IaaS).
Nesse contexto, este minicurso tem como foco principal apresentar os principais
conceitos de multi-tenancy e utilizar uma abordagem prtica para demonstrar a
implementao de uma aplicao baseada em uma arquitetura multi-tenancy. Assim,
este captulo apresenta as definies e as caractersticas essenciais da computao em
nuvem, o modelos de servio SaaS e uma abordagem multi-tenancy para SaaS.
Este captulo est organizado no seguinte formato:
A seo 1.2apresenta os conceitos fundamentais de cloud computing, Software
como servio e Multi-tenancy.
A seo 1.3 apresenta os componentes de uma arquitetura multi-tenancy.
A seo 1.4 apresenta o passo a passo para a implementao de um prottipo de
aplicao multi-tenancy com Grails.
Finalmente, a seo 1.5 apresenta as concluses finais.
6.2 Conceitos Fundamentais
6.1.2.1 Cloud Computing
Na computao em nuvem os recursos de TI so fornecidos como um servio,
permitindo aos usurios o acessa-los sem a necessidade de conhecimento sobre a
tecnologia utilizada. Assim, os usurios e as empresas passaram a acessar os servios
sob demanda e independente de localizao, o que aumentou a quantidade de servios
disponveis. Computao em nuvem pretende ser global e prover servios para todos,
desde o usurio final que hospeda seus documentos pessoais na Internet at empresas
que terceirizaro toda a parte de TI para outras empresas.
Mas o que Cloud Computing? Segundo Taurion o termo computao em
nuvem surgiu em 2006 em uma palestra de Eric Schmidt, da Google, sobre como sua
empresa gerenciava seus data centers. Hoje, computao em nuvem, se apresenta como
o cerne de um movimento de profundas transformaes do mundo da tecnologia
(TAURION, 2009).
Segundo o NIST(National Institute of Standards and Technology) , Cloud
Computing composta por cinco caractersticas essenciais:
125

Self-service sob demanda: O usurio pode adquirir unilateralmente recurso
computacional, como tempo de processamento no servidor ou armazenamento
na rede na medida em que necessite e sem precisar de interao humana com os
provedores de cada servio.
Amplo acesso a rede: recursos esto disponveis atravs da rede e acessados por
meio de mecanismos que promovam o padro utilizado por plataformas
heterogneas (por exemplo, telefones celulares, laptops e PDAs).
Pooling de recursos: o provedor de recursos de computao so agrupados para
atender vrios consumidores atravs de um modelo multi-tenant, com diferentes
recursos fsicos e virtuais atribudos dinamicamente e novamente de acordo com
a demanda do consumidor. H um senso de independncia local em que o cliente
geralmente no tem nenhum controle ou conhecimento sobre a localizao exata
dos recursos disponibilizados, mas pode ser capaz de especificar o local em um
nvel maior de abstrao (por exemplo, pas, estado ou data center). Exemplos de
recursos incluem o armazenamento, processamento, memria, largura de banda
de rede e mquinas virtuais.
Elasticidade rpida: recursos podem ser adquiridos de forma rpida e elstica,
em alguns casos automaticamente, caso haja a necessidade de escalar com o
aumento da demanda, e liberados, na retrao dessa demanda. Para os usurios,
os recursos disponveis para uso parecem ser ilimitados e podem ser adquiridos
em qualquer quantidade e a qualquer momento.
Servio medido: sistemas em nuvem automaticamente controlam e otimizam a
utilizao dos recursos, alavancando a capacidade de medio em algum nvel de
abstrao adequado para o tipo de servio (por exemplo, armazenamento,
processamento, largura de banda, e contas de usurios ativos). Uso de recursos
pode ser monitorado, controlado e relatado a existncia de transparncia para o
fornecedor e o consumidor do servio utilizado.
Ainda segundo o NIST, Cloud Computing dividido em trs modelos de
servio:
Software como Servio (Software as a Service - SaaS): A capacidade fornecida
ao consumidor usar as aplicaes do fornecedor que funcionam em uma
infraestrutura da nuvem. As aplicaes so acessveis dos vrios dispositivos do
cliente atravs de uma relao do thin client tal como um browser web. O
consumidor no administra ou controla a infraestrutura bsica, incluindo nuvens
de rede, servidores, sistemas operacionais, armazenamento, ou mesmo
capacidades de aplicao individual, com a possvel exceo de limitada
aplicao especfica e definies de configurao de usurios da aplicao.
Plataforma como Servio (Plataform as a Service - PaaS): A capacidade
fornecida ao consumidor desdobrar na nuvem a infraestrutura consumidor
criada ou as aplicaes adquiridas criadas usando linguagens de programao e
as ferramentas suportadas pelo fornecedor. O consumidor no administrar ou
126

controlar a infraestrutura bsica, incluindo nuvens de rede, servidores, sistemas
operacionais, ou armazenamento, mas tem controle sobre os aplicativos
utilizados e eventualmente hospedagem de aplicativos e configuraes de
ambiente.
Infraestrutura como Servio (Infraestructure as a Service - IaaS) : A
capacidade prevista para o consumidor a prestao de transformao,
armazenamento, redes e outros recursos computacionais fundamental que o
consumidor seja capaz de implantar e executar programas arbitrrios, que podem
incluir sistemas operacionais e aplicativos. O consumidor no administra ou
controla a infraestrutura de nuvem subjacente, mas tem controle sobre os
sistemas operacionais, armazenamento, aplicativos implantados, e,
eventualmente, o controle limitado de componentes de rede selecionar (por
exemplo, firewalls host).
Esse trabalho no pretende abordar exaustivamente todos os modelos de servio
de Cloud Computing, esse trabalho tem como foco principal SaaS, especificamente a
aplicao da arquitetura multi-tenancy.
6.1.2.2 Software como Servio(SaaS)
Por dcadas, as companhias utilizavam seu software em sua prpria infraestrutura e
eram responsveis por todas as atividades de manuteno, integridade, escalabilidade,
disponibilidade e uma srie de encargos relacionados ao gerenciamento de TI na
empresa. Alm de custos relacionados compra de licenas e atualizaes, as empresas
tinham que adequar sua infraestrutura e contratar pessoas especializadas para as
atividades de gerenciamento.
Foi nesse contexto que surgiu o conceito de SaaS. Neste modelo, a
funcionalidade da aplicao oferecida atravs de um modelo de assinatura pela
Internet. O cliente no se torna dono do software, ao invs disso, ele aluga a soluo
total que oferecida remotamente.
Podemos dividir as aplicaes de software como servio em duas categorias
(CHONG e CARRARO, 2006):
Servios para linha de negcios (line-of-business): oferecidos a
empresas e organizaes de todos os tamanhos. Os servios de linha de negcios
geralmente so solues de negcios grandes e personalizveis direcionadas para
facilitar processos de negcios como finanas, gerenciamento da cadeia de
suprimentos e relaes com o cliente. Normalmente esses servios so vendidos
aos clientes como assinatura. Um exemplo desse tipo de servio so as solues
personalizveis do Salesforce (SALESFORCE, 2000).
Servios orientados ao consumidor: oferecidos ao pblico em geral.
Os servios orientados a cliente s vezes so vendidos como assinatura, mas
geralmente so fornecidos sem custo e financiados por anncios. Um outro
127

exemplo desse tipo de servio so os servios oferecidos pelo Google(Gmail,
Google docs, Google Agenda, etc).
Apesar do conceito de SaaS no ser uma coisa nova, esse conceito ganhou fora
somente por volta de 2005 e 2006 com o surgimento e viabilidade de uso de novas
tecnologias como web 2.0, rich internet application(RIA), SOA, cloud computing,
virtualizao, etc. Implementar o conceito de SaaS nem sempre to simples como
parece. Chong (CHONG e CARRARO, 2006) prope 4 nveis de maturidade para
aplicaes que utilizam o modelo de SaaS:

Figura 6.1 - Nveis de Maturidade SaaS (CHONG e CARRARO, 2006)

Nvel 1 Ad-Hoc/Personalizado: O primeiro nvel de maturidade semelhante
ao modelo de entrega de software do provedor de servios de aplicativos (ASP)
tradicional, que data da dcada de 1990. Nesse nvel, cada cliente tem a sua
prpria verso personalizada do aplicativo hospedado e executa a sua prpria
instncia do aplicativo nos servidores do host. Pensando em arquitetura, software
nesse nvel de maturidade muito semelhante ao software de linha de negcios
vendido tradicionalmente, em que diferentes clientes em uma organizao
conectam a uma instncia nica em execuo no servidor, mas essa instncia
totalmente independente de quaisquer outras instncias ou processos que o host
esteja executando para os seus outros clientes.
Nvel 2 Configurvel: No segundo nvel de maturidade, o fornecedor hospeda
uma instncia separada do aplicativo para cada inquilino enquanto que no
128

primeiro nvel cada instncia personalizada individualmente para o inquilino,
neste nvel todas as instncias utilizam a mesma implementao de cdigo e o
fornecedor atende as necessidades dos clientes fornecendo opes de
configurao detalhadas que permitem ao cliente alterar a aparncia e o
comportamento do aplicativo para os seus usurios. Apesar de serem idnticas
umas s outras no nvel do cdigo, cada instncia permanece totalmente isolada
de todas as demais.
Nvel 3 Configurvel e eficiente para vrios tenants: No terceiro nvel de
maturidade, o fornecedor executa uma nica instncia que serve a todos os
clientes, com metadados configurveis fornecendo uma experincia de usurio e
conjunto de recursos exclusivos para cada um. Polticas de autorizao e de
segurana garantem que os dados de cada cliente sejam mantidos separados dos
de outros clientes e que, da perspectiva do usurio final, no exista qualquer
indicao de que a instncia do aplicativo esteja sendo compartilhada entre
vrios tenants.
Nvel 4 Escalonvel, configurvel e eficiente para vrios tenants: No quarto e
ltimo nvel de maturidade, o fornecedor hospeda vrios clientes em um
ambiente com carga balanceada de instncias idnticas, com os dados de cada
cliente mantidos separados e com metadados configurveis fornecendo uma
experincia do usurio e um conjunto de recursos exclusivos para cada cliente.
Um sistema de SaaS escalonvel para um nmero de clientes arbitrariamente
grande, uma vez que a quantidade de servidores e instncias no lado do
fornecedor pode ser aumentada ou diminuda conforme necessrio para
corresponder demanda sem a necessidade de remodelar a arquitetura aplicativo,
alm do que as alteraes ou correes podem ser transmitidas para milhares de
tenants to facilmente quanto para um nico tenant.
Normalmente se esperaria que o quarto nvel fosse a meta definitiva para
qualquer aplicativo de SaaS, mas no sempre assim. necessrio verificar as
necessidades operacionais, arquiteturais e de negcio relacionadas aplicao. Uma
abordagem single-tenant faz sentido financeiramente? O seu aplicativo pode ser feito
para executar em uma nica instncia lgica? Voc pode garantir os seus contratos de
nvel de servio (SLAs) sem isolamento das aplicaes? Essas so questes que devem
ser respondidas quando se pretende adotar o modelo SaaS.
6.1.2.3 Multi-tenancy
Multi-tenancy uma abordagem organizacional para aplicaes SaaS. Bezemer
(BEZEMER e ZAIDMAN, 2010) define multi-tenancy como aplicaes que permitem
o compartilhamento dos mesmos recursos de hardware, atravs do compartilhamento da
aplicao e da instncia do banco de dados, enquanto permite configurar a aplicao
para atender s necessidades do cliente como se estivesse executando em um ambiente
dedicado. Tenant uma entidade organizacional que aluga uma aplicao multi-tenancy.
Normalmente, um tenant agrupa um nmero de usurios que so os stakeholders da
organizao.
129

A definio acima foca no que ns consideramos aspectos em aplicaes multi-tenancy:
Possibilidade de compartilhamento de recursos de hardware, permitindo a
reduo de custos (HU WANG, JIE GUO, et al., 2008) (WARFIELD, 2007).
Alto grau de configurabilidade, permitindo que cada consumidor customize sua
prpria interface e seu workflow na aplicao (NITU, 2009)(JANSEN,
HOUBEN e BRINKKEMPER, 2010).
Uma abordagem arquitetural na qual os tenants fazem uso de uma nica
aplicao e banco de dados (KWOK, NGUYEN e LAM, 2008).
Como multi-tenancy um conceito relativamente novo, muito comum as
pessoas confundirem multi-tenancy com outros conceitos j existentes. Multi-tenancy
no multi-usurio. Em uma aplicao multi-usurio ns assumimos que os usurios
esto usando a mesma aplicao com opes de acesso limitadas. Em uma aplicao
multi-tenancy ns assumimos que os tenants tem um algo grau de configurao,
dependendo da definio dessas configuraes, dois tenants pode possuir aparncia e
workflows diferentes. Um argumento adicional para essa distino que o SLA(Service
Level Agreement) para cada tenant pode ser diferente (LIN, SUN, et al., 2009).
Outra abordagem que contrasta com multi-tenancy a abordagem multi-
instance. Com o aumento da popularidade de das tecnologias de virtualizao e de cloud
Computing, multi-instance a forma fcil de criar aplicaes parecidas com multi-
tenancy. necessrio apenas criar uma imagem de maquina virtual com a aplicao pr-
configurada e, logo em seguida criar instncias apartir dessa imagem. A abordagem
multi-instance uma melhor abordagem quando o nmero de tenants for pequeno (JIE
GUO, SUN, et al., 2007).
61.3 Arquitetura Multi-tenancy

Nesse minicurso iremos tomar como base a arquitetura apresentada na Figura 6.2. Aqui
vemos que multi-tenancy afeta quase todas as camadas de uma aplicao tpica, e como
tal, possui um grande potencial para se tornar um interesse transversal. Para manter o
impacto sobre o cdigo (complexidade), as implementaes de componentes multi-
tenancy devem ser separadas da lgica dos tenants o tanto quanto possvel. Caso
contrrio, a manuteno pode se tornar um pesadelo, porque:
Implementar cdigo de requisitos da arquitetura multi-tenancy juntamente com
a lgica de negcio dos tenants em todas as camadas de aplicao, o que exige
que todos os desenvolvedores sejam reeducados sobre multi-tenancy;
Misturar multi-tenancy com cdigo de tenants leva ao aumento da
complexidade do cdigo, pois mais difcil manter o controle de onde o cdigo
multi-tenancy introduzido.
Estes dos problemas podem ser superados integrando cuidadosamente multi-tenancy na
arquitetura. No restante desta seo, descrevemos os componentes da arquitetura
130

abordada por Bezemer (BEZEMER e ZAIDMAN, 2010) para implementao de multi-
tenancy como um interesse transversal.

A. Autenticao
Pelo motivo de uma aplicao multi-tenant ter apenas uma aplicao e instancia
de banco de dados, todos os tenants usam o mesmo ambiente fsico. A fim de ser capaz
de oferecer customizao do ambiente e ter certeza de que os tenants podem acessar
somente os seus prprios dados, tenants devem ser autenticados. Enquanto autenticao
de usurio , possivelmente, j presente na aplicao de destino, um mecanismo
separado de autenticao de tenants especficos pode ser necessrio, por duas razes: (1)
geralmente muito mais fcil introduzir um mecanismo de autenticao adicional, do
que mudar um j existente, e (2) autenticao de tenants permite que um nico usurio
faa parte de mais do que uma organizao lgica, o que estende a idia de autenticao
de usurios com grupos.

B. Configurao
Em uma aplicao multi-tenancy a customizao deve ser possvel atravs de
configurao. A fim de permitir que o usurio tenha uma experincia como se ele
estivesse trabalhando em um ambiente dedicado, necessrio permitir pelo menos os
tipos de configurao seguintes:
Estilo de Layout(Layout Style) O componente de configurao de estilo de layout
permite o uso de temas e estilos especficos.
Configurao Geral (General Configuration) O componente de configurao geral
permite a especificao de configuraes especficas, como configuraes de chave de
criptografia e detalhes do perfil pessoal.
Entrada e sada de arquivo (File I/O) O componente de configurao de I/O de
arquivo permite a especificao de caminhos de arquivos, que podem ser usados para,
por exemplo, gerao de relatrio.
Fluxo de trabalho (Workflow) O componente de configurao de fluxo de trabalho
permite a configurao de fluxos especficos. Por exemplo, configurao de fluxos
necessria em uma aplicao de planejamento de recursos empresariais ERP, em que o
fluxo de requisies pode variar significativamente para diferentes companhias.

C. Banco de dados (Database)
Em uma aplicao multi-tenancy h uma grande exigncia para o isolamento dos dados.
Porque todos os tenants usam a mesma instncia de um banco de dados necessrio ter
certeza de que eles podem acessar somente seus prprios dados. Atualmente sistemas
de gerenciamento de dados (Data Base Management Systems DBMS) de prateleira
no so capazes de lidar com multi-tenancy, isso deve ser feito em uma camada entre a
131

camada lgica de negcios e o pool de banco de dados de aplicaes. As principais
tarefas dessa camada so as seguintes:
Criao de novos tenants no banco de dados Se a aplicao armazena ou recupera
dados que podem ser de tenants especficos, tarefa da camada de banco de dados criar
os registros do banco de dados correspondente quando um novo tenant se inscreveu para
a aplicao.
Adaptao de consulta A fim de prover um isolamento de dados adequado, a camada
de banco de dados deve ter certeza que consultas so ajustadas de forma que cada tenant
possa acessar somente seus prprios registros.
Balano de carga Para melhorar o desempenho de uma aplicao multi-tenancy
necessrio um balanceamento de carga eficiente para o pool de banco de dados. Note
que qualquer acordo feito no SLA de um tenant e quaisquer restries impostas pela
legislao do pas onde o tenant est localizado deve ser satisfeita. Alm disso, a
aplicao pode ter requisitos de onde os dados de um tenant esto sendo armazenados,
por exemplo, para a gerao de relatrios. Estes requisitos dificultam o uso de
algoritmos de balanceamento de carga existentes. Por outro lado, nossa expectativa a
de que possvel criar algoritmos de balanceamento de carga mais eficientes usando as
informaes que possumos sobre os tenants.

Figura 6.2- Arquitetura Multi-tenancy (BEZEMER e ZAIDMAN, 2010)
132

6.1.4 Implementando um prottipo de aplicao multi-tenancy com Grails
6.1.4.1 Introduo ao Framework Grails
Para implementar um prottipo que demonstre a aplicabilidade da arquitetura multi-
tenancy ser utilizado o framework Grails. O Grails um framework web open-source
que utiliza a linguagem Groovy, e outros frameworks consagrados como Hibernate,
Spring e Sitemesh, como mostrado na Figura 6.3. O Grails foi projetado para desenvolver
aplicaes CRUD (Create, Read, Update e Delete) de forma simples e gil, utilizando o
modelo de escrever cdigo por conveno introduzido pelo Ruby on Rails. O Grails
est se propondo a trazer a produtividade do Ruby on Rails para a plataforma Java,
porm ele possui uma grande vantagem, sendo que a linguagem Groovy roda sobre uma
JVM, e pode utilizar classes Java e as diversas APIs que existem normalmente.
Groovy (padronizado pela JSR-241) uma linguagem dinmica e gil para a
plataforma Java, que possui muitas caractersticas de linguagens de script como Ruby,
Python e Smalltalk, e ainda pode utilizar classes Java facilmente. Linguagens de script
esto ganhando cada vez mais popularidade, devido a quantidade reduzida de cdigo
fonte necessrio para implementar determinadas funcionalidades, se comparado com
uma implementao em Java.

Figura 6.3 - Arquitetura Grails
6.1.4.2 Instalando Grails
Instalar o Grails framework pode ser considerada uma tarefa simples. O passo a passo
para a instalao do Grails framework apresentado na Figura 6.4.
133

Uma vez instalado, possvel abrir um prompt de comando e testar sua instalao
utilizando, por exemplo, o comando grails help.

Figura 6.4 - Instalao Grails
Para criar uma aplicao em grails o desenvolvedor dever executar o comando:


Esse comando cria um projeto de aplicao grails contendo um conjunto de arquivos e
diretrios necessrios para executar uma aplicao grails. Os diretrios criados e suas
descries podem ser vistos com mais detalhes na Tabela 6.1.
Tabela 6.1 - Estrutura de pastas de uma aplicao Grails
Pasta Descrio
+ grails-app
+ conf Contm as configuraes da aplicao, como a
configurao de banco (DataSource.groovy) e onde
podem ser feitas as configuraes de
inicializao(BootStrap.groovy) entre outros.
+ controllers Contm as classes de controller(controladores) da
aplicao.
+ domain Contm as classes de Domnio, ou modelos.
+ i18n Contm arquivos inerentes a internacionalizao.
grails create-app multitenantapp
134

+ services Nessa pasta ficam as classes utilizadas na camada de
servios do Grails, caso sejam criadas.
+ taglib Contm as TagLibs criadas pelo usurio
+ views Contm os arquivos .gsp(Groovy Server Pages)
utilizados para cada classe de domnio.
+ layouts Nessa pasta ficam os templates da aplicao. Templates
em Grails so views includas em outras views.
+ grails-tests Parta que contm os testes unitrios
+ lib Contm as libs externas, como por exemplo os drivers de
conexo aos bancos de dados
+ src
+ groovy Contm classes groovy que no se encaixam nem em
Domain, Controller ou Service.
+ java Contm classes java que podero ser usadas na aplicao
+ web-app
+ css Contm os arquivos .css
+ images Imagens
+ js JavaScript
+ WEB-INF Arquivos relacionados ao deploy
+ index.jsp O Index da app

Para executar a aplicao criada devero ser executados os seguintes comandos:

O comando cd multitenantapp ir abrir o diretrio da aplicao e o comando grails
run-app executar a aplicao.
Para adicionar um cadastro de uma entidade (CRUD) aplicao, deve ser criado uma
classe de domnio e em seguida uma classe de controller que ir gerenciar as requisies
para o cadastro desta entidade.

O primeiro comando cria uma classe de domnio no seguinte endereo
..\multitenantapp\grails-app\domain\multitenantapp\Product.groovy. Esse arquivo
dever ser alterado para o cdigo da Figura 6.5 a seguir:

>> grails create-domain-class Product
>> grails create-controller multitenantapp Product

>> grails create-domain-class Product
>> grails create-controller multitenantapp Product

>> cd multitenantapp
>> grails run-app
135


Figura 6.5 - cdigo Product.groovy
O segundo comando cria a classe de controller, que dever ser alterada para o cdigo a
da seguir:

Figura 6.6 - Cdigo da Classe Controller
Uma vez criadas as classes de domnio e controller,o comando grails run-app dever
ser executado novamente. Aps isso ser possvel acessar o link
http://localhost:8080/multitenantapp para visualizar a primeira tela da aplicao,
mostrado na Figura 6.7, com o CRUD da entidade criada (Product).

Figura 6.7 - Tela Inicial de uma aplicao Grails

Assim, observamos que com poucos comandos temos uma pequena aplicao grails
funcionando.
6.1.4.3. Componentes de uma aplicao multi-tenancy
Para implementar uma aplicao multi-tenancy necessrio implementar autenticao,
controle de configurabilidade e controle de acesso a dados que atendam s necessidades
de uma aplicao multi-tenancy que foram descritos nos tpicos anteriores. A fim de
diminuir a complexidade da aplicao de exemplo no ser implementado o controle de
configurabilidade em nosso aplicativo de demonstrao.
136

Grails disponibiliza uma arquitetura de plugins que promove o reuso e o aumento de
produtividade. Dentre os plug-ins disponveis existem plugins que facilitam muito a
implementao de aplicaes multi-tenancy em Grails. So eles Multi-tenant Plugin
(Core) e Multi-tenant Spring Security Integration. Esses 2 plugins extendem as
funcionalidades de controle de acesso a dados e autenticao de forma a atender os
requisitos de aplicaes multi-tenant.
Para dar continuidade ao nosso exemplo prtico ser instalado agora um plugin que
adiciona a funcionalidade de autenticao em nossa aplicao. Para isso necessrio a
execuo dos comandos a seguir.

Para que esse plugin funcione necessrio que o cdigo no arquivo BootStrap.groovy
existente na pasta conf do seu projeto esteja semelhante ao cdigo apresentado na
Figura 6.8. Em Seguida j possvel re-executar a aplicao com o comando run-app e
verificar que para utilizar a aplicao agora necessrio utilizar um login e senha. As
configuraes adicionadas no arquivo BootStrap.groovy criaram no banco de dados 2
usurios(user1 e user2), ambos com senha 123.

Figura 6.8 - BootStrap.groovy (Single Tenant)
O prximo passo instalar os plug-ins necessrios para tornar nosso exemplo uma
aplicao multi-tenant. Para isso necessrio a execuo do comando a seguir em nosso
projeto.

Aps a instalao do plugin so necessrias algumas configuraes adicionais:
>> grails install-plugin multi-tenant-spring-security
>> grails install-plugin spring-security-core 1.1.2
>> s2-quickstart login SecUser Role Requestmap
137

1. Adicionar o campo Integer userTenantId na classe SecUser.groovy. Isso far
com que cada usurio esteja associado a um tenant especfico. Ao cadastrar um
usurio, ele dever possuir um valor para o campo userTenantId, isso ir indicar
quais registros do banco de dados ele ter acesso.
2. Anotar a classe Product.groovy com @MultiTenant. Em uma aplicao multi-
tenancy poderemos ter entidades que tero ou no caractersticas multi-tenancy.
Ou seja, mesmo em uma aplicao multi-tenancy poderemos ter entidades que
tero seus registros compartilhados entre todos os tenants. Para indicar quais
entidades tero seus registros filtrados por tenant utilizamos a anotao
@MultiTenant.
3. Adicionar no bloco de constraints da classe Product.groovy a seguinte linha de
cdigo tenantId(display:false). Isso far com que o campo tenantId, que
criado dinamicamente no seja alterado pelos usurios. Dado que o
gerenciamento de seu valor feito pelo plugin.
4. Altera a classe BootStrap.groovy para que o valor do atributo userTenantId seja
informado na criao dos 2 usurios padres do sistema. O cdigo da classe
BootStrap.groovy dever ficar semelhante ao cdigo apresentado na Figura 6.9.
Essa alterao far com que cada usurio padro do sistema esteja em um tenant
diferente.
5. Adicionar o cdigo da Figura 6.10 ao final do arquivo Config.groovy, localizado
na pasta conf do projeto.

Figura 6.9 - BootStrap.groovy (Multi-tenant)

Figura 6.10 - Alterao Config.groovy
138

Seguido estes passos, as funcionalidades bsicas de uma aplicao multi-tenancy esto
presentes no nosso exemplo. Para validar o funcionamento necessrio efetuar o login
com o usurio user1(senha=123) e cadastrar alguns produtos. Em seguida efetuar login
com o usurio user2 e, tambm, efetuar alguns cadastros no sistema. Ser possvel ver
que os dados cadastrados efetuados pelo usurio user1 no sero visualizados pelo
usurio user2, e vice versa. Isto ocorre porque quando esses usurios foram criados
colocados em tenants diferentes.
6.1.5. Concluso
Tomando como base a fundamentao terica e o exemplo prtico apresentado,
conclumos que possvel implementar uma aplicao multi-tenancy de forma produtiva
e com alto grau de reuso de cdigo. Apesar do exemplo prtico ser implementado em
Groovy e Grails, essa arquitetura pode ser replicada em vrias outras linguagens
existentes no mercado. Embora os esforos de pesquisa na rea de SaaS e multi-tenancy
estejam crescendo bastante ainda existem vrios pontos a serem explorados e evoludos,
como avaliao de desempenho, monitoramento de tenants, escalabilidade, migrao de
aplicaes legadas para a arquitetura multi-tenancy, entre outros.
6.1.6. Referncias
ABDUL-JAWAD,. Groovy and Grails Recipes. Berkely: Apress, 2009.
BEZEMER, C.-P.; ZAIDMAN, A. Multi-tenant SaaS applications: maintenance dream
or nightmare? ERCIM Workshop on Software Evolution (EVOL) and International
Workshop on Principles of Software Evolution (IWPSE), New York, 2010.
CHONG , ; CARRARO,. Architecture Strategies for Catching the Long Tail, 2006.
Disponivel em: <http://msdn.microsoft.com/en-us/library/aa479069.aspx>. Acesso em:
2011 out. 01.
HU WANG, Z. et al. A Study and Performance Evaluation of the Multi-Tenant Data
Tier Design Patterns for Service Oriented Computing. ICEBE '08 Proceedings of the
2008 IEEE International Conference on e-Business Engineering, Washington, DC,
2008. 94-101.
JANSEN, S.; HOUBEN, G.-J.; BRINKKEMPER, S. Customization realization in
multi-tenant web applications: case studies from the library sector. Proceeding
ICWE'10 Proceedings of the 10th international conference on Web engineering,
Berlin, Heidelberg, 2010. 445-459.
JIE GUO, et al. A Framework for Native Multi-Tenancy Application Development and
Management. 9th IEEE International Conference on E-Commerce Technology and
the 4th IEEE International Conference on Enterprise Computing, E-Commerce,
and E-Services, Tokyo, 2007. 551 - 558.
KLEIN, D. Grails: A Quick-Start Guide. [S.l.]: Pragmatic Bookshelf, 2009.
KWOK, T.; NGUYEN, T.; LAM, L. A Software as a Service with Multi-tenancy
Support for an Electronic Contract Management Application. International
Conference on Services Computing. Washington: IEEE Computer Society. 2008. p.
179-186.
139

LIN, H. et al. Feedback-Control-Based Performance Regulation for Multi-Tenant
Applications. 15th International Conference on Parallel and Distributed Systems
(ICPADS). Shenzhen: IEEE. 2009. p. 134 - 141.
MELL , P.; GRANCE,. Draft nist working definition of cloud computing - v15.
National Insitute of Standards and Technology, 2009. Disponivel em:
<http://www.nist.gov/itl/cloud/upload/cloud-def-v15.pdf>. Acesso em: 1 out. 2011.
NITU. Configurability in SaaS (software as a service) applications. Proceedings of the
2nd annual India Software Engineering Conference (ISEC), Pune, India, 2009. 19-
26.
ROCHER, G. K. The Definitive Guide to Grails. Berkely: Apress, 2006.
SALESFORCE, 2000. Disponivel em: <http://www.salesforce.com>. Acesso em: 2011
out. 1.
SMITH, G.; LEDBROOK, P. Grails in Action. Greenwich: Manning Publications,
2009.
TAURION, C. Cloud Computing: Computao em Nuvem: Transformando o mundo
da tecnologia da informao. Rio de Janeiro: Brasport, 2009.
WARFIELD, B. Multitenancy Can Have a 16:1 Cost Advantage Over Single-Tenant.
SmoothSpan Blog, 2007. Disponivel em:
<http://smoothspan.wordpress.com/2007/10/28/multitenancy-can-have-a-161-cost-
advantage-over-single-tenant/>. Acesso em: 17 out. 2011.



140
Captulo
7
Introduco a Agentes Autnomos e Sistemas Multiagentes
Samy S
1
, Joo Alcntara
1

1
Departamento de Computao Universidade Federal do Cear (UFC)
Caixa Postal 12.166 60.455-970 Fortaleza CE Brazil
{samy,jnando}@lia.ufc.br
Abstract. The goal of this chapter is to introduce the main concepts in the area
of autonomous agents and multiagent systems. Starting with the question "What
is an agent?", we discuss the key aspects of building agents and agent
societies. For each such concept, we provide some intuition about it, its
formalization, illustrations and examples. In the beginning, we consider the
properties of a single agent and its relation towards the environment in which it
exists. Next, we step up to observe agents societies and the peculiarities that
emerge from the plurality of autonomous self-interested entities. In such
situations, it is possible that agents get involved in situations of conflict or
cooperation, or that some coordination of their actions is required to assure their
goals can be achieved.
Resumo. O objetivo deste captulo introduzir os principais conceitos da rea
de agentes autnomos e sistemas multiagentes. Comeando pela pergunta "O
que um agente?", abordamos os aspectos-chave para a contruo de
agentes autnomos e sociedades de agentes. Para cada conceito abordado,
fornecemos uma intuio sobre o mesmo, sua formalizao, ilustraes e
exemplos. Inicialmente, consideramos as propriedades de um nico agente e
sua relao com o ambiente em que existe. Em seguida, passamos a observar
sociedades de agentes e as peculiaridades emergentes da pluralidade de
entidades autnomas dotadas de interesses prprios. Em tais situaes,
possvel que os agentes se envolvam em situaes de disputa ou cooperao,
ou que precisem coordenar suas aes para garantir que seus objetivos
possam ser cumpridos.
7.1. O que so agentes?
Nesta seo, vamos definir o que so agentes e abordar alguns aspectos sobre como
constru-los. No entanto, devemos destacar que a definio de agente controversa,
pois depende muito do domnio do problema a ser explorado. Apesar disso, todos ns
iremos concordar que uma caracterstica central que todo agente deve ter o da
autonomia. Mas o que vem a ser essa autonomia? Responder essa pergunta no
fcil e ir depender mais uma vez do tipo de problema que estamos lidando. Para
alguns problemas, autonomia pode ser entendida como a capacidade de aprender a
partir da prpria experincia; j em outras aplicaes, aprendizagem um aspecto a
ser evitado. Comearemos, ento, com uma definio de agentes adaptada de
[Wooldridge and Jennings 1995]:
Um agente um sistema computacional que est situado em algum ambiente e
capaz de aes autonmas nesse ambiente com o propsito de alcanar os
objetivos que lhe foram delegados. O que precisamos comprender que agentes
devem decidir por conta prpria o que precisa ser feito para alcanar os objetivos
propostos em vez de receber comandos para tal fim. Em suma, um agente deve ser
141
no s capaz de tomar decises, mas tambm de escolher que aes tomar e quando
execut-las.


Figura 7.1. Um agente em seu ambiente
Como ilustrado na Figura 7.1, um agente percebe o ambiente no qual ele est
inserido atravs de sensores. Como resultado dessa percepo, o agente produz
como sada uma ao que ir, por sua vez, alterar o ambiente. Esse processo de
percepo/ao continua ciclicamente e a base do funcionamento de um agente.
No obstante, na maioria dos problemas de interesse prtico, um agente ir possuir
um controle parcial sobre o ambiente. Isso quer dizer que a mesma ao executada
duas vezes em circunstncias aparentemente idnticas podem ocasionar resultados
completamente diferentes, podendo, em particular, falhar na obteno dos resultados
esperados. Podemos, assim, dizer que os ambientes em geral so no-
determinsticos.
No presente contexto, devemos compreender autonomia como a habilidade de
decidir como agir para alcanar os objetivos delegados. Mas at que ponto um agente
autnomo? Um agente, por exemplo, no deve ter autonomia para escolher o
objetivo a ser alcanado pelo sistema; sua autonomia limita-se, portanto, a buscar os
meios para alcanar esse objetivo. Alm disso, nem todo agente possui o mesmo nvel
de autonomia. Por exemplo, um agente participante de uma operao mdica no
deve ter a mesma autonomia de um agente responsvel por desligar os quartos de um
hotel quando no houver ningum presente.
Mais recentemente, tem-se recorrido ideia de agentes com a autonomia
ajustvel de acordo com as circunstncias. O princpio geral que um agente deve
entregar o poder de tomar deciso para uma autoridade maior (um ser humano)
quando
Ele acredita que isso trar grandes benefcios;
Ambiente com alto grau de incerteza;
A deciso pode causar danos;
Incapacidade do agente de tomar deciso.
7.1.1. Agentes Inteligentes
Com base no que foi exposto, podemos perceber que a noo de agente bastante
abrangente e vai de um simples interruptor de luz ou um termostato ao complexo
sistema de controle de uma nave espacial no-tripulada. No entanto, nem todos esses
agentes (como o caso do termostato) so inteligentes. Mas o que seria um agente
inteligente? De acordo com [Wooldridge and Jennings 1995], um agente inteligente
se ele possui
Reatividade
142
Proatividade
Habilidade Social
7.1.1.1. Reatividade
Agentes inteligentes devem perceber seu ambiente e responder atempadamente s mu-
danas ocorridas nele para satisfazer os seus objetivos. Agora se as nicas mudanas que
ocorrem no ambiente so resultantes das aes do agente, ele no precisar se preocu-
par com essas mudanas, pois as ter sobre controle. No obstante, o mundo no bem
assim: os ambientes so normalmente dinmicos e as mudanas ocorrem independen-
tes do agente, dicultando sobremaneira o desenvolvimento de sistemas computacionais
ecientes. Podemos denir um sistema reativo como aquele que mantm uma interao
contnua com o seu ambiente e responde em tempo hbil s mudanas que ocorrem nele.
7.1.1.2. Proatividade
Desenvolver agentes reativos considerado relativamente simples na medida que para
cada estmulo percebido do ambiente, haja uma regra que permita ao agente dar a resposta
mais adequada. Em geral, no entanto, ns queremos que os agentes executem tarefas para
ns. Com isso, agentes inteligentes devem tambm ser proativos, ou seja, devem exibir
um comportamento orientado a objetivos, tomar a iniciativa para alcan-los alm de
reconhecer novas oportunidades.
7.1.1.3. Habilidade Social
O mundo real um mundo com multiagentes; em pouqussimas tarefas, podemos alcanar
algum xito sem a ajuda de outros. O problema que nem todo mundo compartilha os
nossos mesmos objetivos, sendo muita vezes necessrio negociar e cooperar com outros.
Algo similar ocorre num ambiente computacional. Nesse sentido, a habilidade social de
um agente deve ser compreendida como a sua capacidade de interagir com outros agentes
(e possivelmente humanos) atravs de alguma linguagem de comunicao de agentes.
Atravs dessa linguagem os agentes podem
Cooperar: neste caso, os agentes trabalham como se estivessem num time com o obje-
tivo de alcanar um objetivo em comum. Os agentes cooperam quando um agente
sozinho no capaz de alcanar o objetivo ou quando o trabalho conjunto ir
produz um resultado melhor .
Coordenar: nem sempre dois ou mais agentes podem usar o mesmo recurso ao mesmo
tempo. Assim preciso que eles coordenem suas atividades de modo que os agen-
tes envolvidos possam fazer uso do recurso.
Negociar: a habilidade de fazer acordos sobre assuntos de interesse em comum. Se
voc quer assistir TV e seu irmo quer estudar, um possvel acordo voc ligue a
TV, mas com volume baixo. Tipicamente, negociao envolve proposta e contra-
proposta com compromissos feitos pelos participantes.
Essas habilidades sociais sero esmiuadas mais adiante.
143
7.1.1.4. Algumas Propriedades que Agentes Podem Ter
Alm das propriedades citadas um agente (inteligente) pode ter
Mobilidade: habilidade do agente se mover. Para um agente software, esse movi-
mento por volta de uma rede eletrnica;
Veracidade: se um agente ir propositalmente comunicar informao falsa para
alcanar seu objetivo;
Benevolncia: se agentes possuem objetivos conitantes e se nesse caso, eles vo
se ajudar entre si;
Racionalidade: se um agente ir agir para alcanar seus objetivos e no ir delibe-
radamente agir para evitar esse alcance;
Aprendizagem/adaptao: se os agentes melhoram o seu desempenho com o de-
correr do tempo.
7.1.2. Arquitetura Abstrata para Agentes
Vamos agora formalizar a noo de agente da qual temos discutido. Primeiramente, ire-
mos caracterizar o ambiente simplesmente como umconjunto nito, discreto E de estados
instantneos:
E = {e, e

, . . .}.
Os agentes possuem um repertrio de aes disponveis, que podem ser usadas
para transformar o estado do ambiente. Seja
Ac = {a, a

, . . .}
o conjunto (nito) dessas aes.
A ideia geral que o ambiente comea em algum estado e
0
E. Ento o agente
inicia escolhendo uma ao
0
Ac. Como resultado dessa ao, o ambiente poder
escolher (inclusive no-deterministicamente) dentre umcerto nmero de estados possveis
aquele que servir de resposta para o agente (chamemo-lo de e
1
). Com base nesse estado
e
1
, o agente ter que escolher uma ao para executar, que ir, por sua vez, provocar uma
resposta do ambiente e assim por diante. Uma execuo r de um agente em um ambiente
, portanto, uma sequncia alternada de estados do ambiente e aes:
r e
0

0
e
1

1
e
2

2
e
3

u1
e
u
.
Sejam
R o conjunto de todas as sequncias nitas possveis (sobre E e Ac);
R
Ac
o subconjunto dessas sequncias que terminam em ao;
R
E
o subconjunto dessas sequncias que terminam em um estado.
Ns usaremos r, r

, . . . para nos referirmos aos membros de R. Para representar

o efeito que as aes do agente acarretam no ambiente, ns introduzimos a funo de
transformao de estados:
R
Ac
2
E
.
144
Observe que a funo de transformao de estados recebe uma execuo termi-
nando em uma ao do agente e retorna um conjunto de possveis estados que poderiam
servir de respostas a . Essa denio deixa claro que o ambiente dependente do seu
histrico, ou seja, o prximo estado do ambiente no somente determinado pela ltima
ao do agente e pelo estado corrente, mas por tudo que ocorreu antes. O segundo aspecto
a destacar que essa denio permite a denio de ambientes no-determinsticos.
Quando (r) = , temos que a execuo r terminou. Vamos assumir em nosso
sistema que todas as execues chegam a um m em algum momento.
Formalmente, um ambiente uma tripla Env = E, e
0
, T, em que E um con-
junto de estados, e
0
E um estado inicial e uma funo transformadora de estados.
Ns podemos agora formalizar a noo de agente como sendo a funo
Ag R
E
Ac
Um agente, portanto, toma decisoes sobre que ao executar com base no histrico
do sistema at aquele momento. Chamemos de AG o conjunto de todos os agentes.
Ns denimos um sistema como um par contendo um agente e um ambiente;
todo sistema ser associado com um conjunto de execues possveis. Ns denotamos o
conjunto de todas as execues de Ag em um ambiente Env por R(Ag, Env). Por simpli-
cidade, R(Ag, Env) conter apenas execues r que terminam ((r) = ). Formalmente,
uma sequncia
(e
0
,
0
, e
1
,
1
, e
2
, . . .)
representa uma execuo de um agente Ag num ambiente Env = E, e
0
, se
1. e
0
o estado inicial de Env
2.
0
= Ag(e
0
) e
3. para u > 0
e
u
((e
0
,
0
, . . . ,
u1
)) e
u
= Ag((e
0
,
0
, . . . , e
u
)).
Dois agentes Ag
1
e Ag
2
possuem comportamentos equivalentes com relao a um
ambiente Env se R(Ag
1
, Env) = R(Ag
2
, Env).
Alguns agentes so puramente reativos, isto , decidem com base exclusivamente
no presente e no levam conta o seu histrico:
Ag Env Ac.
O termostato um exemplo de agente reativo, podendo ser denido como
Ag(e) =
desligado se e = temperatura ok
ligado caso contrrio
Ns precisamos agora renar nosso modelo de agente e separar a deciso de um
agente em dois subsistemas: percepo e ao. Ademais, os agentes tm alguma estrutura
de dados interna que permita registrar a informao sobre os estados e o histrico (veja
Figura 7.2).
145
Figura 7.2. Um agente com estado
Nessa arquitetura, a funo veja tem como objetivo representar a habilidade do
agente de capturar o seu ambiente. No mundo real, essa funo implementada em
hardware como um sensor ou uma cmera de vdeo por exemplo. Matematicamente,
podemos den-la como
veja E Per,
em que Per um conjunto de percepes. J a funo ao representa o processo de
tomada de deciso do agente. Essa funo vai receber como entrada o estado interno em
que o agente se encontra e retornar a ao a ser tomada:
ao I Ac,
em que I o conjunto de todos os estados internos do agente. A atualizao do estado in-
terno do agente feita pela funo prximo a partir do estado atual e das novas percepes
obtidas pelo agente:
prximo I Per I.
O comportamento de um agente baseado em estados pode ser sumarizado como segue:
1. Agente Ag comea em algum estado interno i
0
.
2. Ag observa o estado do seu ambiente e e gera uma percepo veja(e).
3. O estado interno de Ag atualizado via funo prximo e passa a ser
prximo(i
0
, veja(e)).
4. A ao selecionada por Ag ao(prximo(i
0
, veja(e))). Essa ao ento exe-
cutada.
5. V para (2).
7.1.3. Abordagens para a Construo de Agentes
Na sequncia, iremos mostrar as principais abordagens desenvolvidas para a construo
de agentes: agentes como provadores de teorema, programao orientada a agentes, agen-
tes reativos e agentes hbridos.
146
7.1.3.1. Um Agente como um Provador de Teoremas
Na abordagem tradicional de Inteligncia Articial, IA simblica, o comportamento inte-
ligente gerado em um sistema atravs de uma representao simblica do seu ambiente e
do comportamento desejado. Partindo desse pressuposto e recorrendo s frmulas lgicas
para fazer essa representao, em [Genesereth and Nilsson 1987] os autores desenvolve-
ram um modelo simples de agente baseado em lgica. Em tais agentes, o estado interno
assumido ser um banco de dados de frmulas da Lgica Clssica de Primeira Ordem. A
ideia bsica usar lgica para codicar uma teoria retratando a melhor ao a ser execu-
tada numa dada situao.
Assim sendo, sejam L um conjunto de sentenas da Lgica Clssica de Primeira
Ordem, D = 2
L
, o conjunto dos conjuntos de frmulas de L. O estado interno de um
agente , ento, um elemento de D. Ns escrevemos ,
1
, . . . para membros de D.
O processo de tomada de deciso de um agente modelado atravs de um conjunto de
regras de deduo . Essas so regras simples de inferncia para a lgica. Ns escrevemos

se a frmula pode ser provada do banco de dados usando somente regras de

deduo . A funo de percepo do agente veja permanece a mesma:
veja S Per
Similarmente, a funo prximo tem a forma
prximo D Per D
Essa funo prximo mapeia, portanto, um banco de dados e uma percepo em
um novo banco de dados. No entanto, a funo de seleo de novas aes
ao D Ac
denida em termo de suas regras de deduo. O pseudo-cdigo dessa funo dado
pelo algoritmo abaixo:
Algorithm 1 Ao( D) retorna uma ao Ac
1: begin
2: for cada Ac do
3: if

Faa() then
4: return
5: end if
6: end for
7: for cada Ac do
8: if

Faa() then
9: return
10: end if
11: end for
12: return null
13: end
147
A ideia que o programador do agente ir codicar as regras de deduo e
um banco de dados de um modo tal que se uma frmula Faa() possa ser derivada,
em que um termo que denota uma ao, ento a melhor ao a ser executada.
Nesta abordagem, o processo de tomada de deciso visto como uma deduo, sendo
esse processo codicado como uma teoria lgica e a parte de selecionar uma ao reduz-
se a um problema de prova. Essa abordagem elegante e possui uma semntica bem
denida. No obstante, problemas relacionados a sua alta complexidade computacional
tornam questionveis se agentes como provadores de teorema podem ser empregados em
ambientes que requerem decises rpidas. Alm disso, eles partem do pressuposto que o
mundo no ir mudar de modo signicativo enquanto o agente est decidindo o que fazer.
Quando isso no se aplica, essa abordagem poder acarretar em resultados indesejveis.
7.1.3.2. Programao Orientada a Agentes
Em 1990, Yoav Shoham introduziu um novo paradigma de programao baseado numa
viso societria da computao. Chamado de "programao orientada a agentes", sua
principal ideia permitir programar agentes diretamente em termos noes como crena,
compromisso e inteno. A primeira implementao desse paradigma foi a linguagem de
programao Agent0. Nessa linguagem, um agente especicado como um conjunto de
capacidades (coisas que ele pode fazer), um conjunto de crenas iniciais, um conjunto de
compromissos iniciais e um conjunto de regras de compromisso. O componente-chave
que determina como o agente agente vai agir o conjunto de regras de compromissos.
Cada regra de compromisso contm uma condio de mensagem, uma condio mental
e uma ao. Para determinar se uma regra pode ser aplicada, a condio de mensagem
confrontada com as mensagens que o agente recebeu; a condio mental confron-
tada com as crenas do agente. Se essas condies forem satisfeitas, o agente torna-se
comprometido quela ao.
Aes em Agent0 podem ser privadas, correspondendo a uma sub-routina execu-
tada internamente ou comunicativa (envio de mensagens). Por sua vez, mensagens so
restritas a trs tipos: requests or unrequests para respectivamente se comprometer a
ou declinar a execuo de aes e mensagens do tipo inform. de se destacar que men-
sagens request e unrequest resultam tipicamente na modicao dos compromissos do
agente, enquanto que mensagens inform alteram as crenas do agente. A seguir, mostra-
mos um exemplo de regra de compromisso em Agent0:
COMMIT(
( agent, REQUEST, DO(time, action)
), ;;; msg condition
( B,
[now, Friend agent] AND
CAN(self, action) AND
NOT [time, CMT(self, anyaction)]
), ;;; mental condition
self,
DO(time, action)
)
148
Essa regra pode ser parafraseada da seguinte maneira: se eu recebo uma mensa-
gem de agent que me solicita executar action em time e eu acredito que
agent um amigo no momento atual;
eu posso fazer essa ao;
em time, eu no estou comprometido em fazer qualquer outra ao,
ento eu me comprometo a fazer action em time.
7.1.3.3. Agentes Reativos
Dois problemas principais so vericados com as abordagens baseadas em representao
lgica/simblica dos agentes:
Problema da Transduo: como traduzir o mundo real numa representao simblica?
Problema da Representao/Raciocnio: como representar simbolicamente informa-
o sobre complexas entidades do mundo real e raciocinar com elas eciente-
mente?
As diculdades de lidar com esses problemas nas abordagens simblicas levaram
muitos pesquisadores a investigar alternativas. Uma delas a abordagem reativa, que
tem esse nome porque tais sistemas so frequentemente percebidos como simplesmente
reagindo a um ambiente sem raciocinar sobre ele. Um dos pesquisadores que estudou
essa abordagem, Rodney Brooks, argumentou o seguinte:
1. Comportamento inteligente pode ser gerado sem representao explcita do tipo
que a IA simblica prope.
2. Comportamento inteligente pode ser gerado sem raciocnio abstrato explcito do
tipo que a IA simblica prope.
3. Inteligncia uma propriedade emergente de certos sistemas complexos.
Ele identifca duas ideias centrais em sistemas reativos:
1. Situado e encorpado: inteligncia real situada no mundo; no so sistemas
desencorpados tais como provadores de teorema ou sistemas especialistas.
2. Inteligncia e emergncia: comportamento inteligente surge como um resultado
da interao de um agente com o seu ambiente. Ademais, inteligncia est no olho
do observador; no uma propriedade inata e isolada.
Para ilustrar suas ideias, Brooks construiu alguns agentes baseados em sua arquitetura da
subsuno. Nesse trabalho, podemos identicar que no processo de tomada de deciso do
agente feito atravs de um conjunto de comportamentos de realizao de tarefas. Cada
comportamento pode ser visto como uma simples regra situao ao, que mapeia
uma entrada de dados (perceptual) diretamente em aes. Alm do mais, cada comporta-
mento compete com outros pelo controle sobre o agente. Uma outra caracterstica dessa
abordagem que ela est dividida em camadas que formam uma hierarquia, sendo que
as camadas inferiores representam tipos mais primitivos de comportamentos (tais como
evitar obstculos) e tm precedncia sobre camadas superiores dessa hierarquia (Figura
7.3).
149
Figura 7.3. Exemplo de mquina baseada em arquitetura da subsuno
vlido mencionar que uma das vantagens desses sistemas baseados em arqui-
tetura da subsuno a sua simplicidade aliada sua ecincia computacional, sendo
empregado em situaes que exigem um rpido tempo de resposta. Em [Steels 1990], por
exemplo, o autor prope um agente baseado em arquitetura da subsuno concebido para
explorar planetas distantes.
7.1.3.4. Agentes Hbridos
Muitos pesquisadores tm argumentado que tanto uma abordagem que seja completa-
mente deliberativa quanto um que seja completamente reativa no so apropriadas para a
construo de agentes. Em funo disso, eles sugeriram um sistema hbrido que buscasse
tirar proveito das boas qualidades de ambas as abordagens. Um caminho direto para tal
sistema seria o de construir um agente a partir de dois (ou mais) subsistemas:
Subsistema Deliberativo: contm um modelo simblico do mundo que desen-
volve planos e toma decises maneira proposta pela IA Simblica;
Subsistema Reativo: capaz de reagir a eventos sem ter que fazer raciocnios
complexos.
De um modo geral, o componente reativo tem precedncia sobre a parte delibera-
tiva. Pode-se ainda argumentar que essa forma de estruturao leva naturalmente ideia
de arquitetura em camadas, das quis TouringMachines [Ferguson 1992] and InteRRaP
[Mller and Pischel 1993] so dois bem conhecidos exemplos. Em tais arquiteturas, os
subsistemas de controle de um agente so dispostos numa hierarquia com as camadas
mais altas lidando com informao cada vez mais abstrata.
Um problema central nessas arquiteturas que tipo de estrutura de controle em-
butir nos subsistemas do agente para gerir as interaes entre as vrias camadas. Em todo
caso, podemos identicar dois tipos de uxo de controle nessas arquiteturas por camadas:
Camada horizontal: cada camada est diretamente conectada s entradas senso-
riais e as aes retornadas como sadas (Figura 7.4(a)). Note que como se cada
camada agisse como um agente, produzindo sugestes sobre que ao executar.
Camada vertical: nesse tipo de arquitetura entradas sensoriais e as aes como
sada so lidadas cada uma por no mximo uma camada (Figuras 7.4(b) e (c)).
150
Figura 7.4. Agentes Hbridos
7.2. Sistemas Multiagentes
At o momento temo-nos concentrado na construo de um agente. No entanto, exce-
o de sistemas extremamente triviais, no iremos encontrar um sistema com um nico
agente. A razo que um sistema contm um nmero de subsistemas que devem intera-
gir uns com os outros com o objetivo de executar suas tarefas com xito. O ponto-chave
agora no como construir um agente, mas como construir uma sociedade de agentes. A
Figura 7.5 ilustra a estrutura tpica de um Sistema Multiagente.
Figura 7.5. Estrutura tpica de um Sistema Multiagente
Um aspecto fundamental aqui a interao entre agentes. Num sistema multia-
gentes, os agentes so capazes de agir num ambiente; diferentes agentes tm diferentes
esferas de inuncia, ou seja, as partes do ambiente sobre a qual os agentes vo ter al-
guma forma de controle. Esferas de inuncia com reas em comum do margem para
151
uma relao de dependncia entre os agentes. Por exemplo, dois agentes robs podem ser
capazes de passar por uma porta, mas ambos no podero fazer isso simultanemente.
Num sistema multiagente, iremos encontrar duas maneiras distintas (muitas vezes
conitantes) de se analisar um agente:
Na perspectiva de quem construiu um agente individual, espera-se que esse agente
faa o melhor para ele.
Na perspectiva de quem projetou o sistema multiagente, o sistema deve otimizar
o desempenho do sistema como um todo.
Um bom sistema multiagente aquele que consegue satisfazer essas duas perspec-
tivas e evitar conitos. Ademais, no que tange aos tipos de interaes que podem ocorrer
entre os agentes, podemos destacar:
Coordenao : objetivo que um agente pelo menos no interra no trabalho do outro.
Eles podem, inclusive, coordenarem entre si para que um agente possa ajudar um
outro.
Comunicao : coordenao normalmente requer comunicao entre os agentes.
Cooperao : Dependendo do objetivo de cada agente, quando um agente coordena ele
pode tambm querer cooperar ou ainda competir.
Negociao : se um agente age por interesse prprio, ento cooperao descartada, mas
agentes podem recorrer a uma negociao para alcanar cooperao.
Em suma, um sistema multiagente consiste de um nmero de agentes que intera-
gem entre si. No caso mais geral, eles vo agir para atender os propsitos para os quais
foram projetados, podendo ter diferentes objetivos e motivaes. No obstante, para que
essa interao seja exitosa, eles tero que cooperar, coordenar e negociar uns com os
outros [Wooldridge 2009].
7.3. Interaes entre Agentes
Como sugerido anteriormente na Figura 7.5, as esferas de inuncia dos agentes em um
sistema podem coincidir. Quando isso acontece, abre-se espao para conitos, mas tam-
bm para ganhos mtuos. De certa maneira, o que faz um sistema multiagentes so o
conjunto de entidades autnomas (s quais chamamos de agentes) e as interaes entre as
mesmas. Portanto, compreender que tipo de interaes se do entre os agentes e em que
situaes elas ocorrem de extrema importncia ao nos depararmos com algo que parea
um domnio multiagentes.
7.3.1. Utilidades e Preferncias
Para simplicar o entendimento dos conceitos a seguir, vamos nos restringir a sistemas
com apenas dois agentes, os quais chamaremos de i e j, respectivamente. Assumimos que
cada um desses agentes tem interesses prprios ( self-interested), ou seja, cada agente
tem suas prprias preferncias e desejos sobre como o mundo deveria ser. No momento,
tambm no vamos nos preocupar com a origem desses desejos e preferncias. Considere
= {
1
,
2
, . . . , }, o conjunto de todos os possveis estados ou resultados (outcomes)
sobre os quais os agentes tm preferncias.
As preferncias dos agentes so capturadas por funes de utilidade, uma para
cada agente, que designam um nmero real para cada resultado em . Esse nmero real
152
indica o quo favorvel o agente acredita que esse resultado lhe , de forma que, quanto
maior o nmero, mais o agente tem interesse naquele estado. Dessa forma, a funo de
utilidade do agente i ser
u
i
R
e as preferncias do agente j so capturadas pela funo de utilidade
u
j
R.
Note que, para cada agente, a relao = {(,

) u
i
() u
i
(

)}
uma ordem parcial, isto , uma relao reexiva, transitiva e anti-simtrica.
7.3.2. Encontros entre Agentes
Vamos agora considerar um modelo para o ambiente no qual os agentes agem. Conside-
raremos que os agentes escolhem simultaneamente que ao iro executar no ambiente
e que um dos estados de ser o resultado dessas escolhas. O resultado depender de
que ao cada agente executa, portanto ambos os agentes podem inuenciar no resultado.
Assumimos tambm que os agentes precisam executar uma ao, ou seja, no podem in-
uenciar o resultado ao permanecer inativos, mas precisam escolher entre uma das aes.
Alm disso, assumiremos que um agente no pode inuenciar e nem sabe qual ser a ao
executada pelo outro agente.
Para simplicar ainda mais, assumiremos que cada agente s tem duas opes
de ao para executar. Chamaremos s opes de C (cooperar) e A (abster-se), ter-
minologia que ser utilizada em um exemplo frente. Seja Ac = {C, A}, o ambiente
modicado de acordo com a funo
Ac Ac ,
onde a primeira ocorrncia de Ac a ao do agente i e a segunda ocorrncia a
ao de j. Essa funo , essencialmente, uma funo de transformao de estados, como
discutido na Seo 1.2.
Eis um exemplo de funo de ambiente:
(A, A) =
1
, (A, C) =
2
, (C, A) =
3
, (C, C) =
4
(3.1)
Nessa funo, cada combinao de aes dos agentes leva a um resultado dife-
rente. Isso signica que o ambiente sensvel s escolhas dos agentes. Em um outro
extremo, os agente poderiam ser completamente incapazes de inuenciar no seu ambi-
ente. Nesse caso, a funo de ambiente mapearia todas as combinaes de aes para o
mesmo resultado.
(A, A) =
1
, (A, C) =
1
, (C, A) =
1
, (C, C) =
1
(3.2)
No exemplo acima, no importa o que os agentes faam. Uma outra possibili-
dade que apenas um dos agentes possa inuenciar no ambiente. No exemplo abaixo, o
ambiente varia somente de acordo com as escolhas do Agent j.
(A, A) =
1
, (A, C) =
2
, (C, A) =
1
, (C, C) =
2
(3.3)
153
Como podemos observar, as escolhas de i no interferem no ambiente.
Consideremos novamente o cenrio (3.1), em que os dois agentes tm inuncia
no ambiente, mas agora vamos levar em conta as suas preferncias. Suponhamos que as
preferncias dos agentes so dadas pelas seguintes funes de utilidade:
u
i
(
1
) = 1 u
i
(
2
) = 1 u
i
(
3
) = 4 u
i
(
4
) = 4
u
j
(
1
) = 1 u
j
(
2
) = 4 u
j
(
3
) = 1 u
j
(
4
) = 4
Nesse caso, podemos relacionar as escolhas dos agentes s utilidades atribudas a
cada resultado da seguinte maneira:
u
i
((A, A)) = 1 u
i
((A, C)) = 1 u
i
((C, A)) = 4 u
i
((C, C)) = 4
u
j
((A, A)) = 1 u
j
((A, C)) = 4 u
j
((C, A)) = 1 u
j
((C, C)) = 4
Neste caso, a preferncia do agente i dada pela ordem parcial
u
i
((C, C)) u
i
((C, A)) > u
i
((A, C)) u
i
((A, A)),
sugerindo que o agent i deve cooperar para obter um resultado mais satisfatrio.
Dizemos que essa a opo racional, pois no h nenhum cenrio em que ele tenha
vantagem se agir de maneira diferente.
As preferncias dos agentes podem ser apresentadas de maneira concisa em uma
matriz de payoffs:
Figura 7.6. A matrix de payoffs para os agentes i e j.
Em uma matriz de payoffs, o agente i joga de acordo com as colunas e recebe a
recompensa de cima em cada clula. Similarmente, as jogadas do agente j esto repre-
sentadas nas linhas e a utilidade alcanada em cada caso o nmero de baixo em cada
clula.
7.3.3. Extratgias Dominantes
Dado um encontro envolvendo dois agentes i e j, cada um deve decidir sobre que ao
tomar. Um agente decide por sua aes de maneira racional se pesa, em cada escolha,
os possveis cenrios que podem resultar de suas aes e as utilidades destes. Sejam

1
,
2
, dizemos que
1
domina
2
se cada resultado em
1
prefervel sobre cada
resultado em
2
.
154
Por exemplo, considere = {
1
,
2
,
3
,
4
}, com u
i
(
1
) > u
i
(
2
) > u
i
(
3
) >
u
i
(
4
),
1
= {
1
,
2
} e
2
= {
3
,
4
}. Nesse caso, dizemos que
1
domina fortemente

2
, pois u
i
(
1
) > u
i
(
3
), u
i
(
1
) > u
i
(
4
), u
i
(
2
) > u
i
(
3
) e u
i
(
2
) > u
i
(
4
).
Uma vez que os conceitos discutidos nessa seo so provenientes de teoria dos
jogos, vamos comear a falar de aes possveis como estratgias. Dessa forma, os agen-
tes devem escolher que estratgias vo adotar em cada situao. Denotemos por s

, o
conjunto de resultados que podem ser alcanados quando o agente i escolhe e joga de
acordo com a estratgia s. Nos exemplos da Seo 3.2, teramos, portanto, C

= {
3
,
4
},
enquanto que A

= {
1
,
2
} para o agente i. Dizemos que uma estratgia s
1
domina
fortemente outra estratgia s
2
se s

1
domina fortemente s

2
. Se uma estratgia s
i
domina
fortemente a todas as outras estratgias acessveis a um agente, dizemos que s
i
uma
estratgia dominante.
A intuio por trs de uma estratgia dominante que esta garante ao agente
alcanar os melhores resultados possveis, ou seja, maximizar a sua utilidade. Quando
existe uma estratgia dominante, o melhor que o agente tem a fazer jogar por ela, pois
os desvios podem lhe levar a recompensas menores ou cenrios envolvendo perdas.
Quando temos dois ou mais agentes em uma mesma situao, podemos perceber
que, por vezes, as estratgias dominantes de cada agente o so por inuncia mtua.
Nesse caso, dizemos que as estratgias se encontram em equilbrio, pois nenhum agente
tem incentivo para desviar-se dessa escolha de estratgias. Esse conceito o de Equilbrio
de Nash e um dos mais importantes em Teoria dos Jogos e na anlise de interaes entre
agentes. Um cenrio de interao entre agentes pode ter zero, um ou vrios equilbrios de
Nash.
7.3.4. O Dilema dos Prisioneiros
Considere o seguinte cenrio:
Dois homens so presos e acusados de terem cometido um crime juntos. Os prisi-
oneiros so mantidos em celas separadas e no tm como se comunicar. A cada um dos
homens dito o seguinte:
1. Se um dos dois confessar o crime, mas o outro no o zer, o que tiver confessado
ser absolvido e o outro cumprir pena de 3 anos;
2. Se os dois confessarem o crime, cada um receber dois anos.
Os dois prisioneiros sabem que, se nenhum dos dois confessar, cada um pegar
1 ano de cadeia. A partir de agora, nos referiremos a confessar como cooperar (com a
polcia) e no confessar como abster-se (da oferta). Suponha que voc um dos agentes
e responda: se voc fosse um dos prisioneiros, o que faria?
Esse cenrio conhecido como o dilema do prisioneiro. Existem quatro resultados
possveis para esse cenrio, dependendo de que estratgias cada agente escolhe. Tais
resultados so resumidos nas funes
u
i
((A, A)) = 3 u
i
((A, C)) = 0 u
i
((C, A)) = 5 u
i
((C, C)) = 2
u
j
((A, A)) = 3 u
j
((A, C)) = 5 u
j
((C, A)) = 0 u
j
((C, C)) = 2.
As funes de utilidade dos agentes, portanto, so:
155
u
i
((C, A)) > u
i
((A, A)) > u
i
((C, C)) > u
i
((A, C)),
u
j
((A, C)) > u
j
((A, A)) > u
j
((C, C)) > u
j
((C, A)).
Ilustramos as funes de utilidade dos agentes na seguinte matriz de payoffs:
Figura 7.7. Matrix de payoffs para o dilema dos prisioneiros
Observe que os nmeros na matrix no dizem respeito ao nmero de anos que
cada agente poderia pegar de cadeia, mas utilidade vista em cada resultado por cada
agente. Nesse sentido, menos anos de cadeia sugerem uma utilidade maior.
Faamos uma anlise para denir o que o agente i deve fazer, colocando-nos em
seu lugar:
Suponha que eu (agente i) me abstenha da oferta. Nesse caso, se o j tambm se
abstiver, ns dois teremos um payoff 3 (pena de 1 ano). Se, por outro lado, o j
cooperar, ento eu terei um payoff 0 (pena de 5 anos). Portanto, o melhor payoff
que eu posso garantir se eu me abstiver, 0.
Suponha, ento, que eu coopere com a polcia. Nesse caso, se j se abstiver, eu
co com um payoff 5, mas se ele cooperar tambm, eu co com payoff 2. Assim
sendo, o melhor payoff que eu garanto se cooperar, 2.
Se eu me abstiver da oferta, garanto um payoff mnimo de 0, mas se eu cooperar
com a polcia, garanto o payoff mnimo de 2. Consequentemnte, se desejo ma-
ximizar a minha utilidade, devo garantir o payoff mnimo de 2. Ento eu devo
cooperar com a polcia!
O dilema dos prisioneiros um exemplo clssico em teoria dos jogos e multiagen-
tes, pois seu resultado inesperado. Como o cenrio de j idntico ao de i, seu raciocnio
j deve ser similar. Consequentemente, se i e j agirem de forma racional, os dois coope-
raro com a polcia e o resultado ser de utilidade 2 para ambos. Observe que o melhor
cenrio possvel para os agentes aquele em que os dois decidem por se abster, o que
lhes daria um payoff de 3, mas ambos evitam esse cenrio porque h um risco de que o
resultado lhes d uma utilidade menor.
7.4. Comunicao
Alm da interao, a comunicao entre agentes outro ponto essencial a ser estudado em
sistemas multiagentes. Nesse sentido, devemos destacar que a maioria dos trabalhos sobre
comunicao de agentes est alicerado na noo de atos de fala, cuja origem remonta-nos
ao livro How to Do Things with Words de Johm Austin [Austin 1962]. Para ele, enunciar
algo pode ser entendido como uma ao fsica. Nessa linha de estudos, em [Searle 1969]
John Searle identicou vrios tipos diferentes de atos de fala:
156
Representativas : tem carter informativo: "est chovendo".
Diretivas : tenta fazer com que o ouvinte faa algo: "por favor, pegue o ch".
Compromissivas : compromete o falante a fazer algo: "eu prometo que...".
Expressivas : meio pelo qual o falante expressa um estado mental: "muito obrigado".
Declaraes : tais como declarar uma guerra ou nomear algum.
De um modo geral, os atos de fala possuem dois componentes: um verbo perfor-
mativo(pedir, informar,...) e um contedo proposicional ("a porta est fechada"). Observe
que o verbo performativo est relacionado inteno do ato de fala. Assim, vrios atos
de fala diferentes podem ter o mesmo contedo proposicional. Veja os seguintes exem-
plos com o mesmo contedo proposicional ("a porta est fechada") gerando trs tipos
diferentes de atos de fala medida que mudamos o verbo performativo:
performativo = pedir; ato de fala: por favor, feche a porta.
performativo = informar; ato de fala: a porta est fechada.
performativo = perguntar; ato de fala: a porta est fechada?
A Foundation for Intelligent Physical Agents (FIPA) comeou a trabalhar sobre a
denio de padres de programas de agentes. Na linguagem desenvolvida por eles, os
atos de fala so caracterizados em termos dos performativos (a FIPA prope 20 tipos di-
ferentes), personagens envolvidos (remetente, destinatrio, etc) e contedo proposicional
da mensagem. Na Figura 7.8, temos um exemplo de ato de fala representado em FIPA no
qual o agent1 informa o agent5 que o preo oferecido a good200 150.
Figura 7.8. Exemplo de Ato de Fala em FIPA
Em FIPA, "Inform" e "Request" so dois performativos bsicos, em termos dos
quais todos os demais so denidos. O signicado de "Inform" e "Request" denido em
duas partes: pr-condio (o que deve ser verdadeiro para o ato de fala ser bemsucedido) e
efeito racional (o que o remetente da mensagem espera ocorrer). No caso do performativo
"Inform", o contedo uma declarao e a sua pr-condio determina que o remetente
acredita que o contedo verdadeiro, pretende que o destinatrio acredite na veracidade
do contedo e no acredita que o destinatrio saiba se o contedo seja verdadeiro ou no.
7.5. Alocao de Recursos
Em sociedades de agentes com interesses prprios (self-interested), recursos escassos se-
ro disputados e estaro, com frequncia, indisponveis. Exemplos de recursos escassos
incluem o direito ao uso de um objeto ou recursos computacionais. Tais recursos podem
ser necessrios realizao de uma atividade por um agente e, portanto, essencial para
que este alcance um objetivo. Nesse sentido, a alocao de recursos um problema cen-
tral em Sistemas Multiagentes e as disputas geradas por escassez devem ser tratadas de
maneira eciente.
157
Formalmente, dados um conjunto com k recursos R = {o
1
, . . . , o
k
} e um conjunto
com n agentes Agentes = {Ag
1
, . . . , Ag
n
}, um problema de alocao de recursos envolve
encontrar uma partio de R com tamanho n, ou seja, conjuntos R
1
, . . . , R
n
tais que
R
1
R
n
= R, mas R
i
R
j
= para quaisquer R
i
, R
j
{R
1
, . . . , R
n
}. Nesse caso,
cada R
i
o conjunto de recursos alocados para o agente Ag
i
, 1 i n.
Os mecanismos utilizados para alocao de recursos dependem essencialmente do
nmero de agentes e recursos envolvidos no problema. No caso em que h uma plurali-
dade de agentes, uma forma bastante eciente de lidar com a distribuio dos recursos
pela utilizao de leiles.
7.5.1. Leiles
Os leiles eram, at pouco tempo, no muito utilizados. A razo era o alto custo para
viabilizar um leilo, dada a necessidade de encontrar um local para o evento, transportar
as mercadorias, contratar um leiloeiro, e mais. A internet mudou isso, reduzindo drasti-
camente os custos e permitindo realizar e concorrer em leiles a partir de qualquer lugar
do mundo.
Essencialmente, um leilo ocorre entre um agente (o leiloeiro) que controla um
recurso (uma mercadoria) e outros agentes (os licitantes) interessados neste. O objetivo
de um leilo decidir qual dos licitantes ca com a mercadoria. Para tal, os licitantes
faro ofertas com outros recursos (a exemplo de dinheiro) com o intuito de minimizar o
seu custo, enquanto que o leiloeiro deseja maximar seu ganho. Nesse sentido, se uma
troca uma atribuio de valores a pagar por uma mercadoria, devemos considerar que:
Cada agente envolvido atribui um preo limite mercadoria.
Um comprador que troca mais do que o seu valor limite pela mercadoria, tem uma
perda.
Um vendedor que troca sua mercadoria por menos do que o seu valor limite, tem
uma perda.
Uma instituio de mercado dene como trocas devem ser feitas. Dessa maneira,
uma instituio dene que tipo de mensagens podem ser trocadas e, com base nas men-
sagens trocadas, quem o vencedor. O mais comum que as mensagens sejam restritas
a lances ou pedidos e que a regra que determina o vencedor diculte a elaborao de
estratgias para vencer o leilo.
Um leilo uma instituio de mercado em que mensagens entre interessados em
trocas (comerciantes) envolvem alguma informao de valor - uma oferta para comprar a
mercadoria (um lance) ou para vend-la (um pedido) por um certo valor - e que prioriza
lances de valor maior ou pedidos de valor menor.
7.5.1.1. Leilo Ingls
O leilo ingls o tipo mais conhecido, consistindo em uma sucesso de propostas pbli-
cas, com valor crescente e cujo vencedor aquele que profere a ltima (maior) proposta:
O leiloeiro prope um preo de reserva (que pode ser 0). Se nenhum agente der
um lance maior, a mercadoria ca com o leiloeiro por esse valor.
158
Agentes so convidados a dar lances cada vez mais altos, vontade. Quando
nenhum agente est disposto a aumentar o lance, o leilo encerrado e o vencedor
paga o valor que props.
A estratgia dominante em leiles desse tipo envolve o agente elevar o valor das
propostas aos poucos at atingir o seu valor de reserva e, ento, desistir.
7.5.1.2. Leilo Holands
Este modelo de leilo consiste de propostas pblicas, mas decrescentes. Dessa maneira,
ligeiramente diferente do leilo ingls, mas tal diferena o bastante para que, em geral,
no haja estratgia dominante.
O leiloeiro prope um valor inicial articialmente alto e segue com ofertas pouco
menores a cada momento.
Quando um agente aceita a ltima oferta feita, paga este valor e ca com a merca-
doria. Em caso de empate, o leilo reiniciado com um valor um pouco maior do
que o atual.
7.5.2. Negociao
Em alguns casos, o mecanismo de leiles insuciente e outras tcnicas mais elaboradas
precisam ser utilizadas. Um dos motivos possveis para tal que os leiles dependem
da existncia de algum tipo de moeda de troca que permita comparaes de valor. Em
um contexto mais geral, tal moeda pode no existir, mas os agentes poderiam que trocar
recursos diversos ou at favores. Nos referimos a essas tcnicas, em geral, pelo nome de
negociao. Em uma negociao, os agentes buscam um acordo em situaes que sejam
de interesse mtuo.
Em um contexto de negociao teremos ao menos quatro elementos:
Um conjunto de negociao, com todas as propostas que os agentes podem fazer.
Um protocolo, o qual dene quais propostas so legais em cada momento da ne-
gociao, com base em seu histrico.
Um coleo de estratgias de negociao, uma para cada agente, que determina
quais propostas um agente pretende fazer. Essa estratgia costuma ser privada
para cada agente, embora as propostas, quando feitas, costumem ser pblicas.
Uma regra que determina o m da negociao e qual seria o acordo alcanado.
Vrios fatores podem fazer com que o processo seja bastante complicado, a exem-
plo do nmero de itens negociados e do nmero de envolvidos na negociao. Devido s
diculdades introduzidas por esses fatores, a maior parte dos trabalhos nesse tema envolve
negociaes dos tipos mais simples, envolvendo apenas dois agentes, um nico item ne-
gocivel e em que h simetria, no sentido de que um resultado mais favorvel a um dos
agentes menos favorvel ao outro, em igual proporo, e vice-versa. Normalmente,
assume-se que os agentes buscam maximizar sua utilidade durante a negociao e que o
pior resultado possvel a ausncia de um acordo.
Uma negociao costuma ser realizada em uma sequncia de rodadas que en-
volvem, cada, uma proposta. A seguir, considere o seguinte modelo para negociao
um-a-um com ofertas alternadas:
159
Os agentes Ag
1
e Ag
2
negociam em uma sequncia de rodadas 0, 1, 2, . . .
Nas rodadas pares (r = 0, 2, 4, . . . ):
Ag
1
faz uma proposta p
r
;
Ag
2
aceita ou rejeita p
r
; Se aceita, a negociao nalizada. Caso contrrio,
a negociao avana para a rodada r + 1.
Nas rodadas mpares (r = 1, 3, 5, . . . ):
Ag
2
faz uma proposta p
r
;
Ag
1
aceita ou rejeita p
r
; Se aceita, a negociao nalizada. Caso contrrio,
a negociao avana para a rodada r + 1.
A negociao tambm pode ser encerrada caso nenhum dos agentes possa fazer
nova proposta aps a rejeio da ltima. Nesse caso, no h acordo. To logo a negoci-
ao seja nalizada, o acordo a que os agentes chegaram (se chegaram) implementado.
A Figura 7.9 ilustra uma negociao desse tipo:
Figura 7.9. O ciclo de negociao entre dois agentes.
7.6. Cooperao
Considerando que agentes so autnomos, eles tm que tomar decises em tempo de exe-
cuo e devem ser capazes de se coordenarem dinamicamente. No entanto, se os agentes
foram projetados por indivduos diferentes, eles podem no compartilhar as mesmas me-
tas. Assim por que e como os agentes iro trabalhar juntos? Para responder essa pergunta
precisamos distinguir dois tipos de agentes: agentes benevolentes e os com interesses
prprios.
Se o sistema multiagente foi projetado por uma nica pessoa ou organizao,
possvel conceber os agentes de um modo tal que eles possam ajudar uns aos outros toda
vez que for preciso. Nesse caso, ns assumimos que os agentes so benevolentes: nosso
melhor interesse o melhor interesse deles. Nesse caso, a soluo de problemas e coope-
rativa e distribuda, sendo que a presena de agentes benevolentes simplica enormemente
a projeo do sistema.
160
Por outro lado, se os agentes representam os interesses de indivduos ou organi-
zaes distintas, ento ns no poderemos assumir que os agentes sero benevolentes.
Nesse cenrio, os gentes sero assumidos como defendendo seus prprios interesses, pos-
sivelmente s custas de outros. No difcil constatar que a possibilidade de conitos
grande, tornando a projeo de tarefas bem mais complicadas. Alm disso, pode ser
necessrio elaborar estratgias de atuao para que os agentes possam atingir os seus
objetivos, como ocorre, por exemplo, na Teoria de Jogos.
7.6.1. Resoluo de Problemas em Conjunto
Ao se tentar resolver um problema cooperativamente em um sistema multiagentes, uma
pergunta fundamental "como um grupo de agentes trabalha junto para resolver proble-
mas?". Esse trabalho cooperativo pode ser dividido em trs estgios: decomposio do
problema, soluo do subproblema e sntese da resposta. A seguinte gura, adaptada de
[Wooldridge 2009], ilustra as fases para a soluo de problemas de forma cooperativa e
distribuda:
Figura 7.10. Os trs estgios para a soluo de problemas em cooperao.
Na decomposio do problema, o problema principal subdividido em subpro-
blemas. Esse processo normalmente hierrquico/recursivo. Os subproblemas so, por
sua vez, divididos em subproblemas ainda menores, sendo que esse processo continua at
se chegar a um nvel atmico razovel. Claramente h como se processar essa diviso.
A questo a ser decidida durante a projeo do sistema como isso ser feito? Outra
questo importante quem ir fazer a diviso. Ser centralizado? Que agentes tero co-
nhecimento da estrutura das tarefas? Que agentes iro resolver cada subproblema? Como
se pode perceber, essa fase de decomposio do problema passa pela resposta de muitas
perguntas.
No prximo estgio, os agentes procuraro solucionar cada um dos subproblemas
gerados. Para tal, eles vo geralmente compartilhar informao durante esse processo.
Almdisso, eles tero que sincronizar suas aes quando precisaremdos mesmos recursos
ao mesmo tempo.
Por m, no estgio de sntese da soluo, as solues dos subproblemas so in-
tegradas. Mais uma vez esse processo pode ser hierrquico, permitindo a obteno de
161
solues diferentes em diferentes nveis de abstrao. Uma questo recorrente nesta fase
que agente ir fazer essa sntese.
Neste modelo de soluo de problemas cooperativamente, muito provavelmente,
ns encontraremos as seguintes atividades:
Compartilhamento de tarefas: os componentes de uma tarefa so distribudos entre
os agentes; uma questo a responder como ns decidimos como alocar tarefas a
agentes?
Compartilhamento de resultados: informaes relevantes soluo de subproble-
mas (a exemplo de resultados parciais) so compartilhadas entre os agentes do
time por demanda ou pr-ativamente.
A Figura 7.11, adaptada de [Wooldridge 2009], ilustra os conceitos discutidos
acima:
Figura 7.11. (a) Compartilhamento de tarefas e (b) compartilhamento de resulta-
dos.
7.6.2. Distribuio de Tarefas com Contract Net
Distribuir tarefas de maneira eciente entre os agentes de um time pode ser difcil, uma
vez que cada membro do time pode ter capacidades muito diferentes. Nos casos em que
os agentes so realmente autnomos, concebvel que estes possam rejeitar tarefas que
lhes sejam atribudas e precisem buscar acordos sobre a alocao destas tarefas. Um
protocolo bem conhecido de compartilhamento de tarefas que leva isso em considerao
o Contract Net. Ele inclui cinco estgios e nos lembra um processo de licitao:
1. Reconhecimento do Problema
2. Anncio da Tarefa
3. Ofertas
4. Seleo do contrato
5. Expedio
Esse protocolo prima por ser autoexplicatrio e ilustrado na Figura 7.12.
Apesar de sua simplicidade, o Contract Net se tornou o framework mais imple-
mentado e melhor estudado para a soluo de problemas com distribuio de tarefas.
7.7. Coordenao
Talvez o problema principal no que tange o trabalho cooperativo em grupos de agentes
o da coordenao entre os envolvidos. Este problema concentra-se no gerenciamento de
162
Figura 7.12. Protocolo Contract Net
dependncias entre as atividades dos agentes para que estas possam interagir de maneira
apropriada. As dependncias entre atividades vo desde os requisitos para seu incio ao
cumprimeiro de regras que garantem a consistncia do sistema.
Considere o seguinte exemplo, corriqueiro na vida real:
Duas pessoas esto em uma sala e, ao mesmo tempo, resolvem sair. H uma nica
porta na sala e sua largura s permite que uma pessoa passe por vez. Nesse caso, h um
recurso pblico (a porta) que ambos desejam usar, mas do qual apenas um pode usufruir
por vez. Como consequncia, as atividades das pessoas precisam ser coordenadas para
que no haja uma coliso e todos possam cumprir os seus objetivos.
Os agentes de uma sociedade tambm podem usar de coordenao para evitar a
repetio de esforos, nesse caso, agindo de forma coordenada e cooperativa. No exemplo
acima, se a porta deve permanecer fechada quando ningumestiver utilizando a passagem,
as aes necessrias a cada agente envolveriam abrir a porta, sair e fechar a porta. Se o
primeiro que passar pela porta perceber que h outra e, invs de executar todos os passos,
deixar a porta aberta, alguns esforos so evitados.
Existem diversas abordagens para coordenar dinamicamente as atividades de
agentes em um sistema. Entre estas abordagens, pode-se modelar os agentes desde o
comeo para que ajam coordenadamente, desenhar regras que induzam coordenao
de atividades ou promover a comunicao das intenes dos agentes sociedade. Neste
captulo, vamos nos concentrar em apenas uma dessas abordagens, a dizer, baseada em
normas e leis sociais.
163
7.7.1. Normas e Leis Sociais
Sociedades so frequentemente reguladas por regras (muitas vezes no-escritas) de com-
portamento. Por exemplo, um grupo de pessoas est esperando numa parada de nibus.
O nibus chega; quem entra no nibus primeiro? Num sistema multiagentes, ns teremos
que projetar as normas que o programa dos agentes deve seguir ou formalizar aspectos do
ambiente e dos agentes de maneira que essas normas possam emergir. Vamos agora dar
mais detalhes sobre esses dois tipos de normais sociais:
Antes de descrever como projetar as normas que o programa dos agentes deve
seguir, vlido destacar que ns descrevemos agentes como
Ag R
E
Ac,
ou seja, uma funo que dada uma execuo terminando num estado, retorna uma ao.
Uma restrio um par
E

, ,
em que E

E um conjunto de estados e Ac uma ao. Essa restrio arma

que no pode ser realizada em qualquer estado em E

. Uma lei social denida, ento,

como um conjunto dessas restries.
Ns ainda podemos renar nossa viso de um ambiente. Para tal, vamos chamar
de estados focais, F E, aqueles que ns queremos nosso agente seja capaz de estar.
De qualquer estado focal e F, deve ser possvel chegar a qualquer outro estado focal
(embora no necessariamente de maneira direta). Uma lei social til uma que no
previne agentes de chegar de um estado focal a outro.
No que tange s normas sociais, ns tambm podemos projetar sistemas
em que elas podem emergir. Um conhecido exemplo o jogo da camiseta
[Shoham and Tennenholtz. 1997]:
"Agentes tm ambos uma camiseta vermelha e uma azul e vestem uma delas. O
objetivo que cada cada agente termine com a mesma cor. Em cada rodada, cada agente
encontra-se com um outro agente e decide se muda de camiseta ou no. Durante a rodada,
eles veem somente a camiseta de que seu par estiver vestindo (eles no obtm nenhuma
outra informao)". Que funo de atualizao de estratgia eles deveriam usar? Na
sequncia, esto algumas funes de atualizao que poderiam ser aplicadas nesse caso:
Maioria simples: agentes pegam a camiseta que eles viram com mais frequncia.
Maioria simples com tipos: agentes esto divididos em dois tipos; quando eles
encontram um agente do mesmo tipo, eles compartilham suas memrias. Caso
contrrio, eles agem como no caso de maioria simples.
Recompensa cumulativa mais alta: para essa atualizao funcionar, agentes devem
ser capazes de perceber que adotando certa estratgia ir produzir um resultado
particular. A regra de atualizao baseada na recompensa cumulativa mais alta
estabelece que um agente use a estratgia que produza o resultado cumulativo
mais alto at o momento.
164
Referncias
Austin, J. L. (1962). How To Do Things With Words. Oxford University Press.
Ferguson, I. A. (1992). TouringMachines: An Architecture for Dynamic, Rational, Mobile
Agents. PhD thesis, Computer Laboratory, University of Cambridge, Cambridge, UK.
Genesereth, M. R. and Nilsson, N. (1987). Logical Foundations of Articial Intelligence.
Morgan Kaufmann.
Mller, J. P. and Pischel, M. (1993). The agent architecture inteRRaP : concept and appli-
cation. Technical report, Saarlndische Universitts- und Landesbibliothek; Sonstige
Einrichtungen. DFKI Deutsches Forschungszentrum fr Knstliche Intelligenz.
Searle, J. R. (1969). Speech Acts: an Essay in the Philosophy of Language. Cambridge
University Press.
Shoham, Y. and Tennenholtz., M. (1997). On the emergence of social conventions: mo-
deling, analysis and simulations. Articial Intelligence, 94(1):139166.
Steels, L. (1990). Cooperation between distributed agents through self organization. In
Demazeau, Y. and Mller, J.-P., editors, Decentralized AI - Proceedings of the 1st Euro-
pean Workshop on Modelling Autonomous Agents in a Multi-Agent World(MAAMAW-
89), pages 175196. Elsevier.
Wooldridge, M. (2009). An Introduction to MultiAgent Systems. Wiley Publishing, 2nd
edition.
Wooldridge, M. and Jennings, N. R. (1995). Intelligent agents: theory and practice. The
Knowledge Engineering Review, 10(2):115152.
165

Captulo
8
Desenvolvimento para dispositivos mveis que
utilizam plataforma iOS

Roniel Soares de Sousa, Jos Alm Soares Filho, Ricardo Teles Freitas,
Kelson Aires, Andr Soares, Vinicius Machado, Laurindo Britto Neto

Laboratrio de Inteligncia Computacional (LabInC) da Universidade
Federal do Piau (UFPI)


Abstract
This chapter describes the main principles for the applications development for iOS
devices iPhone, iPad and iPod Touch. The main tool required for such activity, the
Xcode, is presented. Moreover, this work will approach the Objective-C programming
language, Views manipulation, the use of the iOS Simulator tool used for testing the
applications and even the connectivity technologies functionality (Bluetooth and Wi-
Fi).

Resumo
Este captulo descreve princpios fundamentais para o desenvolvimento de aplicativos
para dispositivos que utilizam a plataforma iOS iPhone, iPad e iPod Touch.
Apresentar-se- a principal ferramenta necessria nesta atividade, o Xcode. Alm
disso, este trabalho abordar a linguagem de programao Objective-C, manipulao
de Views, o uso do iOS Simulator ferramenta utilizada para testar as aplicaes
e at mesmo o funcionamento de tecnologias de conectividade (Bluetooth e Wi-Fi).
8.1. Introduo
Esta seo apresenta o iOS SDK, kit de desenvolvimento de sistemas para iOS.
coberto desde a sua instalao at a definio dos principais componentes.
8.1.1. Obtendo o iOS SDK (Software Development Kit)
O iOS SDK um conjunto de aplicaes necessrias para desenvolver aplicativos para
dispositivos mveis (conhecidos popurlamente como apps), que rodam nativamente no
166

iOS. Ele fornece uma grande variedade de programas que do suporte ao desenvolvedor
nas etapas de produo do app.
Para obter acesso ao iOS SDK, necessrio inicialmente possuir uma conta na App
Store (loja virtual de aplicativos para iOS). Abaixo est o link para download:
- http://itunes.apple.com/us/app/xcode/id448457090?mt=12
Alm disso, voc precisa de um Mac baseado em Intel com o Mac OS Snow Leopard ou
superior instalado.
O iOS SDK dividido em diferentes componentes que auxiliam no desenvolvimento das
aplicaes. Tais componentes so: Xcode, DashCode, iOS Simulator, e Instruments.
Dentre eles, os mais utilizados aqui sero o Xcode e o iOS Simulator.
NOTA: Neste minicurso ser considerada a verso 4 do SDK, verso mais atual no
momento da confeco deste minicurso.
8.1.2. Componentes do SDK
O SDK do iOS inclui as seguintes ferramentas:
XCode - Ambiente de desenvolvimento integrado atravs do qual o programador
gerencia, edita e depura os projetos.
Dashcode - Ambiente de desenvolvimento integrado voltado para produzir
aplicaes web para iOS, assim como Dashboard Widgets.
iOS Simulator - Simulador do iOS.
Interface Builder - Editor grfico para projetar interfaces, que est integrado ao
XCode desde a verso 4. Nas verses anteriores o Interface Builder no
compunha o XCode mas vinha separado no SDK.
Instruments - Programa que visa analisar o desempenho dos apps.
O SDK do iOS tambm inclui outras aplicaes. Entretanto, este minicurso est focado
apenas no XCode, Interface Builder, e no iOS Simulator. Nas prximas sees tais
componentes sero detalhados.
8.1.2.1. XCode
O XCode o principal ambiente, onde se desenvolvem as aplicaes, tanto na sua parte
grfica, com auxlio de um construtor de interfaces grficas que auxilia de maneira
bastante intuitiva na criao da interface, quanto na sua parte funcional, feita atravs do
cdigo escrito em Objective-C.
Este ambiente de desenvolvimento integrado (IDE) permite que o programador comece
sua aplicao a partir de modelos pr definidos (templates):
!"#$%"&$'()*"+,- "//0$1"&$'(: Tema que viabiliza um ponto ue paitiua paia uma
aplicao com contiole ue navegao.
2/,(34 56 7//0$1"&$'(" Peimite utilizai uma visualizao na qual possivel
ienueiizai uma cena !"#$%& ().
6/0$& 8$,9)*"+,- 7//0$1"&$'(" Comea uma aplicao com uma visualizao uo
tipo uiviuiua e uuas visualizaes comuns.
167

:"* ;"< 7//0$1"&$'(" Comea uma aplicao com um contiolauoi ue baiia e um
contiolauoi ue visualizao uo piimeiio item ua baiia.
=&$0$&> 7//0$1"&$'(" Inicia uma aplicao com uma visualizao piincipal e uma
outia uo tipo "*+,"-,.#".
8$,9)*"+,- 7//0$1"&$'(" Piovem uma visualizao com um contiolauoi e um
aiquivo .nib.
?$(-'9)*"+,- 7//0$1"&$'(" /#0"+12# inicial paia qualquei tipo ue aplicao.
Alguns desses templates so exclusivos para determinados dispositivos, mesmo rodando
sobre a mesma plataforma. Por exemplo o template Split-View Based serve apenas para
iPad.
8.1.2.2. iOS Simulator
Outra ferramenta importante que o SDK fornece o simulador que imita o
funcionamento de um iPhone, iPad ou iPhone Retina utilizando o iOS.
importante notar que esta ferramenta um simulador, ou seja ela tenta imitar o
comportamento do iOS nos dispositivos baseando-se no MAC OS para compilar o
cdigo da aplicao. Isso significa que ela ir usar as bibliotecas presentes no MAC para
fazer a aplicao se comportar como se estivesse num verdadeiro iPhone, embora em
um dispositivo real a aplicao precise ser compilada para o byte-code usado nele. O
iPhone utiliza um cdigo baseado na arquitetura ARM para isso.
O simulador apresenta algumas caractersticas importantes do dispositivo real. Entre
elas esto os movimentos de toque: toque leve, duplo toque e pina, rotaes de tela e
simulaes de avisos de pouca memria. Porm outras caractersticas importantes como
fazer ligaes, utilizar a cmera ou o acelermetro no esto disponveis at a verso 4.3
do simulador.
8.1.2.3. Interface Builder (Integrado ao Xcode)
O Interface Builder favorece a construo de interfaces grficas para o usurio,
fornecendo elementos grficos baseados no drag-and-drop (arrastar e soltar) e formas
intuitivas de conectar tais elementos com o cdigo.
Os conceitos de Outlets e Actions so essenciais para se compreender como so ligados
os elementos grficos do Interface Builder com as funcionalidades do cdigo.
8.2. Objective-C
A Objective-C uma linguagem de programao orientada a objeto, desenvolvida pela
Apple, a fim de ser usada tanto no desenvolvimento para MAC OS X quanto para o iOS.
uma extenso da linguagem C padro, portanto quem j possui certa experincia com
a programao em C no ter problemas na adaptao ao Objective-C.
Para entender o cdigo de uma aplicao em tal linguagem preciso saber como so
divididos seus arquivos:
.h Arquivos de cabealho, onde se localizam as declaraes de objetos e
mtodos.
.m Arquivos de implementao, como sugere o prprio nome, contm a
implementao do que foi declarado nos arquivos de cabealho.
168

A seguir veremos algumas caractersticas da Linguagem Objective-C.
8.2.1. Diretivas
Para incluir bibliotecas na implementao de cdigo usa-se o pr-processador de
diretivas, no caso do Objective-C, o #import, que atua de forma igual ao #include no C
ou C++.
8.2.2. Classes
Como Objective-C uma linguagem orientada a objetos, existe a necessidade de um
certo conhecimento sobre classes.
Para declarar uma classe usa-se @inteface, como no exemplo a seguir:

@interface NomeDaClasse : NSObject {
}
@end

NSObject refere-se a classe da qual a classe declarada herda.
J na implementao de uma classe usa-se @implementation alm da declarao da
mesma. Veja o exemplo:

#import NomeDaClasse
@implementation NomeDaClasse
//implementao
@end

Entretanto, podem ocorrer casos de importao cclica, onde uma determinada classe,
que ser chamada de ClasseUm, tem como atributo uma instncia de uma certa
ClasseDois e vice-versa, tendo assim a necessidade de cada uma ser importada na
outra. Para evitar isso, faz-se necessrio o uso de @class como mostrado abaixo:

#import<Foundation/Foundation.h>
@class ClasseDois;
@interface ClasseUm : NSObject{
ClasseDois *classeDois;
}
@end
#import <Foundation/Foundation.h>
@class ClasseUm;
@interface ClasseDois : NSObject{
ClasseUm *classeUm;
169

}
@end

8.2.3. Instanciando classes
Para criar uma instncia de determinada classe em Objective-C, devemos usar a palavra
alloc, que permite reservar um espao na memria para o novo objeto. Alm disso,
usa-se o caractere * (asterisco) precedendo o nome da varivel que ir referenciar o
objeto criado, exceto nos casos em que a varivel de tipo primitivo. O trecho abaixo
exemplifica a criao de um objeto:
ClasseQualquer *classeQualquer = [ClasseQualquer alloc];

8.2.4. Mtodos
Como qualquer linguagem orientada a objetos, em Objective-C existem mtodos.
Mtodos so funes definidas dentro de uma classe e podem ser de dois tipos:
Mtodos de instncia: so usados apenas atravs da instncia de uma classe e em
Objective-C so precedidos pelo caractere -. Exemplo:

- (void) facaAlgo {
//Implementao
}
Caso existam parmetros:
- (void) facaAlgo:(NSString *) outroParametro: (NSInteger *){
//Implementao
}

Para fazer a chamada de mtodos de instncia:
[objeto metodo];
Caso existam parmetros:
[objeto metodo: parametro1 outroParametro: parametro2];

Mtodos de classe: So usados diretamente com o nome da classe, no se
fazendo necessria a existncia de uma instncia. Em Objective-C so
precedidos pelo caractere +. Exemplo:

+ (void) facaAlgo {
//Implementao
}
Caso existam parmetros:
+ (void) facaAlgo:(NSString *) outroParametro: (NSInteger *){
170

//Implementao
}
Para fazer a chamada de mtodos de classe:
[classe metodo];
Caso existam parmetros:
[classe metodo: parametro1 outroParametro: parametro2];

8.2.5. Privilgios de acesso
Os campos de uma classe no devem ser acessados de qualquer forma, pois a alterao
de um desses campos indevidamente pode causar erros. Para evitar que isso acontea
existem os privilgios de acesso. Por padro os campos em Objective-C so do tipo
@protected, mas existem ainda 2 outros tipos, veja a lista:
@protected - Campo visivel tanto na classe em que foi ueclaiaua quanto nas que
heiuam ua mesma.
@public Campo visvel em todas as classes.
@private Campo visvel apenas na classe em que foi declarado.
Exemplo de como mudar o privilgio de acesso de um campo:

#import<Foundation/Foundation.h>
@class OutraClasse;
@interface ClasseQualquer : NSObject{
OutraClasse *outraClasse;
@public float rate;
@public NSString *name;
}
@end

8.2.6. Propriedades
As propriedades permitem um maior controle sobre como os campos da classe so
definidos ou retornados, sendo mais til que os privilgios de acesso vistos
anteriormente. Elas criam automaticamente os chamados assessores (getters e setters).
Exemplo de como definir um campo como propriedade:

#import <Foundation/Foundation.h>
@class OutraClasse;
@interface ClasseQualquer : NSObject{
OutraClasse *outraClasse;
float rate;
NSString *name;
171

}
@property float rate;
@property (retain, nonatomic) NSString *name;
-(void)doSomething;
-(void) doSomething:(NSString*)str;
-(void)doSomething:(NSString*) strwithAnotherPara:(float)value;
+(void)alsoDoSomething;
@end

J na implementao usa-se o operador @synthesize como a seguir:

#importClasseQualquer.h
@implementation ClasseQualquer
@synthesize rate, name;

Veja que aps o operador @property do campo name foram colocadas as palavras
retain e nonatomic, elas so as responsveis pelas modificaes na definio e no
modo como o campo retornado.

8.2.7. Inicializadores
Quando uma instncia de uma classe criada existe a necessidade de inicializ-la. Em
Objective-C usada a palavra-chave init para a inicializao dessa instncia.
Entretanto, tambm h a possibilidade de criar inicializadores adicionais, definindo-se
mtodos iniciados com init.
Exemplo de inicializao:
[[ClasseQualquer alloc] init];
Exemplo de inicializadores adicionais:
#import<Foundation/Foundation.h>
@class OutraClasse;
@interface ClasseQualquer:NSObject{

OutraClasse *OutraClasse;
float rate;
NSString *name;
}
@property float rate;
@property (retain,nonatomic) NSString *name;

-(void)doSomething;
-(void)doSomething:(NSString*) str;
172

-(void)doSomething:(NSString*) strwithAnotherPara: (float)value;
+(void)alsoDoSomething;

- (id)initWithName:(NSString *) n;
- (id)initWithName:(NSString *) n andRate:(float) r;
@end

E a implementao feita da seguinte forma:
#importSomeClass.h
@implementationSomeClass
@synthesizerate,name;

- (id)initWithName:(NSString *) n {
return [self initWithName:n andRate:0.0f];
}
- (id)initWithName:(NSString *) n andRate:(float) r {
if (self = [super init]) {
self.name = n;
self.rate = r;
}
return self;
}

8.2.8 Protocolos
Protocolos funcionam de forma bem parecida s interfaces de programao, porm com
a diferena que o programador pode escolher o que a classe vai implementar ou no.
Assim existe a possibilidade de se adicionar um protocolo e usar apenas um mtodo
declarado por ele. Para melhor entendimento veja o trecho abaixo:

UIAlertView*alert=[[UIAlertViewalloc] initWithTitle:@Hello
message:@This is an alert view
delegate:self
cancelButtonTitle:@OK
otherButtonTitles:@Option 1, @Option 2, nil];
[alertshow];
O cdigo anterior ilustra um alerta na tela, isso ser explicado mais detalhadamente na
seo 9.4. O trecho em negrito usado quando se quer adicionar botes ao alerta, e para
saber qual boto foi clicado necessrio manipular mtodos declarados no protocolo
UIAlertViewDelegate.
Os protocolos devem ser adicionados no arquivo .h da classe em que se quer
implementar, como no explicitado no exemplo a seguir:
173

@interface ObjCTestViewController:UIViewController <UIAlertViewDelegate> {
//Declarao de atributos
}
@end
Agora basta fazer a implementao do mtodo desejado no arquivo .m.

8.3. Anatomia de um aplicativo para iOS e Hello World
Para exemplificar a criao de um projeto, vamos desenvolver um aplicativo Hello
World. Para isto, siga as seguintes etapas:
1. Abra o Xcode e voc ver a tela de boas vindas como mostra a Figura 8.1. Acesse
File ! New ! New Project para criar um novo projeto.
2. Voc poder observar na nova janela os vrios tipos de projetos que podem ser
criados, conforme explicado anteriormente. Escolha View-based Application e
clique em Next.
3. Na prxima janela, nomeie o projeto para HelloWorld e em Device Family escolha
iPhone. Clique em Next e escolha o local onde deseja salvar o projeto. No lado
esquerdo da nova janela voc poder observar os vrios arquivos gerados com o
projeto.
Assim como em qualquer aplicativo em C, em Objective-C o programa inicializado
por uma funo main, que no nosso projeto est localizada na pasta Supporting Files,
dentro do arquivo main.m. Porm, necessrio edit-lo. Foram criadas duas classes com
o nosso projeto. A primeira, HelloWorldAppDelegate, receber e manipular
importantes mensagens durante o tempo de execuo do aplicativo. J a
HelloWorldViewController a primeira visualizao, que foi criada automaticamente
porque escolhemos View-Based Application na hora da criao do projeto.
Observe o mtodo (BOOL)application: (UIApplication*)
applicationdidFinishLaunchingWithOptions: (NSDictionary*) launchOptions presente
no arquivo HelloWorldAppDelegate.m. Ele ser invocado assim que o aplicativo for
inicializado completamente. Observe que ele o responsvel pela exibio da primeira
visualizao, que uma instncia da classe HelloWorldViewController.
4. No lado esquerdo, realize um clique simples no arquivo
HelloWorldViewController.xib para exibir o Interface Builder.
174

5. No canto superior direito, existem botes para exibir novas reas na janela. Clique no
boto de utilitrios, como destacado na Figura 8.1, para exibir a rea de Utilitrios.

Figure 8.1. Interface Builder.
6. No canto inferior direito, observa-se a biblioteca de objetos. Clique e arraste um
Label para o Interface Builder. Aumente o tamanho do label. Depois, com o label
selecionado, clique no cone Attributes Inspector para editar o mesmo. Na tag
name, digite Hello World. Sua janela dever ficar como na Figura 8.2.

Figura 8.2. Colocando um label na aplicao.
175

7. Por fim, clique no boto Run, localizado no canto superior esquerdo. O iOS
Simulator dever abrir automaticamente e exibir o aplicativo com o Hello World,
conforme ilustra a Figura 8.3.

Figura 8.3. iOS Simulator com Hello World.
8.4. Actions e Outlets
Outlets e Actions so dois dos principais conceitos que voc tem que entender para
programar para iOS.
Quando o objetivo utilizar atributos de uma determinada classe como referncia para
algum objeto criado pelo Interface Builder, necessrio declar-los como Outlet.
Para isto, basta declarar o atributo no arquivo .h como segue abaixo:
IBOutlet <Class> *<var>;
em que <Class> representa o nome da classe a que pertence o atributo, e <var> o
nome da varivel. Ex: IBOutlet NSString *nome;
Caso o atributo no fosse declarado com a tag IBOutlet, ele no poderia ser visualizado
pelo Interface Builder.
Para ligar o Outlet a algum objeto do Interface Builder, siga os passos abaixo:
1. Com o projeto anterior aberto, v no arquivo HelloWorldViewController.h e adicione
o cdigo destacado abaixo:

@interface HelloWorldViewController : UIViewController {
176

IBOutlet UIButton *button;
}

2. Clique no arquivo HelloWorldViewController.xib, insira um Round Rect Button logo
abaixo do Label Hello World e renomeio para Enviar, da mesma maneira que foi
inserido o label.
3. Clique com o boto direito no cone File Owner, arraste para o boto criado e solte.
Ser exibida uma janela com os Outlets disponveis para seleo, escolha button.


Figura 8.4. Outlets.

Pronto, agora voc j pode manipular o boto criado no Interface Builder atravs do
atributo button criado no .h. Vamos exemplificar isto alterando o nome do boto.
Para isto, implementaremos o mtodo viewDidLoad no arquivo
HelloWorldViewController.m. Voc pode observar que este mtodo j existe, porm
est em forma de comentrio. Descomente-o e adicione o cdigo destacado abaixo:
-(void)viewDidLoad
{
[button setTitle:@Novo forState:UIControlStateNormal];
[super viewDidLoad];
}
Pressione Run para testar, se tudo tiver ocorrido como o esperado, o iOS Simulator
dever exibir o boto com o nome Novo.
177

J quando deseja-se que algum mtodo seja invocado por algum objeto do Interface
Builder, necessrio declar-lo no arquivo .h como segue abaixo:
- (IBAction) <metodo> ;
em que <metodo> receber o nome do mtodo. A utilizao de parmetros segue
normalmente. Ex: -(IBAction) imprimeNome:(NSString*) nome;
Para exemplificar a utilizao de Actions, siga o exemplo abaixo:
1. Com o projeto anterior aberto, v no arquivo HelloWorldViewController.h e adicione
o cdigo destacado abaixo:

@interface HelloWorldViewController : UIViewController {
IBOutlet UIButton *button;
}
-(IBAction) buttonPressed;

2. Vamos agora implementar o mtodo criado. Para isto , abra o arquivo
HelloWorldViewController.m e adicione o cdigo destacado abaixo.

@implementation HelloWorldViewController
-(void) buttonPressed
{
UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Funcionou"
message:@"Voce pressionou o boto.
delegate:self cancelButtonTitle:@"Ok"
otherButtonTitles:nil];
[alert show];
[alert release];
}

O que fizemos foi criar um alerta e exib-lo toda vez que o mtodo for chamado.
3. Abra o arquivo HelloWorldViewController.xib. Clique com o boto direito no boto
Enviar e arraste para File Owner (sentido contrrio ao feito com o Outlet). Ser
exibida uma janela com os eventos disponveis, escolha buttonPressed. Com isso,
toda vez que o boto for pressionado, ele chamar o mtodo buttonPressed.
4. Salve o projeto, clique em Run e pressione o boto Novo. Se tudo tiver ocorrido
como o esperado, ser exibido um alerta como mostra a Figura 8.5. Clique em Ok
para fechar o alerta.

178


Figura 8.5. IBAction, Alerta.
8.5. Adicionando views
8.5.1. Window-Based Application
At ento o nico template do XCode explorado foi o View-based application que j
traz um controlador de visualizaes e uma visualizao ligada janela principal da
aplicao. Para o projeto alcanar essa etapa, primeiramente, ele foi desenvolvido a
partir de um template bsico chamado Window-based application. Este template
oferece somente o alicerce para qualquer aplicao que rode em iPhone, e todo o
restante deve ser criado pelo programador. A vantagem de se usar um template assim
que qualquer tipo de aplicao com qualquer tema inicial pode surgir de uma aplicao
Window-based, em contrapartida, por ser um template muito bsico, o desenvolvedor
precisa construir toda a aplicao quase do zero.
O programador deve escolher, de acordo com suas necessidades, o template adequado
para sua aplicao. Se nenhum template for correto para o tipo de aplicao que o
desenvolvedor almeja, ento ele pode comear a aplicao a partir do template
Window-based application e fazer todo o app da maneira que desejar.
Agora iremos mostrar como o template View-based application criado a partir do
Window-based application. Para isso ser criada uma visualizao e um controlador
de visualizaes ao projeto.

1. Crie um projeto no XCode para uma aplicao iOS com o template Window-
based application, coloque o nome Window e selecione a opo destinado a
iPhone.
2. Clique no arquivo WindowAppDelegate.xib, isso ir mostrar a janela principal do
app. Note que, ao rodar o aplicativo neste ponto, ser possvel ver apenas uma tela
179

branca sem nenhuma visualizao dentro, diferente de um template View-based
que traz uma tela cinza. Isto ocorre porque no h um controlador de visualizaes
nem mesmo uma visualizao vinculada ao aplicativo.
3. Agora v no menu View/Utilities/ e clique em Show Object Library, uma coluna no
lado direito da tela surgir com os objetos na parte de baixo.
4. Arraste o objeto View Controller para qualquer local do editor fora da janela
principal do app, isto ir exibir outra janela ao lado da principal. Neste passo voc
est inserindo um controlador de visualizaes como objeto na instncia que
representa a janela principal do projeto.
5. Clique com o boto direito do mouse na pasta que tem o nome do projeto no
navegador de projeto, coluna mais esquerda do XCode. Na janela selecione a opo
New File e ento escolha o template do tipo iOS Cocoa Touch chamado
UIVIewController subclass. Marque a opo With XIB for user interface, clique
em Next, nomeie a classe para primeiraView e selecione o local para salv-la.
Agora voc tem um programa mais modularizado com uma visualizao separada
para usar no projeto. Essa visualizao ainda no est associada janela principal do
app, no entanto voc j pode trabalhar nela.
6. Selecione o arquivo primeiraView.xib que foi gerado do passo anterior e insira um
objeto UIButton chamado Round Rect Button que pode ser encontrado na
biblioteca de objetos (coluna da direita no canto inferior). Realize um duplo clique
nele e nomei-o para Visualizao conectada. Ao rodar o aplicativo neste ponto
voc perceber que, mesmo tendo alterado a visualizao do arquivo que acabou de
inserir, ainda no ser possvel acess-la no app, pois ela ainda no est vinculada
janela principal.
7. Selecione o outro arquivo, MainWindow.xib, e clique no objeto View Controller.
Acesse o menu View/Utilities/ e clique em Show Identity Inspector, ele ir aparecer
no canto direito do construtor grfico. Em Custom Class selecione a classe que
voc criou no passo 5. Agora v no inspetor de atributos, clicando em Show
Attributes Inspector em View/Utilities/, no campo NIB Name escreva o nome da
classe que voc criou no passo 5. Aperte Command + S.
8. Clique no arquivo WindowAppDelegate.h e adicione o seguinte trecho de cdigo que
est em negrito:

#import <UIKit/UIKit.h>
@class primeiraView;
@interface mesaAppDelegate : NSObject <UIApplicationDelegate>
@property (nonatomic, retain) IBOutlet UIWindow *window;
@property (nonatomic, retain) IBOutlet primeiraView *teste;
@end

Ao fazer isso voc est declarando um atributo para o objeto
WindowAppDelegate da aplicao e ele ser visvel no construtor de interface.

180

9. Agora clique no arquivo WindowAppDelegate.m e adicione o trecho de cdigo que
est em negrito:
#import "mesaAppDelegate.h"
#import "primeiraView.h"

@implementation mesaAppDelegate
@synthesize window = _window,teste;
- (BOOL)application:(UIApplication*)application
didFinishLaunchingWithOptions:(NSDictionary*)launchOptions
{
// Override point for customization after application launch.
[_window addSubview:teste.view];
[self.window makeKeyAndVisible];
return YES;
}
- (void)dealloc // ltimas linhas
{
[teste release];
[_window release];
[super dealloc];
}

10. V ao MainWindow.xib, clique com o boto direito do mouse no cone do objeto
Window App Delegate e arraste para o cone primeiraView. Ir aparecer uma
pequena janela com o nome do atributo do tipo primeiraView criado na interface
WindowAppDelegate.h, clique nele e salve. Esse movimento representa a conexo
entre o atributo criado para o objeto WindowAppDelegate e a classe que voc
inseriu.
11. Pressione Command + R para rodar a aplicao. Ela dever exibir a tela da classe
inserida no passo 5. Este projeto que comeou com o template Window-based
Application agora uma aplicao idntica a uma que comea como o template
View-based application.


8.5.2. Adicionando Views dinamicamente
Outra maneira de se adicionar uma visualizao atravs do cdigo. Dessa maneira
pode-se colocar uma visualizao com o aplicativo em execuo, caracterstica que
dever ser bastante explorada pelo desenvolvedor para aliviar a quantidade de
elementos da primeira visualizao, deixando o cdigo mais modularizado e legvel.
O objeto UIView que ser adicionado dinamicamente funciona como um container para
outras visualizaes como botes, textos, campos de texto e at mesmo para um outro
container. A primeira visualizao do projeto servir de base para suportar o objeto que
ser inserido dinamicamente, portanto, este objeto depender da base para existir.
181

Para adicionar uma visualizao dinamicamente, inicie um projeto do tipo View-based
application destinado a iPhone com o nome viewBased.

1. Clique no arquivo viewBasedViewController.xib, insira um objeto Round Rect
Button e nomeie-o para Mudar Visualizao, aperte Command + S. Esse boto
vai servir de gatilho para mudar da primeira para a segunda visualizao.
2. Adicione um novo arquivo do tipo UIViewController com o nome
novaVisualizacao. Clique no arquivo .xib gerado por ele, adicione um Label e
coloque o nome Nova Visualizao nele. Essa nova classe vai gerar o objeto que
ser usado na segunda visualizao.
3. Clique no arquivo viewBasedViewController.h, e acrescente o seguinte trecho de
cdigo em negrito e aperte Command + S:
#import <UIKit/UIKit.h>
@class novaVisualizacao;
@interface docsViewController : UIViewController
@property(nonatomic, retain) novaVisualizacao *nova;
-(IBAction)mudarVisualizacao;
@end

A nova visualizao ser declarada como um atributo da primeira com o nome nova.
4. Clique agora no arquivo da implementao viewBasedViewController.m, acrescente
o trecho de cdigo em negrito e aperte Command + S:
#import "docsViewController.h"
#import "novaVisualizacao.h"

@implementation docsViewController

@synthesize nova;

-(IBAction)mudarVisualizacao{
nova = [[novaVisualizacao alloc] init];
[self.view addSubview:nova.view];
}

-(void)dealloc{
[nova release];
[super dealloc];
}

O mtodo mudarVisualizacao, que ser acionado pelo boto Mudar Visualizao, ir
criar um objeto da classe que voc inseriu no passo 2 e associ-lo ao atributo nova. O
182

mtodo addSubview chamado pelo campo view ir colocar a segunda visualizao
em cima da primeira e a partir de agora o usurio ir interagir com ela.

5. Agora v ao viewBasedViewController.xib, clique com o boto direito do mouse no
elemento UIButton que voc inseriu no primeiro passo, arraste para o Files Owner
e selecione o mtodo que aparece na tela. Agora est feita a vinculao que far o
boto da interface chamar o mtodo.
6. Clique em Command + R para executar o projeto.

8.5.3. Animando a transio de visualizaes

A implementao anterior mostra uma transio brusca de uma visualizao
para outra, sem nenhum efeito visual para deixar a aplicao mais agradvel. Os apps,
no entanto, devem apresentar recursos estticos para tornar a aplicao mais aprazvel e
consequentemente atrair mais usurios. Um desses efeitos disponveis pelo framework
UIKit o de transio de visualizaes. Para mostrar como implementado o efeito
voc pode aproveitar o projeto anterior.

1. Clique em <NomeDoProjeto>ViewController.m e dentro do corpo do mtodo
mudarVisualizacao insira o seguinte trecho em negrito:

-
(IBAction)mudarVisualizacao
{
self.nova = [[novaVisualizacao alloc] init];

[UIView beginAnimations:@"Curl" context:nil];
[UIView setAnimationCurve:UIViewAnimationCurveEaseIn];
[UIView setAnimationDuration:.4];
[UIView setAnimationTransition:UIViewAnimationTransitionCurlUp
forView:self.view cache:YES];
[self.view addSubview:nova.view];
[UIView commitAnimations];
}

Essa srie de mtodos da classe UIView serve para customizar a animao de
transio e esta transio pode ser aplicada a qualquer objeto da classe UIView.

2. Aperte Command + R para rodar o projeto.
8.6. Suporte a multi-plataformas para iPhone e iPad
Por ter o mesmo sistema operacional que o iPhone e o iPod Touch, o iPad pode rodar
aplicativos desenvolvidos para ambos dispositivos. Porm, a visualizao do aplicativo
183

na tela do iPad ter a mesma dimenso usada pelo iPhone. Isso significa um grande
desperdcio, visto que a tela do iPad possui uma dimenso maior que a tela do iPhone.
Para resolver esse problema, a Apple recomenda que se crie aplicaes universais
alterando apenas a interface de usurio. Veja a seguir como isso feito (Figura 8.6):
1. Usando o Xcode, crie uma View-based application (para iPhone) e nomeie-o
como Universal.
2. Abra o UniversalViewController.xib adicione um Label e mude seu texto para
iPhone application.
3. Na tela inicial do projeto, em targets, selecione o aplicativo e em devices, selecione
Universal. Ento clique em YES.


Figura 8.6. Tornando o aplicativo multiplataforma.

4. Veja que foi criada uma pasta para recursos do iPad. Crie uma nova classe do tipo
UIViewController destinada a iPad e nomeie como iPadUniversal.
5. Edite o novo .xib criado.
6. Selecione MainWindow-iPad.xib para que seja editado no Interface Builder. Agora
selecione o item Universal View Controller e no inspetor de identidade coloque
Class como iPadUniversal.
7. Agora em inspetor de atributos defina NIB Name como iPadUniversal.
Dessa forma o aplicativos ter duas interfaces de usurio, sendo cada uma iniciada no
dispositivo para o qual foi desenvolvido.
184

8.7. Rotao de tela
Os dispositivos que utilizam iOS possuem a capacidade de detectar a orientao da
interface. Assim existe a possibilidade de adequar a interface do usurio nova
orientao, nesta seo descreve como feita a rotao.
Por padro o projeto no Xcode criado com suporte a nica orientao, para habilitar
mas mltiplas orientaes preciso sobrescrever o mtodo
shouldAutorotateToInterfaceOrientation. Esse mtodo chamado sempre que a
orientao muda e retorna YES caso esteja em orientao Portrait (retrato). Ento
basta mud-lo para que sempre retorne YES de modo que o mtodo fique como a
seguir:
- (BOOL)shouldAutorotateToInterfaceOrientation:
(UIInterfaceOrientation)interfaceOrientation {
return YES;
}
Agora, para colocar cada objeto em seu lugar na tela siga o passo-a-passo:
1. Crie um projeto View-Based Application no Xcode, nomeie-o ScreenRotations e
edite-o no Interface Builder adicionando um boto.
2. No arquivo ScreenRotationsViewController.h adicione o seguinte cdigo:

#import <UIKit/UIKit.h>
@interface ScreenRotationsViewController : UIViewController {
IBOutlet UIButton *btn;
}
@property (nonatomic, retain) UIButton *btn;
@end

1. No Interface Builder, conecte o Outlet que voc criou clicando com boto direito do
mouse e arrastando at o Rounded Rect Button. Selecione btn.
2. No arquivo ScreenRotationsViewController.m adicione o seguinte cdigo:

#import ScreenRotationsViewController.h
@implementation ScreenRotationsViewController
@synthesize btn;
-(void) positionViews {
UIInterfaceOrientation destOrientation = self.interfaceOrientation;
if (destOrientation == UIInterfaceOrientationPortrait ||
destOrientation == UIInterfaceOrientationPortraitUpsideDown) {
//---if rotating to portrait mode---
btn.frame = CGRectMake(20, 20, 233, 37);
} else {
185

btn.frame = CGRectMake(227, 243, 233, 37);
}
}
- (void)willAnimateSecondHalfOfRotationFromInterfaceOrientation:
(UIInterfaceOrientation) fromInterfaceOrientation
duration:(NSTimeInterval) duration {
[self positionViews];
}
- (void)viewDidLoad {
[self positionViews];
[super viewDidLoad];
}
- (void)dealloc {
[btn release];
[super dealloc];
}
8.8. Conectividade
Servios de conexo no iOS podem ser feitos de vrias maneiras. Podem ser usadas
redes wi-fi ou bluetooth para conectar dispositivos. No entanto, o iOS Simulator apenas
utiliza rede wi-fi para fazer as simulaes. Ao simular uma conexo Bluetooth o
simulador vai, efetivamente, utilizar a rede wi-fi.
Nesta sesso mostraremos como fazer uma conexo entre dois aparelhos via bluetooth.
Para isto, utilizaremos o Game Kit, que um framework que contm APIs que permitem
a comunicao atravs de uma rede bluetooth.
Instanciaremos a classe GKSession para representar uma sesso entre dois dispositivos
conectados. Tambm utilizaremos uma instncia da classe GKPeerPickerController,
que providncia uma interface grfica para procurar e conectar com outros dispositivos.
Para isto, siga os seguintes passos:
1. Crie um novo projeto utilizando o template View-Based Application, nomeie-o
Bluetooth. Adicione o GameKit.framework ao projeto. Para isto, acesse Targets
! Build Phases ! Link Binary With Libraries, clique no sinal + e selecione o
GameKit.framework.
2. Adicione 3 botes, 1 label e 1 Text Field ao BluetoothViewController.xib e
renomeie-os como mostra a Figura 8.7.
186


Figura 8.7. Interface.
3. Em BluetoothViewController.h, adicione o cdigo destacado abaixo:

#import <UIKit/UIKit.h>
#import <GameKit/GameKit.h>

@interface BluetoothViewController : UIViewController <GKSessionDelegate,
GKPeerPickerControllerDelegate> {

GKSession *currentSession;
GKPeerPickerController *picker;

IBOutlet UIButton* conectar;
IBOutlet UIButton* disconectar;
IBOutlet UIButton* enviar;
IBOutlet UITextField *texto;
}

@property (nonatomic, retain) GKSession *currentSession;
@property (nonatomic, retain) UITextField *texto;
@property (nonatomic, retain) UIButton *conectar;
@property (nonatomic, retain) UIButton *disconectar;


-(IBAction) btnSend:(id) sender;
-(IBAction) btnConectar:(id) sender;
-(IBAction) btnDisconectar:(id) sender;

@end
4. Conecte os botes e o Text Field aos seus respectivos atributos pelo Interface
Builder, como j foi feito com projetos anteriores. Faa o mesmo com os mtodos.
5. Em BluetoothViewController.m, adicione o cdigo destacado abaixo para
implementar os mtodos necessrios:

@synthesize conectar,desconectar,texto,currentSession;

-(IBAction) btnConectar:(id) sender {
picker = [[GKPeerPickerController alloc] init];
picker.delegate = self;
187

picker.connectionTypesMask = GKPeerPickerConnectionTypeNearby;
[conectar setHidden:YES];
[desconectar setHidden:NO];
[picker show];
}

-(IBAction) btnDesconectar:(id) sender {
[self.currentSession disconnectFromAllPeers];
[self.currentSession release];
currentSession = nil;
[conectar setHidden:NO];
[desconectar setHidden:YES];
}

-(void)peerPickerController:(GKPeerPickerController *)pk
didConnectPeer:(NSString *)peerID toSession:(GKSession *)session {
self.currentSession = session;
session.delegate = self;
[session setDataReceiveHandler:self withContext:nil];
picker.delegate = nil;
[picker dismiss];
[picker autorelease];
}

-(void)peerPickerControllerDidCancel:(GKPeerPickerController *)pk {
picker.delegate = nil;
[picker autorelease];
[conectar setHidden:NO];
[desconectar setHidden:YES];
}

-(void)session:(GKSession *)session peer:(NSString *)peerID
didChangeState:(GKPeerConnectionState)state {
switch (state) {
case GKPeerStateConnected:
NSLog(@"Conectado");
break;
case GKPeerStateDisconnected:
NSLog(@"Desconectado");
[self.currentSession release];
currentSession = nil;
[conectar setHidden:NO];
[desconectar setHidden:YES];
break;
}
}

-(void)session:(GKSession *)session didFailWithError:(NSError *)error {
NSLog(@"%@",[error description]);
}

- (void) mySendDataToPeers:(NSData *) data {
if (currentSession)
[self.currentSession sendDataToAllPeers:data
withDataMode:GKSendDataReliable
error:nil];
}

-(IBAction) btnSend:(id) sender {
NSData* data;
NSString *str = [NSString stringWithString:texto.text];
data = [str dataUsingEncoding: NSASCIIStringEncoding];
[self mySendDataToPeers:data];
}

188

- (void) receiveData:(NSData *)data fromPeer:(NSString *)peer
inSession:(GKSession *)session context:(void *)context {
NSString* str;
str = [[NSString alloc] initWithData:data

encoding:NSASCIIStringEncoding];
UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Informacao
recebida"
message:str delegate:self
cancelButtonTitle:@"OK"
otherButtonTitles:nil];
[alert show];
[alert release];
[str release];
}

- (void)dealloc
{
[texto release];
[currentSession release];
[conectar release];
[desconectar release];
[super dealloc];
}
- (void)viewDidLoad
{
[conectar setHidden:NO];
[desconectar setHidden:YES];
[super viewDidLoad];

}
6. Rode o projeto e pressione o boto Conectar. 0 mtouo 32$45$#6217 sei
chamauo quanuo o boto "45$#6217" foi piessionauo. Ele configuia e exibe o
8,69#745$275++#7.

Figura 8.8. PeerPickerController
189

Quando algum dispositivo for encontrado, o picker exibir uma lista com esses
dispositivos, para que o usurio possa escolher com qual deseja se conectar. Aps
selecionar dispositivo para conexo, ser exibida uma interface de espera, at que o
outro dispositivo aceite a conexo. Caso a conexo seja aceita, o mtodo session: peer:
didChangeState: ser chamado automaticamente. Ao enviar uma mensagem, o mtodo
btnSend transformar o texto em Data e enviar a informao atravs do mtodo
mySendDataToPeers. Ao receber uma mensagem, o mtodo receiveData: fromPeer:
inSession :context ser invocado, decodificar a informao em String e a exibir em
um alerta.

8.9. Consideraes finais
Este minicurso abordou princpios fundamentais e alguns conceitos mais tcnicos
relacionados a programao para a plataforma de dispositivos mveis iOS. Ele teve
como objetivo servir de ponto de partida para aqueles que desejam se aprofundar mais
na programao para o sistema operacional mvel da Apple. Para isto, recomenda-se a
leitura dos livros mencionados na bibliografia.

8.10. - Bibliografia

! ALI, Nahei. :.;1$6#. ,!) < "75=7100,$=> .#;#+5",$= 053,+# 1""+,612,5$- *57 :""+#
,8?5$#@ ,81. 1$. ,85. /5A6?B Wiley. E0A: 2u1u. 698 p.

! LEE, Wei-Neng. C#=,$$,$= ,!) < .#;#+5"0#$2 1""+,612,5$B D,+#EB (F:> GHIHB JKI "B

! i0S Bev Centei <http:uevelopei.apple.comuevcenteiiosinuex.action>.
Acessauo em 2Su92u11, s 14:S7.

190
Captulo
9
Desenvolvimento Rpido de Aplicaes Mveis
Utilizando a Linguagem Declarativa QML
Ricardo Erikson V. S. Rosa, Adriano M. Gil, Paulo R. B. Mendona, Ccero
F. F. Costa Filho e Vicente F. Lucena Jr.
Abstract
The emerging software development technologies have their focus on reducing the time-
to-market of new products. In the mobile applications context, reduce time-to-market is
critical to maximize ROI. QML (Qt Meta-object Language) is part of a declarative UI fra-
mework known as Qt Quick which aims to facilite the rapid development of applications.
This course aims to present the main components and features of the QML language and
Qt Quick UI framework addressed to the development of mobile applications.
Resumo
As novas tecnologias de desenvolvimento de software buscam meios de reduzir o tempo
excessivo gasto na criao de novos produtos. No contexto de aplicaes mveis, re-
duzir o tempo que um produto leva para chegar ao mercado crtico para maximizar
o retorno sobre investimento. QML uma linguagem declarativa que facilita o desen-
volvimento rpido de interfaces do usurio (UIs) e consequentemente reduz o tempo de
desenvolvimento. Este minicurso tem por objetivo apresentar os principais componentes
e caractersticas da linguagem QML e do framework Qt Quick com foco em aplicaes
mveis.
9.1. Introduo
Desenvolvedores de aplicaes mveis buscam meios de reduzir o tempo excessivo gasto
na criao e publicao de novos produtos. No mercado das app stores, as lojas online
de aplicativos, o desenvolvedor precisa considerar trs parmetros de tempo: (1) tempo
de desenvolvimento, (2) time to shelf (intervalo de tempo entre a submisso de uma apli-
cao e sua publicao para compra na loja) e (3) time to payment (perodo de tempo
entre a venda da aplicao e os rendimentos chegarem at o desenvolvedor). A reduo
191
do intervalo de tempo compreendido entre o incio do desenvolvimento e o retorno dos
rendimentos um fator crtico para maximizar o ROI.
Levando em considerao o tempo de desenvolvimento, a rapidez na codicao e
na prototipagem dos aplicativos apontada como uma das principais razes tcnicas para
que os desenvolvedores escolhamuma plataforma de desenvolvimento [10]. Os resultados
de codicao e prototipagem so muitas vezes apresentados na forma de interfaces do
usurio (UIs). No entanto, a diculdade de criao dessas UIs, onde os usurios tm que
aprender novas APIs inteiramente sem levar em conta as experincias de desenvolvimento
em outras plataformas, destacada como um dos problemas comumente enfrentado pelos
desenvolvedores em vrias plataformas [9, 10].
QML (Qt Meta-objects Language) uma linguagem declarativa utilizada no kit
de desenvolvimento Qt Quick (Qt User Interface Creation Kit) [8] que faz parte do fra-
mework Qt
1
. QML utilizada no desenvolvimento de aplicativos cross-platform e busca
facilitar o projeto e a implementao de UIs para dispositivos mveis atravs da rapidez
na codicao e na prototipagem. O estilo de programao da linguagem QML baseado
nas linguagens CSS (Cascading Style Sheets) e JavaScript, tornando-se de aprendizado r-
pido e fcil para programadores C, Qt/C++, Java e principalmente desenvolvedores web.
Diferentemente de outras linguagens de programao que utilizam a abordagem
imperativa para construir as UIs, QML utiliza o paradigma declarativo. A utilizao desse
paradigma permite que os desenvolvedores descrevam UIs declarando somente os objetos
que devem ser exibidos, ou seja, sem descrever o uxo de controle ou sequncia de aes
que devem ser executadas para criar a interface. Enquanto a UI criada de maneira decla-
rativa, a lgica da aplicao pode ser escrita de maneira imperativa atravs das linguagens
JavaScript e C++. Isso facilita a separao entre a UI e a lgica da aplicao, permitindo
que projetos Qt/C++ baseados no padro model-view-controller (MVC) sejam facilmente
portados para QML [1, 2].
Uma das principais caractersticas da linguagem QML a exibilidade na criao
das UIs. Essa exibilidade possvel graas possibilidade de adicionar e manipular
elementos como formas, imagens e texto. Outros elementos como estados, transies,
animaes, transformaes, efeitos grcos e elementos de interao permitem a criao
de aplicaes mais sosticadas em QML, principalmente quando utilizados em conjunto
com JavaScript e C++.
Este captulo tem o objetivo de apresentar a linguagem QML e sua utilizao no
desenvolvimento rpido de aplicaes mveis. Os principais caractersticas da lingua-
gem so apresentados na Seo 9.2. A utilizao dos elementos no tratamento de eventos
demonstrada na Seo 9.3. A Seo 9.4 mostra os principais elementos utilizados na
criao de animaes. Os mecanismos de criao de componentes customizados so des-
critos na Seo 9.5. As particularidades das principais plataformas de desenvolvimento
so mostradas na Seo 9.6 e, por m, as consideraes nais so feitas na Seo 9.7.
1
Qt um framework de desenvolvimento de aplicaes cross-platform que foi desenvolvido em C++ e
est disponvel para Windows, Linux e Mac OS X. O framework disponibiliza um amplo conjunto de APIs
que podem ser utilizadas no desenvolvimento para plataformas mveis embarcadas e desktop.
192
9.2. Linguagem Declarativa QML
Muitas plataformas mveis disponibilizam APIs, em linguagens de programao comu-
mente conhecidas (por exemplo Symbian C++, Qt/C++, Java, e Objective-C), para que
os desenvolvedores criem as UIs dos aplicativos. Porm, muitas vezes o custo de apren-
dizado de uma API inteira, considerando tambm as particularidades da sintaxe de cada
linguagem, bastante alto [9]. Almdisso, o paradigma imperativo, que frequentemente
empregado nas linguagens de programao modernas, faz com que o processo de criao
das UIs se torne rduo e demorado [12]. Baseando-se nesses fatos, o desenvolvimento
cross-platform utilizando plataformas que possibilitem baixo custo de aprendizado e r-
pida prototipagem parece ser uma alternativa desejvel no desenvolvimento de aplicativos
mveis.
A linguagem declarativa QML fornece um ambiente de programao bastante
simples e exvel, porm robusto. Ela dispe de um amplo conjunto de componentes,
para a criao das UIs, e de mecanismos de integrao (bindings) com as linguagens
JavaScript e Qt/C++. Os objetos da UI dos aplicativos QML so especicados por ele-
mentos que possuem tipo e propriedades (no estilo nome:valor, como em CSS), o que
torna a linguagem intuitiva e de fcil aprendizado tanto para designers de UI quanto para
programadores. Para ilustrar isso, as Listagens 9.1 e 9.2 apresentam uma comparao
entre as linguagens Qt/C++ e QML para a criao de um simples elemento visual.
O cdigo Qt/C++ necessrio para desenhar um retngulo apresentado na Lista-
gem 9.1. Esse cdigo exibe o retngulo na UI e dene propriedades como largura, altura
e cor.
1 void paint(QPainter
*
painter,
2 const QStyleOptionGraphicsItem
*
option,
3 QWidget
*
widget){
4 QRect rect(0, 0, 200, 100);
5 painter->setBrush(QBrush(Qt::green));
6 painter->drawRect(rect);
7 }
Listagem 9.1. Cdigo Qt/C++ necessrio para exibir um retngulo.
A Listagem9.2 exibe o cdigo QML necessrio para desenhar o mesmo retngulo.
O retngulo criado consiste em um nico objeto do tipo Rectangle com 3 propriedades
(width, height e color).
1 import QtQuick 1.0
2 Rectangle {
3 width: 200
4 height: 100
5 color: "green"
6 }
Listagem 9.2. Cdigo QML necessrio para exibir um retngulo.
193
9.2.1. Ambiente de Desenvolvimento
O ambiente necessrio para o desenvolvimento de aplicativos em QML disponibilizado
juntamente com o QtSDK [5], que pode ser obtido em http://qt.nokia.com/downloads. O
QtSDK inclui o Qt Quick e disponibiliza a ferramenta Qt QML Viewer [6], que muito
utilizada no desenvolvimento e depurao de cdigo QML, mas no deve ser utilizada em
ambiente de produo. Outra opo disponvel no SDK a utilizao da IDE Qt Creator,
que fornece um ambiente completo para o desenvolvimento de aplicativos em Qt/C++ e
QML.
Uma aplicao QML executada atravs da mquina de execuo QML, tambm
chamada de QML runtime, para ser executada. Existem duas maneiras de se iniciar essa
mquina de execuo: (1) a partir de uma aplicao Qt/C++ (utilizando a classe QDecla-
rativeView) ou (2) atravs da ferramenta Qt QML Viwer
2
. Aplicativos QML destinados
ao usurio nal (para instalao e utilizao no dispositivo mvel) devem utilizar a pri-
meira opo. J os aplicativos quando ainda em processo de desenvolvimento podem ser
testados utilizando o Qt QML Viewer.
Os exemplos apresentados nas prximas sees podem ser testados utilizando o
Qt QML Viewer. Porm, mais adiante neste captulo, ser apresentado como invocar
aplicativos QML utilizando cdigo Qt/C++.
9.2.2. Propriedades e Tipos de Dados
Os objetos QML so especicados por meio de seus elementos e cada elemento possui
um conjunto de propriedades. Essas propriedades so formadas por pares nome-valor
(por exemplo, color:blue) e assumem uma variedade de tipos de dados que podem ser
referncias para outros objetos, strings, nmeros, etc. Em QML, as propriedades so
fortemente tipadas, ou seja, se uma propriedade possui um tipo especco ento um valor
de tipo diferente no pode ser atribudo ela. A Tabela 9.1 apresenta alguns dos tipos de
dados comumente utilizados em propriedades QML.
Objetos denidos em QML podem ser referenciados por outros objetos por meio
da propriedade id. Essa propriedade denida explicitamente pelo programador para
identicar um objeto dentro do escopo QML. Dessa maneira, o valor de uma propriedade
de um determinado objeto podem ser externamente acessado por <id>.<propriedade>,
como na linha 5 da Listagem 9.3 com obj2.width.
Uma propriedade pode ser expressada em funo de outra propriedade do mesmo
objeto (ou de um objeto diferente, por meio de seu id) desde que possuam tipos com-
patveis. Dessa maneira, se o valor da propriedade referenciada for alterado durante a
execuo aplicao, a mquina de execuo QML recalcula a expresso e atualiza o valor
da propriedade que fez a referncia. Por exemplo, na Listagem 9.3 a propriedade height
denida pela expresso obj2.width*2. Ento, se o valor da propriedade width for alte-
rado, o valor de height ser automaticamente atualizado, alterando tambm a aparncia
visual do objeto.
QML permite que novas propriedades sejamdeclaradas na denio de um objeto.
Ainda na Listagem 9.3 (linha 7), a propriedade area, que no faz parte da denio
2
Para testar o aplicativo necessrio executar o seguinte comando: $ qmlviewer arquivo.qml
194
Tabela 9.1. Alguns tipos utilizados no sistema de tipagem da linguagem QML.
Tipo Descrio
color Nomes de cores especicadas no padro SVG [11] entre aspas. Os va-
lores tambm podem ser especicados nos formatos #RRGGBB ou
#AARRGGBB.
bool Pode assumir os valores true ou false.
date Data especicada no formato YYYY-MM-DD.
time Horrio especicado no formato hh:mm:ss.
font Encapsula as propriedades de uma instncia do tipo QFont do Qt.
int Representa valores inteiros.
double Possui ponto decimal e seus valores so armazenados com preciso dupla.
real Representa um nmero real.
list Representa uma lista de objetos.
point Representa um ponto atravs das coordenadas x e y.
rect Consiste na representao dos atributos x, y, width e height.
size Consiste na representao dos atributos width e height.
string Texto livre entre aspas.
url Representa a localizao de algum recurso, como um arquivo, atravs de seu
endereo.
original do tipo Rectangle, denida como sendo o produto width*height. O valor
dessa propriedade atualizado pela mquina de execuo QML sempre que os valores de
width e height so alterados.
1 import QtQuick 1.0
2 Rectangle {
3 id: obj1
4 width: 200
5 height: obj2.width
*
2
6 color: "#008000"
7 property real area: width
*
height
8 }
Listagem 9.3. Exemplos da utilizao de propriedades na linguagem QML.
9.2.3. Elementos Bsicos
A linguagem QML oferece um conjunto de elementos que permitema rpida e fcil inclu-
so de objetos nos aplicativos. Esses elementos podem ser aninhados permitindo a criao
de um relacionamento do tipo pai-lho (parent-child) entre eles. Esse tipo de relaciona-
mento pode ser muito til para a criao de layouts baseados em pontos de ancoragem,
que ser apresentado na Seo 9.2.4.
Uma lista dos elementos mais bsico comumente encontrados em QML est dis-
ponvel na Tabela 9.2. Esses elementos, atravs de suas propriedades e seus sinais
3
,
3
Sinais (de sinais e slots) uma caracterstica muito importante no tratamento de eventos do framework
195
Tabela 9.2. Alguns elementos bsicos disponveis na linguagem QML.
Elemento Descrio
Item O elemento mais bsico da linguagem QML. Embora no possua apa-
rncia visual, ele utilizado como base de todos os elementos visuais.
Rectangle umdos elementos mais bsicos para a criao de aplicaes em QML.
utilizado para preenchimento de reas e frequentemente utilizado
como base para o posicionamento de outros elementos.
Image O elemento utilizado para exibir imagens na UI. Todos os formatos
suportados pelo Qt podem ser utilizados no elemento Image, incluindo
PNG, JPEG e SVG.
Text utilizado para adicionar texto na UI.
TextInput Esse elemento possibilita a entrada de texto no aplicativo, podendo res-
tringir o formato dos dados de entrada travs da utilizao de uma ms-
cara de validao.
MouseArea um elemento invisvel, frequentemente utilizado em conjunto com
elementos visveis, no tratamento de eventos de entrada com o ponteiro
do mouse ou toques na tela.
possibilitam a criao das UIs e o tratamento de eventos em aplicativos mveis. Uma
lista mais completa dos elementos QML pode ser encontrada em [4].
9.2.4. Layouts Baseados em Pontos de Ancoragem
O layout baseado em pontos de ancoragem um poderoso recurso proporcionado pela lin-
guagem QML e muito til no posicionamento dos objetos na UI dos aplicativos. Cada
elemento QML possui basicamente seis pontos invisveis de ancoramento: left, right,
top, bottom, horizontalCenter e verticalCenter. Esses pontos possibilitam a criao
de relacionamentos entre as linhas de ancoragem de diferentes objetos. Em outras pala-
vras, esses pontos facilitam o posicionamento de um objeto em relao a outros objetos
adjacentes.
A Figura 9.1 apresenta um exemplo da utilizao de pontos de ancoragem com
dois elementos do tipo Rectangle. O cdigo apresentado a esquerda (Figura 9.1(a))
realiza a ancoragem da borda esquerda do objeto obj2 borda direita do objeto obj1.
Dessa maneira, obj2 sempre ca localizado direita de obj1. O resultado visual da
utilizao desses pontos de ancoragem apresentado na Figura 9.1(b).
Mltiplos pontos de ancoragem podem ser especicados por objeto. Esse tipo de
abordagem permite maior exibilidade no posicionamento dos objetos assim como me-
lhor ajuste da UI do aplicativo. Isso pode ser muito til na adaptao de aplicativos para
execuo em dispositivos com tamanhos de tela diferentes. Uma das abordagens utiliza-
das por designers grcos criar reas de utuao (que variam de tamanho) para facilitar
o reajuste dos objetos da UI em tamanhos de tela variados. A utilizao de ancoragem
permite que os valores de largura e/ou altura dessas reas sejam ajustados sem que sejam
Qt. Os sinais so emitidos com a inteno de comunicar eventos que ocorrem na aplicao. Os slots, por
sua vez, so funes que so chamadas respondendo aos sinais, ou seja, aos eventos.
196
1 Rectangle {
2 id:obj1; ...
3 Text {text: "obj1"; ...}
4 }
5 Rectangle {
6 id:obj2; ...
7 Text {text: "obj2"; ... }
8 anchors.left: obj1.right
9 }
(a) Cdigo (b) Resultado
Figura 9.1. Ancoragem da borda direita do objeto obj1 borda esquerda do objeto obj2.
denidos explicitamente.
A Figura 9.2(a) apresenta o cdigo para a criao de uma rea que redimensi-
onada dependendo do posicionamento dos outros objetos. Na denio do objeto obj2,
o ponto top foi ancorado ao bottom do objeto obj1, e o ponto bottom foi ancorado ao
top do objeto obj3. Como resultado, a propriedade height do objeto obj2 dependente
do posicionamento dos objetos obj1 e obj3, no necessitando deni-la explicitamente. O
resultado visual dessa ancoragem apresentado na Figura 9.2(b).
1 Rectangle {
2 id: obj1; ...
3 x: 0; y: 0; width: 120
4 }
5 Rectangle {
6 id: obj2; ...
7 anchors.top: obj1.bottom
8 anchors.bottom: obj3.top
9 }
10 Rectangle {
11 id: obj3; ...
12 x: 0; y: 200; width: 120
13 }
(a) Cdigo (b) Resultado
Figura 9.2. Exemplo da utilizao de ancoragem para a criao um objeto que varia a pro-
priedade height automaticamente.
Uma propriedade de ancoragem muito til e frequentemente utilizada para o pre-
enchimento de objetos o anchors.ll. Essa propriedade convenientemente xa as n-
coras left, right, top e bottom de um objeto s ncoras left, right, top e bottom de um
objeto alvo. Essa propriedade muitas vezes utilizada pelo tipo MouseArea para criar
uma rea clicvel com as mesmas dimenses de um outro objeto.
Outra propriedade de convenincia bastante utilizada o anchors.centerIn. Essa
propriedade utilizada para automaticamente centralizar um objeto em relao outro
objeto. A propriedade anchors.centerIn xa as ncoras verticalCenter e horizontal-
197
Center de um objeto s ncoras verticalCenter e horizontalCenter de outro objeto.
9.2.5. Criando a Primeira Aplicao QML
Como explicado anteriormente na Seo 9.2.1, para que seja instalada e executada no
dispositivo mvel, uma aplicao QML precisa ser executada a partir de uma aplicao
Qt/C++ utilizando a classe QDeclarativeView. A IDE Qt Creator possui templates que
facilitam a criao de projetos para executar aplicaes QML. No lado esquerdo da tela de
criao de novos projetos do Qt Creator, deve ser escolhido um projeto do tipo Qt Quick
Project, e no lado direito, um template do tipo Qt Quick Application.
Aps a escolha do nome do projeto e sua localizao, necessrio escolher o
target. Dentre as opes de target apresentadas, normalmente so escolhidas duas opes
para auxiliar no desenvolvimento de aplicaes mveis: Desktop e Remote Compiler. A
opo Desktop utilizada para compilao e execuo da aplicao no prprio desktop
durante o desenvolvimento. J a opo Remote Compiler utilizada para a compilao
dos aplicativos para plataformas mveis especcas.
No projeto criado, o arquivo principal da aplicao (main.cpp) possui o cdigo que
executa o arquivo QML principal, conforme apresentado na Listagem 9.4. Nesse exem-
plo, o objeto viewer do tipo QmlApplicationViewer congurado e dene o arquivo
QML principal como sendo qml/ERCEMAPI/main.qml (linha 10). Em seguida, o m-
todo showExpanded() do objeto viewer apresenta a o arquivo QML na tela do aplicativo,
conforme apresentado na linha 11.
O tipo QmlApplicationViewer um tipo denido no template de criao do pro-
jeto e do tipo QDeclarativeView. O QmlApplicationViewer uma classe de conveni-
ncia criada com conguraes especcas de cdigo para cada plataforma mvel, como
orientao de tela e debug.
1 // Arquivo: main.cpp
2 #include <QtGui/QApplication>
3 #include "qmlapplicationviewer.h"
4
5 int main(int argc, char
*
argv[])
6 {
7 QApplication app(argc, argv);
8 QmlApplicationViewer viewer;
9 viewer.setOrientation(
10 QmlApplicationViewer::ScreenOrientationAuto);
11 viewer.setMainQmlFile(QLatin1String("qml/ERCEMAPI/main.qml"));
12 viewer.showExpanded();
13 return app.exec();
14 }
Listagem 9.4. Arquivo Qt/C++ principal de uma aplicao QML executvel no dispositivo
mvel.
Na Listagem9.5 encontra-se o arquivo main.qml, que possui cdigo QML prin-
cipal da aplicao. Esse cdigo possui uma aplicao simples que exibe uma mensagem
Ol Mundo QML e exibe uma imagem com o logo do Framework Qt ao se clicar em
198
boto. Logo na primeira linha do arquivo, declarada a instruo import QtQuick 1.0,
utilizada para importar os principais elementos da linguagem QML. A seguir declarado
um elemento do tipo Rectangle como a base do aplicativo. interessante observar que o
elemento Item tambm pode ser utilizado para criar essa base para a construo do apli-
cativo. Nas linhas seguintes, o restante da aplicao construda declarando-se objetos
dos tipos Image, Rectangle, Text e MouseArea.
1 // Arquivo: main.qml
2 import QtQuick 1.0
3
4 Rectangle {
5 width: 640; height: 360
6 color: "white"
7 Image {
8 id: img
9 y: 250
10 source: "qt.png"
11 visible: false
12 anchors.horizontalCenter: parent.horizontalCenter
13 }
14 Rectangle {
15 color: "limegreen"; width: 150; height: 50; radius: 5
16 anchors.horizontalCenter: parent.horizontalCenter; y: 50
17 Text {
18 anchors.centerIn: parent;
19 font { family: "Helvetica"; pointSize: 20 }
20 text: "Clique aqui"
21 }
22 MouseArea {
23 anchors.fill: parent
24 onClicked: {
25 msg.text = "Ol Mundo QML"
26 img.visible = true
27 }
28 }
29 }
30 Text {
31 id: msg;
32 font { family: "Helvetica"; pointSize: 40 }
33 anchors.centerIn: parent; text: ""
34 }
35 }
Listagem 9.5. Arquivo QML principal com o cdigo da aplicao.
9.3. Tratamento de Eventos
Um dos pontos mais importantes no desenvolvimento de software para dispositivos m-
veis o tratamento de eventos, pois atravs desses eventos que ocorre a interao entre
o usurio e a aplicao. Nesta seo sero abordadas as principais maneiras de interao
com o usurio atravs do mecanismo de tratamento de eventos utilizado na linguagem
QML e no framework Qt Quick.
199
9.3.1. Sistema de Eventos Baseado em Sinais
O tratamento de eventos da linguagem QML similar ao mecanismo de sinais e slots dis-
ponvel no framework Qt. Em QML os sinais so emitidos para noticar a ocorrncia de
eventos e esto conectados a slots especcos (tambm conhecidos como manipuladores
de sinais ou signal handlers). Esses slots, por sua vez, permitem que cdigo JavaScript
seja executado em resposta um evento. Dessa maneira, sempre que um determinado si-
nal associado a um evento for emitido, o slot associado a esse sinal chamado e o cdigo
JavaScript contido nele executado.
Cada elemento QML possui seus prprios slots, cada um associado a um sinal ou
mesmo uma propriedade. No caso dos sinais, os slots seguem uma sintaxe padro do
tipo: on<Sinal>. Por exemplo, o tipo MouseArea possui o sinal clicked e um slot asso-
ciado chamado onClicked. De maneira semelhante, cada propriedade possui um slot as-
sociado s mudanas de valor atravs da seguinte sintaxe: on<Propriedade>Changed.
Por exemplo, o slot onWidthChanged refere-se ao slot da propriedade width. Assim,
sempre que ocorrerem alteraes no valor dessa propriedade, seu slot correspondente ser
chamado.
O cdigo exibido na Listagem 9.6 apresenta um exemplo de tratamento de evento
de clique emumelemento do tipo MouseArea. Esse cdigo fecha a aplicao executando
o comando JavaScript quit() disponvel na varivel global Qt.
1 MouseArea {
2 anchors.fill: parent
3 onClicked: {
4 Qt.quit();
5 }
6 }
Listagem 9.6. Tratamento de evento de clique no elemento MouseArea.
Ao declarar novos sinais ou propriedades, o framework Qt Quick automaticamente
cria slots seguindo as convenes de nomenclatura apresentadas anteriormente. Logo,
possvel construir um sistema prprio de eventos, estendendo os sinais e slots bsicos
providos pelo framework Qt Quick. Por exemplo, ao implementar um teclado virtual,
seria interessante que a assinatura do sinal tivesse um parmetro para enviar o valor da
tecla pressionada ao slot quando o sinal for emitido.
O cdigo exibido na Listagem 9.7 mostra como um teclado virtual poderia ser im-
plementado em QML. O elemento Rectangle no possui um sinal que emitido na ocor-
rncia de eventos de clique, e to pouco um slot para tratar esses eventos. Dessa maneira,
um sinal clicked(string value) declarado recebendo como argumento um valor do tipo
string (linha 5). Ao declarar esse sinal, o slot onClicked criado automaticamente no
objeto button do tipo Rectangle. No slot onClicked do elemento MouseArea, o sinal
button.clicked(string value) emitido e passa como argumento o valor buttonText.text
(linha 13). No slot onClicked do objeto button, essa propriedade pode ser acessada atra-
vs do parmetro value passado pelo sinal clicked(string value), conforme apresentado
na linha 15.
200
1 import QtQuick 1.0
2
3 Rectangle {
4 id: button; ...
5 signal clicked(string value)
6 Text {
7 id: buttonText
8 anchors.centerIn: parent
9 text: "A"
10 }
11 MouseArea {
12 anchors.fill: parent
13 onClicked: button.clicked(buttonText.text)
14 }
15 onClicked: console.log(value)
16 }
Listagem 9.7. Trecho de cdigo da implementao de um teclado virtual com sinais e slots
customizados.
9.3.2. Elementos de Interao
O mais primrio tipo de interao que um usurio espera ter com um software moderno se
d atravs de interaes de mouse ou outro mecanismo apontador. Esse tipo de interao
no limita-se somente aos cliques. Na verdade, existem vrios outros eventos como boto
pressionado, boto solto, movimento, etc. Com a crescente popularizao das telas de
toque em dispositivos mveis, como tablets e smartphones, outros tipos de interaes
(como gestos de ick, swipe, pinch e drag) vm sendo absorvidas pelos usurios.
Na linguagemQMLalguns componentes j implementamalgumtipo de interao,
como o caso dos elementos a seguir: ListView, GridView e PathView, que permitem
fazer o scroll por seus elementos; TextInput e TextEdit, que possibilitama insero e edi-
o de texto; Flickable e PinchArea, que lidam com a interao atravs de gestos de ick
e pinch; Flipable e MouseArea, que tratam dos eventos de mouse; e nalmente Keys e
FocusScope, referentes aos eventos de teclado. Nas sees a seguir, sero apresentados
os tipos de interao mais bsicos que podem ser implementados com a linguagem QML:
eventos de clique (MouseArea) e entrada de texto (TextInput).
9.3.2.1. MouseArea
O MouseArea trata-se de um elemento para o tratamento de eventos de clique. Ele
possui todos os sinais e slots necessrios para a construo de qualquer funcionalidade
baseada em eventos de mouse. O MouseArea um elemento invisvel e sua utilizao ,
tipicamente, associada a um elemento visvel.
O elemento MouseArea permite capturar uma variedade de eventos atravs de
seus slots. Os slots apresentados na Tabela 9.3 so os mais comuns emdispositivos mveis
e podem ser amplamente utilizados no tratamento de eventos em aparelhos que possuem
tela de toque. O exemplo exibido na Listagem 9.8 apresenta o cdigo para o tratamento
de eventos de clique (onClicked) e pressionamento e liberao (onPressAndHold) em
201
aplicativos que possuam tela de toque. O slot chamado para cada sinal escreve o tipo
de evento no console do aplicativo. Os outros eventos apresentados na Tabela 9.3 so
tratados de maneira semelhante.
Slot Descrio
onCanceled Chamado quando um evento de mouse cancelado, seja porque
o evento no foi aceito ou porque foi interceptado por outro ele-
mento.
onClicked Chamado quando ocorre um clique, ou seja, um pressionamento
seguido de liberao.
onDoubleClicked Chamado quando ocorre um duplo clique, ou seja, um pressio-
namento seguido de uma liberao seguida de outro pressiona-
mento.
onPressAndHold Esse slot chamado quando existe um longo pressionamento (du-
rante 800ms).
onPressed O slot chamado quando ocorre um pressionamento.
onReleased Chamado quando ocorre uma liberao do ponteiro.
Tabela 9.3. Principais slots associados aos eventos do elemento MouseArea.
1 import QtQuick 1.0
2
3 Item {
4 width: 360
5 height: 640
6
7 MouseArea {
8 anchors.fill: parent
9 onClicked: console.log("Evento: click")
10 onPressAndHold: {
11 console.log("Evento: Press and hold")
12 }
13 }
14 }
Listagem 9.8. Tratamento de eventos de mouse com os slots onClicked e onPressAndHold.
Outra funcionalidade muito interessante proporcionada pelo MouseArea o drag.
Atravs do drag, o usurio pode arrastar elementos na tela. Esse evento muito utilizado
em dock widgets
4
e jogos. O exemplo exibido na Listagem 9.9 ilustra como o evento de
drag pode ser alcanado facilmente usando o elemento MouseArea.
importante observar que o layout baseado em pontos de ancoragem pode com-
prometer o tratamento de eventos de drag. Dependendo do tipo de ancoragem utilizado, o
objeto pode car totalmente ancorado, impedindo sua movimentao na tela do aplicativo.
4
Dock widgets um painel de cones que inicialmente aparece escondida nas bordas da tela de um
aplicativo. Ao clicar e arrastar a dock widgets, o painel com os cones exibido, permitindo assim que esses
cones sejam clicados.
202
1 import QtQuick 1.0
2
3 Rectangle {
4 id: background
5 color: "lightblue"
6 width: 360
7 height: 640
8 ...
9 Rectangle {
10 id: dragable
11 color: "white"
12 width: 50
13 height: 50
14 ...
15 MouseArea {
16 anchors.fill: parent
17 drag.target: dragable
18 }
19 }
20 }
Listagem 9.9. Exemplo de implementao de um evento de drag.
9.3.2.2. Entrada de Dados
Na linguagem QML, os elementos disponveis para realizar entrada de dados so TextIn-
put e TextEdit. Ambos so utilizados para entrada de texto, porm o TextInput mostra
uma nica linha de texto editvel no formatado, enquanto o TextEdit exibe vrias linhas
de texto editvel e formatado.
O texto digitado no elemento TextInput pode ser restringido atravs da utilizao
da propriedade validator ou inputMask. Utilizando as restries de entrada, o elemento
TextInput somente aceitar o texto que esteja em um estado aceitvel ou, no mnimo,
intermedirio. Alguns validadores suportados so IntValidator, DoubleValidator e Re-
gExpValidator.
A Listagem 9.10 apresenta um trecho de cdigo demonstrando a utilizao da
propriedade validator para a validao de texto. Nesse exemplo, a propriedade utiliza
o tipo DoubleValidator com as seguintes propriedades: bottom (menor valor assumido
pelo campo), top (maior valor assumido pelo campo) e decimals (nmero mximo de
dgitos aps o ponto decimal). O slot onTextChanged verica o valor da propriedade
acceptableInput e modica a cor de fundo do campo de entrada para verde claro quando
o texto for vlido ou para vermelho claro, caso contrrio.
Outra possibilidade interessante do elemento TextInput a utilizao da pro-
priedade echoMode, que especica como o texto deve ser apresentado. Essa propri-
edade pode assumir as seguintes opes: TextInput.Normal (exibio normal), TextIn-
put.Password (exibe asteriscos e normalmente utilizado para exibio de senhas), Tex-
tInput.NoEcho (no exibe o texto) e TextInput.PasswordEchoOnEdit (com exceo do
caractere atual, todos os outros so exibidos como asterisco).
203
1 import QtQuick 1.0
2
3 Rectangle {
4 id: background
5 width: 200
6 height: 70
7 TextInput {
8 focus: true; horizontalAlignment: TextInput.AlignHCenter
9 font {family: "Helvetica"; pointSize: 20}
10 anchors { fill: parent; topMargin: 20 }
11 validator: DoubleValidator {
12 bottom: 0.0; top: 99.99; decimals: 2
13 }
14 onTextChanged: {
15 if (acceptableInput) {
16 background.color = "lightgreen"
17 } else {
18 background.color = "indianred"
19 }
20 }
21 }
22 }
Listagem 9.10. Exemplo do uso da propriedade validator no elemento TextInput.
9.4. Criando Animaes com Estados e Transies
As propriedades de objetos QML podem ser manipuladas atravs de cdigo JavaScript,
permitindo assim que animaes sejam criadas de maneira imperativa. A criao de ani-
maes atravs de cdigo JavaScript muitas vezes uma tarefa complexa para os progra-
madores. QML disponibiliza um conjunto de elementos baseados emestados e transies,
que quando associados a outros elementos, facilitam a criao de animaes nas aplica-
es. As sees a seguir apresentam os conceitos e elementos relacionados a estados,
transies e animaes em QML.
9.4.1. Estados em QML
Em QML, estados so colees de conguraes denidas atravs do elemento State.
Um objeto alcana um estado quando as mudanas realizadas nas suas propriedades re-
presentam um dos estados presentes em sua coleo de estados. A propriedade states
armazena essa coleo (representado atravs de uma lista de objetos do tipo State) e
representa todos os estados possveis de um objeto.
A simples declarao de um elemento automaticamente cria um estado padro,
chamado de estado base, denido como (string vazia). Esse o estado em que um ob-
jeto se encontra quando no representa nenhum dos estados denidos em sua propriedade
states. Outros estados podem ser declarados e a transio entre esses estados pode ser re-
alizada facilmente modicando o valor da propriedade state (no singular), que armazena
o estado atual de um objeto. O valor dessa propriedade pode ser modicado diretamente
em um slot ou funo escrita em JavaScript, como apresentado na Listagem 9.11.
O elemento State possui as seguintes propriedades: changes (lista de mudanas
204
1 onClicked: {
2 if(obj.state == "clicado") {
3 obj.state = "";
4 }
5 else {
6 obj.state = "clicado";
7 }
8 }
Listagem 9.11. Exemplo da alterao do estado de um objeto utilizando cdigo JavaScript
diretamente.
a serem realizadas neste estado), extend (nome do estado pai), name (nome do estado)
e when (condio para ativao do estado). A Listagem 9.12 apresenta um exemplo da
utilizao da propriedade when para a ativao do estado clicado do objeto rect. Nesse
caso, a propriedade diz que esse estado s ser ativado quando o objeto representado pelo
MouseArea for clicado, ou seja, quando o sinal clicked do objeto mouse for emitido.
Na linha 12 da Listagem9.12 tambm possvel observar a utilizao do elemento
PropertyChanges. Esse elemento utilizado para modicar as propriedades de um ob-
jeto especco identicado em target durante o tempo em que um estado estiver ativado.
Ento, nesse exemplo, a propriedade color do objeto rect (target) alterada para red
enquanto esse objeto estiver no estado clicado.
1 import QtQuick 1.0
2
3 Rectangle {
4 id: rect; color: "green"; width: 120; height: 120
5 MouseArea { id: mouse; anchors.fill: parent }
6 states: [
7 State {
8 name: "pressed"
9 when: mouse.pressed
10 PropertyChanges { target: rect; color: "red" }
11 }
12 ]
13 }
Listagem 9.12. Utilizao da propriedade when do elemento State para modicao de
estado de um objeto.
9.4.2. Animao com com elemento Behavior
Em QML, a transio de um estado para outro ocorre de maneira brusca e como con-
sequncia os valores das propriedades tambm so alterados bruscamente. Porm, muitas
vezes, o esperado que a transio ocorra de maneira suave, ou seja, atravs de ani-
maes, que so criadas atravs da interpolao entre os valores inicial e nal de uma
propriedade.
O elemento Behavior utilizado com o propsito de se criar animaes em QML.
Esse elemento dene uma animao padro que deve ser utilizada sempre que uma de-
205
terminada propriedade de um objeto sofrer alteraes. Uma boa prtica de programao
para esse elemento utilizar estados bem denidos para realizar as transies, ou seja,
evitar a utilizao do estado base (). Essa prtica recomendada porque se uma anima-
o for interrompida, o estado base assume os valores intermedirios das propriedades e
o comportamento nal pode no ser o esperado.
A Listagem 9.13 apresenta um exemplo da utilizao do elemento Behavior.
Nesse exemplo, foram declarados dois estados no objeto rect, denominados EstadoIn-
cial e EstadoFinal. A propriedade x possui o valor 0 no primeiro estado e o valor 400
no segundo estado. A declarao Behavior on x responsvel por realizar a interpolao
dos valores dessa propriedade entre os dois estados que foram declarados. A interpolao
do tipo NumberAnimation e deve ter uma durao de 200ms.
Alm do tipo NumberAnimation existem outras animaes baseadas nos tipos
de dados. Algumas das animaes mais utilizadas so: ColorAnimation, para animar
mudanas nos valores de cor; RotationAnimation, para animar rotaes; e PropertyA-
nimation, para animar mudanas nos valores de propriedades.
1 import QtQuick 1.0
2
3 Rectangle {
4 width: 500; height: 100
5 MouseArea { id: mouse; anchors.fill: parent }
6 Rectangle {
7 id: rect; width: 100; height: 100; color: "blue"
8 Behavior on x { NumberAnimation{duration: 200} }
9 states: [
10 State {
11 name: "EstadoInicial"
12 when: !mouse.pressed
13 PropertyChanges { target: rect; x: 0 }
14 },
15 State {
16 name: "EstadoFinal"
17 when: mouse.pressed
18 PropertyChanges { target: rect; x: 400 }
19 }
20 ]
21 }
22 }
Listagem 9.13. Exemplo de animao utilizando o elemento Behavior.
Uma propriedade pode ter somente um elemento Behavior associado ela. Para
realizar mltiplas transies com diferentes propriedades necessrio utilizar os elemen-
tos ParallelAnimation ou SequentialAnimation, para animaes paralelas ou sequenci-
ais, respectivamente.
9.4.3. Transies entre estados
Outra forma de se fazer animaes em transies entre estados utilizando o elemento
Transition. Esse elemento dene as animaes que devem acontecer quando ocorrem
206
trocas de estados. As transies so atribudas a um objeto atravs da propriedade transi-
tions, que pode receber um nico objeto ou uma lista de objetos do tipo Transition.
O elemento Transition possui 4 propriedades: animation, que um lista de ani-
maes que devemser executadas durante a transio; frome to, indicamque a transio
aplicvel somente quando ocorrer a mudana de estados especicada nessas propriedades;
e reversible, que indica se a animao da transio deve ser automaticamente revertida
quando as condies de ativao forem invertidas. Essa ltima propriedade evita a criao
de uma nova transio para realizar a animao reversa quando as condies de ativao
estiverem invertidas.
As transies podem conter elementos de animao para interpolar as mudanas
causadas por mudanas de estados nos valores das propriedades. Os elementos utilizados
podem ser os mesmos utilizados com o elemento Behavior apresentado na Seo 9.4.2.
Porm, se uma mudana de estado altera uma propriedade que foi declarada tanto em um
Transition quanto em um Behavior, o comportamento denido no elemento Transition
sobrepe o elemento Behavior.
A Listagem 9.14 apresenta um exemplo da utilizao do elemento Transition para
realizar animaes. Nesse exemplo, o elemento dene animaes para as propriedades
color e x do objeto obj utilizando os elementos de animao ColorAnimation e Numbe-
rAnimation, respectivamente.
1 import QtQuick 1.0
2
3 Rectangle {
4 width: 200; height: 100
5 Rectangle { id: obj; width: 100; height: 100; color: "red" }
6 MouseArea { id: mouse; anchors.fill: parent }
7 states: State {
8 name: "EstadoFinal";
9 when: mouse.pressed
10 PropertyChanges { target: obj; x: 100; color: "green" }
11 }
12 transitions: Transition {
13 NumberAnimation { properties: "x"; duration: 200 }
14 ColorAnimation { duration: 200 }
15 }
16 }
Listagem 9.14. Exemplo da utilizao do elemento Transition para realizar animaes.
9.5. Componentes QML Customizados
A linguagem QML fortemente baseada nos conceitos de componentizao. Dessa ma-
neira, qualquer trecho de cdigo pode ser tornar um componente e a prpria declarao
de elementos pode ser vista como o uso de componentes pr-denidos.
9.5.1. Denio de Componentes
Um componente QML como uma caixa preta que interage com o mundo externo atra-
vs de suas propriedades, sinais e funes, e geralmente denido dentro de um arquivo
207
QML. Um ponto importante a ser considerado que arquivos QML que denem com-
ponentes deve ter seus nomes iniciados com letra maiscula. A Listagem 9.15 apresenta
um exemplo de um componente Button, denido em um arquivo Button.qml, que emite
sinais medida que recebe cliques do usurio.
1 // Arquivo: Button.qml
2 import QtQuick 1.0
3
4 Rectangle {
5 id: button
6 anchors.centerIn: parent
7 width: 100; height: 100
8 radius: 50; color: red
9 signal clicked
10 MouseArea {
11 anchors.fill: button
12 onClicked: {
13 button.clicked()
14 }
15 }
16 }
Listagem 9.15. Componente customizado criado com o nome de arquivo Button.qml.
Componentes em QML tambm podem ser criados de uma maneira mais explcita
usando o elemento Component, que permite uma denio inline, ou seja, dentro de um
documento QML, ao invs de um arquivo separado. A vantagem do uso desse elemento
permitir reusar pequenas denies de componente dentro de um arquivo QML, ou para
denir componentes que pertencem logicamente a um mesmo arquivo QML. Assim, o
elemento Component gera componentes abstratos que servem como um modelo para
reproduzir e renderizar cpias do componente denido. importante esclarecer que o
elemento Component apenas atua na denio de componentes e essa denio pode
ser utilizada por outros elementos e mtodos, tais como:
Loader. um elemento usado para carregar componentes QML visuais dinami-
camente. Atravs dele possvel especicar como fonte de referncia tanto um
arquivo QML, usando a propriedade source, quanto um objeto Component, este
ltimo utilizando a propriedade sourceComponent;
createObject. um mtodo pertencente aos objetos do tipo Component, que
permite criar dinamicamente objetos a partir de suas denies de componente.
Este mtodo recebe como parmetro a referncia (id) do objeto que ser o pai do
novo objeto criado.
A Listagem 9.16 apresenta um exemplo da denio de um componente como
um crculo de cor verde com id igual a circleComponent. Nesse exemplo, o elemento
Loader declarado, especicando o objeto circleComponent como sendo o componente
de referncia, atravs da propriedade sourceComponent, e ento um crculo verde
renderizado na tela do dispositivo na posio padro (x = 0 e y = 0).
208
O mesmo exemplo mostra a declarao de um elemento MouseArea, onde de-
clarado um slot onMousePositionChanged que chamado no momento em que ocorre
uma mudana no ponto de clique na tela, ou seja, no momento em que a rea de toque
arrastada. Nesse slot listada uma sequncia de comandos visando a criao de objetos
dinamicamente segundo a denio feita no componente circleComponent. A cada vez
que o slot onMousePositionChanged chamado, o mtodo createObject() de circle-
Component cria um novo objeto do mesmo tipo dentro do objeto mainView. Quando
ocorre a criao do crculo dentro do slot, algumas das suas propriedades so alteradas
diretamente no objeto armazenado na varivel JavaScript circle. Assim, o novo crculo
passa a ter seu centro no posio atual do mouse, e sua cor passa a ser azul.
1 import QtQuick 1.0
2
3 Item {
4 id: mainView; width: 360; height: 640
5 Component {
6 id: circleComponent
7 Rectangle {
8 id: circle
9 width: 40; height: 40; radius: 40; color: "green"
10 }
11 }
12 Loader { id: pointer; sourceComponent: circleComponent}
13 MouseArea {
14 anchors.fill: mainView
15 onMousePositionChanged: {
16 var circle = circleComponent.createObject(mainView)
17 circle.x = mouseX - circle.width/2
18 circle.y = mouseY - circle.height/2
19 circle.color = blue
20 }
21 }
22 }
Listagem 9.16. Denio e carregamento de um componente para desenhar um crculo.
9.5.2. Criao Dinmica de Componentes com JavaScript
A utilizao de cdigo JavaScript outra maneira de especicar os componentes. Essa
abordagem bastante usada no desenvolvidos de jogos em QML, onde preciso criar um
nmero grande de objetos referentes cena de jogo e fazer o gerenciamento destes
medida em que ocorrem alteraes no estado do jogo.
Para denir componentes dentro de um trecho de cdigo JavaScript utilizada
a funo createComponent() pertencente a varivel global Qt. Esta funo requisita
como parmetro a url do arquivo QML onde o componente foi declarado e retorna um
objeto do tipo Component.
A criao de objetos a partir de componentes que foram denidos possvel por
meio do mtodo createObject(). Esta funo pertence a objetos do tipo Component, e
recebe como parmetros a referncia do item que ser o pai do novo objeto e um valor do
tipo dicionrio, uma srie de pares chave-valor com as conguraes das propriedades. O
209
retorno desta funo um objeto denido da forma como declarado no Component e
com suas propriedades alteradas segundos os valores passados como argumento. Assim
possvel criar diferentes objetos de uma denio de componente e customizar livremente
seus valores de propriedades.
O cdigo apresentado na Listagem 9.17 demonstra a criao de um componente
do tipo Button, mostrando que o objeto criado segue a mesma interface denida na de-
clarao inicial do componente. Um objeto do tipo Button criado de maneira dinmica
atravs do mtodo createComponent() e armazenado na varivel buttonComponent.
A varivel buttonObj, por sua vez, recebe um objeto Button aps a chamada do mtodo
createObject() do objeto buttonComponent, conforme apresentado na linha 14.
1 import QtQuick 1.0
2
3 Rectangle {
4 id: mainView
5 width: 360
6 height: 640
7
8 function randomColor() {
9 return Qt.rgba(Math.random(),
10 Math.random(),
11 Math.random(),
12 0.5 + (Math.random())/2)
13 }
14
15 Component.onCompleted: {
16 var buttonComponent = Qt.createComponent("Button.qml");
17 var buttonObj = buttonComponent.createObject(
18 mainView,
19 {"color" : randomColor()});
20 buttonObj.clicked.connect(function() {
21 color = randomColor()
22 });
23 }
24 }
Listagem 9.17. Criao de componentes utilizando cdigo JavaScript.
Tanto as propriedades quando os sinais fazem parte da interface de um compo-
nente QML, assim todos os objetos criados a partir de um componente possuem as mes-
mas denies de propriedades e sinais. Logo, ainda na Listagem 9.17, possvel co-
nectar um slot ao sinal clicked do objeto buttonObj do tipo Button (linha 16), onde tal
sinal foi denido. O papel do slot conectado ao sinal clicked atribuir um valor de cor
aleatrio a propriedade color tela de fundo do aplicativo. interessante perceber que
apesar de estar dentro de um slot do objeto do tipo Button, o escopo de propriedade per-
tence a mainView, dado que o Component.onCompleted declarado em mainView.
Decorre ento que a propriedade color refere-se ao objeto mainView e no ao prprio
Button. Como resultado, tem-se um boto centralizado no objeto pai, mainView, e que
ao ser pressionado altera a cor de fundo da tela.
210
9.5.2.1. Criao de Objetos a partir de uma String
Uma maneira interessante de criao de objetos QML em tempo de execuo a partir
de uma string utilizando cdigo JavaScript. Esses objetos so criados atravs do mtodo
createQmlObject() disponvel na varivel global Qt, conforme apresentado na Lista-
gem 9.18.
1 var newObj = Qt.createQmlObject(
2 import QtQuick 1.0; +
3 Rectangle { color: "red"; width: 20; height: 20},
4 parentItem,
5 "dynamicSnippet1");
Listagem 9.18. Novo objeto criado a partir de uma string utilizando cdigo JavaScript
O primeiro argumento do mtodo dene o componente, utilizando o cdigo com
os mesmos elementos de declaraes em arquivos QML. Se o cdigo denido na string
possuir algum caminho de arquivo, este deve ser relativo ao item pai do objeto criado.
O segundo argumento o item pai do objeto a ser criado. Por m, o terceiro argumento
apenas um nome de diretrio associado ao novo objeto, caso seja necessrio reportar
erros.
9.5.2.2. Deletando Objetos Dinamicamente
De maneira geral, uma grande quantidade de itens criados dinamicamente poder trazer
impactos negativos ao desempenho de um aplicativo. Assim, altamente recomendvel
que se tenha um bom gerenciamento dos objetos criados. Deletar os objetos criados
dinamicamente medida que se tornarem desnecessrios pode beneciar o desempenho
como um todo.
importante pontuar a diferena entre itens criados dinamicamente por funes
JavaScript e aqueles criados por elementos QML, tais como o Loader. Estes ltimos pos-
suem em sua implementao o pressuposto de que seus itens gerados no sero deletados
durante o tempo de vida do componente que os engloba. Assim deve ser evitado deletar
qualquer item que no tenha sido diretamente criado por funes JavaScript.
Todo item possui um mtodo de destruio chamado destroy(). Este mtodo pos-
sui um argumento opcional onde pode ser passado o tempo em milissegundos antes que o
objeto seja destrudo. A Listagem 9.19 apresenta umexemplo de criao dinmica atravs
de uma string e destruio do objeto criado. O trecho de cdigo denido no slot onCom-
pleted executado no momento em que o item pai mainView carregado e renderizado
na tela. Ento, um novo objeto criado (um retngulo vermelho de bordas arredondadas)
cujo pai denido como sendo o mainView e seu caminho para relatrios de erros como
snippetCode1. A varivel newObject passa a armazenar o objeto retngulo, enquanto
na linha seguinte uma varivel newMouseArea recebe uma instncia do tipo MouseA-
rea. Ao nal do exemplo, um slot conectado ao sinal clicked do MouseArea, onde o
primeiro objeto tem sua opacidade modicada para zero e ento seu mtodo de destruio
chamado.
211
1 import QtQuick 1.0
2
3 Rectangle {
4 id: mainView; width: 640; height: 360
5 Component.onCompleted: {
6 var newObject = Qt.createQmlObject(
7 " import QtQuick 1.0; " +
8 " Rectangle { anchors.centerIn: parent; " +
9 " color: red; width: 200; height: 200; " +
10 " radius: 20}",
11 mainView, "snippetCode1");
12 var newMouseArea = Qt.createQmlObject(
13 " import QtQuick 1.0; " +
14 " MouseArea { anchors.fill: parent;}",
15 newObject, "mouseArea1");
16 newMouseArea.clicked.connect(function() {
17 newObject.opacity = 0;
18 newObject.destroy(1000)
19 });
20 }
21 }
Listagem 9.19. Exemplo da utilizao do mtodo destroy() para a destruio de objetos
criados dinamicamente.
9.5.3. Denio de Componentes utilizando Qt/C++
A grande diversidade de elementos QML permitem criar variados tipos de interface de
maneira declarativa. Entretanto para aplicaes que exijam renderizaes de forma geo-
mtricas complexas ou possuam comportamento funcional acima do disponibilizado pe-
los elementos QML padres, existe a possibilidade de estender novas funcionalidade atra-
vs de classes C++. Dessa maneira, elementos QML com alto grau de customizao po-
dem ser denidos em uma classe C++ que herde o QDeclarativeItem, a classe pai de
todos os itens declarativos.
Feita a sobrecarga do mtodo de paint do QDeclarativeItem, possvel criar um
componente QML utilizando todas as potencialidades oferecidas pelo framework Qt. Na
Listagem 9.20, um tringulo desenhado atravs de um caminho de pontos pr-denidos,
um QPaintPath. O painter congurado para realizar a renderizao do caminho de
pontos denido, atravs do mtodo drawPath do QPainter. Os mtodos setPen e set-
Brush apenas selecionam a cor preta para os traos do desenho e uma cor pr-denida
m_color para o preenchimento da gura.
9.5.3.1. Criao de Novos Tipos
Uma vez que um novo elemento QML criado em C++, necessrio registr-lo para uso
dentro de arquivos QML, ou seja, preciso certicar que a mquina de execuo QML
consiga compreender o signicado dos novos smbolos denidos.
Especicada no cabealho qdeclarativeengine.h, a funo qmlRegisterType re-
212
1 class MyItem : public QDeclarativeItem
2 {
3 ...
4 void paint(QPainter
*
painter,
5 const QStyleOptionGraphicsItem
*
,
6 QWidget
*
) {
7 QPainterPath path;
8 path.moveTo(boundingRect().width()/2,0);
9 path.lineTo(boundingRect().width(),boundingRect().height());
10 path.lineTo(0,boundingRect().height());
11 path.lineTo(boundingRect().width()/2,0);
12
13 painter->setPen(QColor("black"));
14 painter->setBrush(QBrush(m_color));
15 painter->drawPath(path);
16 }
17 };
Listagem 9.20. Denio de um novo componente utilizando cdigo Qt/C++.
gistra os tipos C++ no sistema QML, atravs da especicao de um URI (Uniform Re-
source Identier) da biblioteca, um nmero de verso e o nome do componente. Abaixo
segue um exemplo de seu uso dentro do cdigo C++, onde o elemento MyItem decla-
rado atravs do registro da classe MyItem dentro da biblioteca MyComponents sob a
verso 1.0.
qmlRegisterType<MyItem>("MyComponents", 1, 0, "MyItem");
Oitemcustomizado pode ser facilmente importado para o cdigo QML, sendo que
para isso necessrio conhecer o nome e verso da biblioteca onde est agrupado, assim
como seu nome de componente. Uma vez importado, o novo elemento segue exatamente
as mesmas regras de qualquer outro elemento do tipo Item, possuindo assim tambm
suas propriedades, tais como x, y, width, height e outras. A Listagem 9.21 apresenta um
exemplo da utilizao do elemento do novo tipo (MyItem) criado a partir de cdigo C++.
1 import MyComponents 1.0
2
3 Rectangle {
4 MyItem {
5 id: myItem
6 }
7 }
Listagem 9.21. Declarao do novo elemento criado a partir de cdigo C++.
9.6. Plataformas de Desenvolvimento
No contexto de dispositivos mveis, Symbian e Maemo/MeeGo so algumas plataformas
que oferecem suporte ao desenvolvimento de aplicaes em Qt. No desenvolvimento em
Qt, geralmente no so necessrias muitas modicaes no cdigo para que um projeto
213
existente funcione em uma nova plataforma. Dessa maneira, na maioria dos casos o
processo de compilar o cdigo para essa nova plataforma e executar a aplicao funciona
sem maiores problemas. Porm, algumas vezes necessrio realizar conguraes de
projeto no arquivo .pro para que o aplicativo tenha acesso aos recursos do dispositivo.
A Listagem 9.22 apresenta algumas conguraes especcas da plataforma Sym-
bian utilizadas no desenvolvimento de aplicaes. As duas instrues apresentadas nessa
listagem so: TARGET.CAPABILITIES, que dene privilgios extras para que a aplica-
o tenha acesso aos recursos do dispositivo, como o caso dos servios de rede com
NetworkServices; e TARGET.EPOCHEAPSIZE, que dene a quantidade mnima e
mxima de memria disponvel para a aplicao.
1 symbian: {
2 ...
3 TARGET.CAPABILITY += NetworkServices
4 TARGET.EPOCHEAPSIZE = 0x020000 0x4000000
5 ...
6 }
Listagem 9.22. Conguraes especcas da plataforma Symbian para desenvolvimento Qt.
Na plataforma Maemo/MeeGo, a IDE Qt Creator cria os projetos com todos os
recursos necessrios para o desenvolvimento. No caso da plataforma Android, ainda no
existe um port ocial, mas j existem algumas iniciativas para utilizar desenvolver com
o Framework Qt nessa plataforma. O Necessitas [3] um projeto que tem o objetivo de
prover o port do Qt para a plataforma Android e integrao com o Qt Creator. O site do
projeto fornece as informaes necessrias para comear a utilizar o Necessitas SDK.
Quanto ao processo de compilao das aplicaes para instalao no dispositivo
mvel, o QtSDK fornece o mdulo Remote Compiler. Esse mdulo foi criado para con-
tornar a ausncia de solues que permitissem a compilao dos binrios Symbian nas
plataformas Linux e Apple Mac. Esse recurso permite a compilao para as plataformas
Symbian S60, Symbian1, Symbian3, Maemo 5 e MeeGo 1.2 Harmattan, oferecendo
suporte para a verso 4.6 do Qt, incluindo o Qt Quick a partir da verso 4.7 do Qt.
9.7. Consideraes Finais
Os elementos e caractersticas da linguagem QML apresentados neste captulo possibi-
litam o desenvolvimento cross-platform de UIs de alto nvel de maneira rpida e intui-
tiva. Para reforar a importncia desse kit de desenvolvimento, o framework Qt vem
sendo utilizado por grandes empresas em projetos como Google Earth, Skype, KDE e
Opera [7]. O Ambiente declarativo Qt Quick, atravs da linguagem QML, surge como
uma ferramenta promissora para a criao de UIs onde a rapidez de desenvolvimento e
a experincia do usurio so cruciais para as aplicaes. Alm disso, novos dispositivos
mveis recentemente lanados com o sistema operacional MeeGo possuem o Qt como kit
de desenvolvimento padro.
Emresumo, neste captulo foi apresentado como utilizar a linguagemQMLno am-
biente declarativo Qt Quick para a criao de interfaces para dispositivos mveis. Atravs
de elementos bsicos como Rectangle, Item, MouseArea, Text e Image foi apresen-
214
tado como especicar UIs pelo seu contedo, e no por meio de comandos imperativos
em Qt/C++ na especicao dos mtodos. Alm disso, outras caractersticas importan-
tes da linguagem QML (como a criao de animaes e o tratamento de eventos) foram
apresentadas, possibilitando a criao de UIs modernas e exveis.
9.8. Agradecimentos
A escrita deste captulo foi apoiada pelo CETELI (Centro de Pesquisa e Desenvolvimento
em Tecnologia Eletrnica e da Informao) e pelo INdT (Instituto Nokia de Tecnologia).
Referncias
[1] Goderis, S. (2005) High-level declarative user interfaces. In: Companion to the
20th annual ACM SIGPLAN conference on Object-oriented programming, sys-
tems, languages, and applications (OOPSLA 05). New York, NY, USA, ACM,
p. 236-237.
[2] QUIt Coding, Crash course to Qt Quick Game Programming, disponvel
em: http://quitcoding.com/download/Qt_Quick_Game_Programming_1_0.pdf,
acessado em outubro de 2011.
[3] Necessitas, disponvel em: http://sourceforge.net/p/necessitas/home/necessitas/,
acessado em outubro de 2011.
[4] Nokia, QML Elements, disponvel em: http://doc.qt.nokia.com/4.7-
snapshot/qdeclarativeelements.html, acessado em outubro de 2011.
[5] Nokia, Qt - Cross-platform application and UI framework, disponvel em:
http://qt.nokia.com/, acessado em outubro de 2011.
[6] Nokia, Qt 4.7: QML Viewer, disponvel em: http://doc.qt.nokia.com/4.7-
snapshot/qmlviewer.html, acessado em outubro de 2011.
[7] Nokia, Qt in Use, disponvel em: http://qt.nokia.com/qt-in-use/, acessado em ou-
tubro de 2011.
[8] Nokia, Qt Quick, http://qt.nokia.com/qtquick/, acessado em outubro de 2011.
[9] Vision Mobile, Developer Economics 2011, Disponvel em:
http://www.visionmobile.com/devecon.php, acessado em outubro de 2011.
[10] Vision Mobile, Mobile Economics Developer 2010 and Beyond, Disponvel em:
http://www.visionmobile.com/rsc/researchreports/Mobile%20Developer %20Eco-
nomics%202010%20Report%20FINAL.pdf, acessado em outubro de 2011.
[11] W3C Recommendation, Basic Data Types and Interfaces, disponvel em:
http://www.w3.org/TR/SVG/types.html#ColorKeywords, acessado em outubro de
2011.
[12] Zucker, D. e Rischpater, R., Beginning Nokia Apps Development: Qt and HTML5
for Symbian and MeeGo, Apress Series. Apress, 2010.
215
Captulo
10
Tcnicas de Processamento de Imagens em Diag-
nstico Auxiliado por Computador
Rodrigo M. S. Veras, Ilis C. Paula Jr. e Ftima N. S. Medeiros
Abstract
Computer-aided diagnosis systems (CAD) are dened to improve the accuracy of diagno-
sis by health experts, as well as consistency of interpretation of imaging tests by using the
computers response as a reference. Large collections of medical imaging have brought
the necessity of using computational techniques to process analyze and retrieve pictorial
information related to them. Therefore, computer-aided diagnosis has been attracting
great interest. The aim of this chapter is to introduce the main concepts related to CAD
systems: kinds of CAD and major areas of activity, techniques of Digital Image Proces-
sing, Pattern Recognition algorithms and practical applications.
Resumo
Sistemas de Diagnstico Auxiliado por Computador (CAD - Computer-aided diagnosis)
so denidos para aprimorar a acurcia do diagnstico realizado por especialistas de
sade, assim como a consistncia da interpretao de exames de imagens, mediante o
uso da resposta do computador como referncia. Grandes colees de imagens mdi-
cas trouxeram consigo a necessidade de utilizar tcnicas computacionais para processar,
analisar e recuperar a informao pictrica relacionada s mesmas. Dessa forma, o
diagnstico auxiliado por computador vem atraindo grande interesse. O objetivo deste
captulo apresentar os principais conceitos ligados aos sistemas CAD: tipos de CAD e
principais reas de atuao, tcnicas de Processamento Digital de Imagens, algoritmos
de Reconhecimento de Padres e aplicaes prticas.
10.1. Introduo
A demanda crescente dos hospitais por um diagnstico de exames baseados em imagens
de forma rpida e precisa, somada aos avanos computacionais e de processamento de
216
imagens, zeram surgir novas frentes de pesquisa relacionadas ao diagnstico mdico au-
xiliado por computador [Marques 2001]. Diagnstico auxiliado por computador, tambm
conhecido pela sigla CAD (Computer-Aided Diagnosis) denido como um diagnstico
realizado pelo especialista, utilizando o resultado de anlises quantitativas automatizadas
de imagens como auxlio para tomada de decises diagnsticas. A nalidade do diagns-
tico auxiliado por computador melhorar a acuidade do diagnstico, assim como a con-
sistncia da interpretao da imagem, mediante o uso da resposta do computador como
referncia. A ideia do CAD pode ser aplicada em todas as modalidades de obteno de
imagem, incluindo a radiograa convencional, tomograa computadorizada, ressonncia
magntica, ultra-sonograa e medicina nuclear.
Podem-se desenvolver sistemas CAD para todos os tipos de exame de todas as
partes do corpo, incluindo, o crnio, trax, abdome, estrutura ssea, sistema vascular e
outros. O objetivo deste captulo apresentar os principais conceitos ligados aos sistemas
CAD: tipos de CAD e principais reas de atuao, tcnicas de Processamento Digital de
Imagens, algoritmos de Reconhecimento de Padres e aplicaes prticas.
10.2. Diagnstico Auxiliado por Computador
Diagnstico auxiliado por computador pode ser denido como um diagnstico feito por
um mdico que utiliza o resultado de anlises quantitativas automatizadas de imagens
como uma segunda opinio para a tomada de decises diagnsticas [Doi 2007]. im-
portante ressaltar que o computador utilizado somente como uma ferramenta para ob-
teno de informao adicional, sendo o diagnstico nal sempre feito pelo especialista,
o que diferencia claramente o conceito bsico de CAD do conceito de diagnstico auto-
matizado, que foi um conceito proposto e estudado nas dcadas de 60 e 70 [Doi 2007].
A nalidade do CAD melhorar a acurcia do diagnstico, assim como a consis-
tncia da interpretao da imagem, mediante o uso da resposta do computador como refe-
rncia. A resposta do computador pode ser til, uma vez que o diagnstico do especialista
baseado em avaliao subjetiva, estando sujeito a variaes intra e interpessoais, bem
como perda de informao devido baixa qualidade da imagem, sobreposio de estru-
turas, fadiga visual ou distrao. Alm disso, foi demonstrado que uma dupla leitura (por
dois especialistas) pode aumentar a sensibilidade do diagnstico[Thurfjell et al. 1994]. A
proposta do CAD funcionar como um segundo especialista.
Basicamente, existem dois tipos de aplicaes de sistemas CAD. Um o auxlio
deteco de leses, a partir da localizao de padres anormais atravs da varredura da
imagem pelo computador (por exemplo, agrupamentos de microcalcicaes em imagens
mamogrcas ou ndulos pulmonares em imagens de trax). O outro o auxlio ao di-
agnstico, atravs da quanticao de caractersticas da imagem e sua classicao como
correspondendo a padres normais ou anormais (por exemplo, a associao da quantidade
e forma das microcalcicaes presentes em um agrupamento com a malignidade ou no
do tumor, ou a associao da textura dos pulmes com leses intersticiais em imagens de
trax).
Em geral, os sistemas CAD utilizam-se de tcnicas provenientes de duas reas
do conhecimento: viso computacional, que envolve o processamento de imagem para
realce, segmentao e extrao de atributos, e inteligncia articial, que inclui mtodos
217
para seleo de atributos e reconhecimento de padres.
10.2.1. Auxlio Deteco
A deteco automatizada de leses envolve a localizao pelo computador de regies con-
tendo padres suspeitos, porm com a classicao da leso sendo feita exclusivamente
pelo especialista. Sistemas para auxlio deteco tm sido desenvolvidos, principal-
mente, para imagens radiolgicas de trax e de mama.
10.2.2. Auxlio ao Diagnstico
Uma vez que um padro suspeito foi detectado, cabe ao especialista decidir o encami-
nhamento do caso, ou seja, se necessria a realizao de algum outro exame ou de uma
bipsia, por exemplo. Ou ento, se um simples acompanhamento suciente e, neste
caso, qual deve ser o intervalo at o prximo exame.
Sistemas de anlise computadorizada esto sendo desenvolvidos para auxiliar a
distino entre leses e no-leses e aumentar a sensibilidade e especicidade do diag-
nstico. Estes sistemas utilizamatributos extrados e quanticados de forma automatizada
e tambm por especialistas.
A vantagem da extrao automatizada a objetividade e reprodutibilidade da me-
dida dos atributos escolhidos. Por outro lado, os especialistas utilizam uma grande quan-
tidade de atributos, os quais so extrados e interpretados simultnea e instantaneamente.
No caso de exames relacionados a cncer, umdos objetivos dos sistemas de auxlio
classicao a reduo do nmero de casos benignos encaminhados para bipsia.
Porm, como o custo da perda de uma leso maligna muito maior que o de uma
classicao errnea de um caso benigno, os sistemas de auxlio ao diagnstico devem
ser desenvolvidos com o propsito de aumentar a especicidade, porm sem reduzir a
sensibilidade.
10.2.3. Estratgias dos Sistemas CAD
Em [Hong Shao 2004] so propostas estratgias para diagnstico de imagens, particular-
mente, aplicados anlise de patologias nos tecidos do crebro (edema, tumor, etc.), tais
como:
1. Anlise comparativa de imagens do mesmo paciente, obtidas pelo mesmo equipa-
mento, com os mesmos parmetros de escaneamento, mas em diferentes instantes
de tempo
2. Anlise comparativa de imagens do mesmo paciente, obtidas pelo mesmo equipa-
mento, no mesmo instante, mas com parmetros de escaneamento diferentes. Este
tipo de anlise denominado anlise multi-espectral.
3. Anlise comparativa de imagens do mesmo paciente, mas obtidas atravs de dife-
rentes tecnologias de escaneamento, tais como, tomograa computadorizada, res-
sonncia magntica, PET e SPECT.
4. Anlise comparativa da imagem do paciente com um padro obtido de pessoas sau-
218
dveis, denominado atlas anatmico. Na prtica, esta tcnica no mostrou muita
ecincia dado sua complexidade e diculdade de estabelecer um padro anat-
mico.
Ainda como tcnica de anlise comparativa, pode-se acrescentar a tcnica de com-
parao de duas imagens do mesmo paciente, mas obtida em diferentes partes do corpo.
Essa a metodologia desenvolvida para deteco de ndulos em mamogramas, por exem-
plo, a qual baseada na simetria de arquitetura entre as mamas esquerda e direita, com as
assimetrias indicando possveis ndulos, conforme descrito em [F.F. et al. 1991].
10.3. Conhecimentos Envolvidos
Em geral, os sistemas CAD utilizam-se de tcnicas provenientes de duas reas do co-
nhecimento, visando a extrao e quanticao de atributos de uma imagem em formato
digital. Neste captulo direcionamos este estudo com base nas seguintes tcnicas:
1. Processamento de Imagens: envolve o processamento de imagem para realce, seg-
mentao e extrao de atributos.
2. Reconhecimento de Padres: inclui mtodos para seleo de atributos, estatstica e
reconhecimento de padres.
Utilizam-se tcnicas de processamento de imagens para realce e segmentao das
leses, conforme o tipo do exame. Por exemplo, utilizam-se propriedades de descontinui-
dade dos nveis de cinza, deteco de contorno, bordas ou segmentao para separao de
regies que apresentem determinada caracterstica. Aps o realce e segmentao, segue
o processamento envolvendo a quanticao de atributos da imagem, como, tamanho,
contraste e forma dos seus objetos constituintes.
Adescrio dos atributos da imagemrelaciona as caractersticas reconhecidas sub-
jetivamente pelos especialistas. De um modo geral, os atributos so quanticados a partir
de propriedades mtricas, topolgicas e de textura dos objetos.
Aps a extrao e quanticao dos atributos, utiliza-se o reconhecimento de
padres para distino entre padres normais e anormais. Esta rea do conhecimento
abrange tcnicas de distribuies de probabilidade de classe, tcnicas de anlise de dis-
criminante, mtodos estatsticos e redes neurais.
10.3.1. Processamento Digital de Imagens
O processamento de imagens abrange uma ampla escala de software, hardware e funda-
mentos tericos [Gonzalez e Woods 2007]. Entre estes fundamentos, discutiremos nesta
seo tcnicas importantes na caracterizao e representao das informaes relevantes
de uma imagem ao usurio de sistema CAD.
Esta subseo descreve algumas funes de processamento digital de imagens
abordadas em sistema CAD. Inicialmente discute-se sobre o processo de aquisio de
imagens. A subseo 10.3.1.2 descreve estratgias para adequar a imagem ao processa-
mento em que ela ser submetida. Tcnicas para separar as regies de interesse de uma
219
imagem so apresentadas na subseo 10.3.1.3. A subseo 10.3.1.4 expe mtodos para
representao e descrio de formas.
10.3.1.1. Aquisio de Imagens
Considera-se aquisio de uma imagem o processo de converso de uma cena real tridi-
mensional em uma imagem digital produzida por um ou vrios sensores. A aquisio de
imagens requer um sensor para imageamento e capacidade de digitalizar o sinal produ-
zido pelo sensor [Burger e Burge 2009]. Este pode ser caracterizado por um dispositivo
fsico que seja sensvel a uma banda do espectro eletromagntico (como raios-X, ultravi-
oleta, visvel ou banda infravermelha), gerando um sinal eltrico proporcional ao nvel de
energia recebida. Por m, converte-se a sada eltrica deste sensor para a forma digital
num outro dispositivo, conhecido como digitalizador [Azevedo et al. 2007]. Dependendo
do tipo do sensor, o resultado pode variar entre uma imagem bidimensional, uma cena
tridimensional ou ainda uma sequncia de imagens.
f (x, y)

f (0, 0) f (0, 1) f (0, M1)

f (1, 0) f (1, 1) f (1, M1)
.
.
.
.
.
.
f (N1, 0) f (N1, 1) f (N1, M1)

(1)
O termo imagem refere-se a uma funo de intensidade luminosa bidimensional,
denotada por f (x, y). O valor ou amplitude de f nas coordenadas espaciais (x, y) d a
intensidade (brilho) da imagem naquele ponto. Para adequar-se a um sistema compu-
tacional, a funo f (x, y) precisa ser digitalizada tanto espacialmente quanto na ampli-
tude. A digitalizao de suas coordenadas espaciais denominada amostragem da ima-
gem e a digitalizao da amplitude chamada quantizao em nveis de cinza. Supondo
que uma imagem contnua f (x, y) aproximada por amostras igualmente espaadas, ar-
ranjadas na forma de uma matriz NxM (Equao (1)) com cada elemento apresentando
uma quantidade discreta. O lado direito desta equao traz a representao de uma ima-
gem digital [Gomes e Velho 1994]. Cada elemento desta matriz denido como um ele-
mento da imagem ou pixel (abreviao do termo picture element, elemento da gura)
[Azevedo et al. 2007]. Os valores dos pixels podem indicar, alm da intensidade da luz,
uma ou vrias faixas de cor (gerando imagens em tons de cinza ou coloridas), mas tam-
bm podem indicar valores fsicos como profundidade e absoro ou reexo das ondas
eletromagnticas.
Considerando a Equao (1) uma aproximao de uma imagem contnua, deve-
se avaliar quantas amostras e nveis de cinza so sucientes para esta aproximao. A
resoluo desta imagem depender destes dois parmetros. Maiores valores nestes ndices
indicam maior aproximao da matriz digitalizada imagem original. Essa relao pode
ser observada na Figura 10.1(b), que se apresenta diferente da Figura 10.1(a), aps ser
reamostrada no plano digital e com uma limitao nos nveis de cinza visveis. Diferentes
equipamentos podem ser utilizados para a aquisio de imagens, como cmeras CCD (do
ingls Charge-Coupled Device, dispositivo de carga acopladade para vdeo e fotograa),
sistema infravermelho, aparelhos para radiologia que utilizam sinais recebidos de raio-X,
220
tomograa computadorizada, medicina nuclear, ultra-sonograa e ressonncia magntica
nuclear.
(a) (b)
Figura 10.1. Efeito da discretizao da imagem: exemplo de (a) imagem contnua
e (b) resultado da amostragem e quantizao da mesma. Adaptado de Gonzalez
& Woods (2007).
Para a realizao de testes em um sistema CAD, possvel processar imagens
armazenadas em repositrios disponveis na web. Alguns destes podem ser abertos e
oferecem a caracterizao das imagens oferecidas. Como exemplo, num sistema CAD
que atue com imagens de mamograa, h bases de dados que disponibilizam as imagens
de mamograa com a indicao de quais destas correspondem a exames de pacientes
doentes ou no.
10.3.1.2. Tcnicas de Pr-Processamento
Emmuitas aplicaes, os mtodos de processamento de imagens requeremajustes na ima-
gem de entrada para extrair suas informaes de maneira satisfatria. Somente aps estes
ajustes, a imagem processada e se torna apta para anlise na aplicao. Essa etapa de
pr-processamento pode ser denida por diversas tcnicas como: remapeamento (para as-
segurar o sistema de coordenadas), reduo de rudos (para assegurar que as informaes
so verdadeiras) e aumento de contraste (para assegurar que as informaes relevantes
sero detectadas), entre outras.
Algumas distores esto presentes em uma imagem e afetam a percepo da real
informao presente na mesma. Uma distoro crtica a presena de rudo na imagem.
Esse fator implica em nova informao na imagem, diferente do seu comportamento real.
Normalmente, os rudos so denidos por uma distribuio estatstica, como o modelo
gaussiano, speckle e de poisson [Marques et al. 2004, Gonzalez e Woods 2007].
Para eliminao do rudo em uma imagem, faz-se necessrio aplicar tcnicas de
realce com processamento por mscara. Isso consiste em denir uma nova imagem, de
dimenso menor do que aquela a ser processada, e aplicar valores a cada um dos elemen-
tos dessa nova imagem que ser chamada de mscara (ou janela). Essa janela percorre
toda a imagem, e faz uma avaliao pixel a pixel de acordo com sua dimenso. A dis-
tribuio de valores nessa mscara dene o tipo de ltragem a ser executada: passa-alta
(preserva as informaes de alta-frequncia, como bordas e rudo, e elimina as demais)
ou passa-baixa (preserva as informaes de baixa-frequncia, como regies homogneas
221
Figura 10.2. Exemplos de ltragem. Ao lado esquerdo esto dispostas imagens
com resultados de tentativa de remoo de rudo com ltro passa-baixa. No lado
direito, um exemplo de deteco de borda com um ltro passa-alta.
em suas intensidades, e elimina o restante). Na Figura 10.2 esto dispostos exemplos de
ltros passa-baixa e passa-alta com suas respectivas mscaras. Cada mscara apresenta
um efeito diferenciado no resultado da ltragem [Paula 2009, Velho et al. 2009].
(a) Imagem original. (b) Fatiamento da imagem em oito
pseudo-cores.
Figura 10.3. Exemplo de realce por uso de fatiamento de intensidades. Adaptado
de Gonzalez & Woods (2007).
Existem ainda outras tcnicas que no realizam um processamento especial como
ocorre na ltragem, mas que permitem ajustar a imagem em seu pr-processamento. Uma
dessas tcnicas o fatiamento de intensidades, que permite criar uma nova codicao de
cores na imagem para melhor interpret-la. Esse mtodo muito utilizado em aplicaes
mdicas e meteorolgicas, em que as intensidades dos pixels so categorizadas em inter-
valos especcos. Cada interstcio de intensidade assume uma cor na nova representao
da imagem. Um exemplo desse processo est na Figura 10.3 que apresenta uma imagem
monocromtica do Fantasma de tireide de Picker [Gonzalez e Woods 2007]. Com o fa-
tiamento de intensidades, a imagem redenida com oito intervalos de intensidades onde
cada regio assume uma pseudo-cor especca.
222
H ainda tcnicas de pr-processamento identicadas com a avaliao da estats-
tica inerente imagem para melhorar a sua aparncia. Um exemplo muito prtico consiste
na equalizao do histograma da imagem. O histograma de uma imagem digital corres-
ponde a uma estimativa da probabilidade de ocorrncia dos seus nveis de cinza. Este
desenvolvimento produz uma imagem cujos nveis de cinza possuem uma densidade uni-
forme. Isso implica num aumento da escala dinmica dos pixels, o que pode acarretar
em um efeito relevante na visualizao da imagem [Gonzalez e Woods 2007]. A Figura
10.4 exibe amostras em condies diferentes de contraste e suas imagens de resultado
aps a equalizao dos seus respectivos histogramas. possvel perceber a mudana no
contraste destas imagens.
10.3.1.3. Segmentao
O processo de segmentao visa separao dos pixels pertencentes a cada objeto pre-
sente na imagem. Isso implica em separao de regies dentro da imagem analisada.
0
1000
2000
3000
4000
5000
6000
0 50 100 150 200 250
0
1000
2000
3000
4000
5000
6000
7000
0 50 100 150 200 250
0
1000
2000
3000
4000
5000
6000
7000
0 50 100 150 200 250
0
500
1000
1500
2000
2500
3000
3500
4000
0 50 100 150 200 250
0
1000
2000
3000
4000
5000
6000
7000
0 50 100 150 200 250
0
1000
2000
3000
4000
5000
6000
7000
0 50 100 150 200 250
0
1000
2000
3000
4000
5000
0 50 100 150 200 250
Figura 10.4. Realce na imagem atravs da equalizao do histograma. Cada co-
luna apresenta quatro diferentes amostras de imagens: escura, clara, com baixo
contraste e com alto contraste. Analisando cada amostra a partir da imagem
de topo at a de base, tem-se: imagem original, histograma, efeito do realce e
histograma equalizado.
223
Exemplos desse processo incluem a seleo de regies de interesse especcos e segmen-
tao de uma ou mais regies que contm um objeto de interesse [Castleman 1996].
A importncia do realce em uma imagem percebida no momento em que o pro-
cesso de segmentao efetuado. Omtodo de segmentao precisa que a imagem tratada
esteja livre de distores para atingir seu objetivo. A tcnica mais simples a limiarizao
(ver Figura 10.5), que consiste em denir um valor de intensidade como limiar e modicar
todos os pixels da imagem com base no mesmo. Isso ocorre a partir de um comparativo,
no qual o pixel com intensidade menor ou igual ao limiar recebe valor 0 (zero). Em caso
contrrio, a intensidade do pixel considerado receber valor igual a 255. Portanto, duas
regies so separadas na imagem.
(a)
0
500
1000
1500
2000
2500
3000
3500
0 50 100 150 200 250
(b) (c) (d)
Figura 10.5. Exemplo de segmentao por limiarizao: (a) imagem original e (b)
seu respectivo histograma. Aplica-se o processo a partir do valor r =125 aplicado
na (c) funo de limiarizao s =T(r) e obtm-se o (d) resultado da segmentao.
Adaptado de Gonzalez & Woods (2007).
10.3.1.4. Representao e Descrio de Formas
Com os agrupamentos obtidos a partir da segmentao da imagem, torna-se possvel re-
presentar e descrever as regies identicadas. Inicialmente, a representao de uma re-
gio pode ser caracterizada como baseada no contorno (fronteira), ou em termos de suas
caractersticas internas (pixels que compem a regio) [Paula et al. 2011]. Os dados da
regio so enm transformados em uma nova representao de acordo com a abordagem
escolhida e depois a mesma regio descrita. Esta descrio consiste em reconhecer ca-
ractersticas da regio da imagem que possam diferenci-la de outras regies ou ainda de
outras imagens. Sendo assim, caractersticas matemticas da imagem so extradas em
vrios nveis de complexidade. Exemplos bsicos incluem deteco de bordas, cantos ou
pixels destacados na imagem [Costa e Cesar 2009].
Normalmente uma representao externa escolhida quando as caractersticas da
forma so importantes. Por outro lado, se a ateno da aplicao est na cor e textura,
utiliza-se a representao interna. De toda maneira, as caractersticas selecionadas para o
descritor da forma devem ser afetadas o mnimo possvel por variaes de mudana de es-
cala, rotao e translao da imagem. A representao da forma geralmente compacta os
dados emesquemas consideravelmente mais teis no clculo de descritores. AFigura 10.6
dispe de duas assinaturas de formas. A primeira uma representao funcional unidi-
224
Figura 10.6. Exemplo de realce por uso de fatiamento de intensidades. Adaptado
de Gonzalez & Woods (2007).
mensional de uma fronteira e pode ser gerada por maneiras distintas [Costa e Cesar 2009].
No exemplo apresentado, tem-se dois grcos da distncia da fronteira ao centride em
funo do ngulo para as formas de crculo e quadrado. Obtm-se assim, uma reduo na
representao da forma a uma funo unidimensional que se apresenta mais simples que
a imagem original.
Tabela 10.1. Exemplo de descrio de regies. Na imagem esquerda, imagem
do mapa da Amrica separada em regies. Proporo de luzes utilizado como
descritor, direita. Adaptado de Gonzalez & Woods (2007).
Para gerar uma descrio de uma regio importante avaliar quais os descritores
que captam as diferenas essenciais entre os objetos ou classes de objetos. Diferentes
informaes da imagem podem ser tratadas como descritores. Exemplos simples so rea
e permetro. A rea de uma regio denida pelo nmero de pixels contidos dentro de
sua fronteira. O permetro o tamanho dessa fronteira. A Tabela 10.1 traz um exemplo de
descrio de uma representao de regio. Utilizaram-se as informaes de intensidade
dos pixels para identicar quantos detalhes de luzes podem ser reconhecidos nas regies
da imagem apresentada (lado esquerdo da tabela). Um descritor foi denido a partir da
contagem de pontos que representam luz em cada regio e foi possvel diferenci-los entre
si.
225
10.3.2. Reconhecimento de Padres
Conforme [Jain et al. 2000], o estudo de reconhecimento de padres teve incio depois da
dcada de 60, quando foi desenvolvida a maior parte da teoria estatstica moderna. Com
o advento dos computadores, cresceu ainda mais a demanda por aplicaes de reconhe-
cimento de padres. Atualmente, o reconhecimento de padres utilizado em aplicaes
envolvendo viso computacional, reconhecimento de caracteres, diagnstico auxiliado
por computador, reconhecimento da fala, reconhecimento de impresso digital, autenti-
cao de assinaturas, etc.
Existem muitos tipos de padres, por exemplo: padres visuais, padres tem-
porais, padres lgicos. Pode-se dizer que tarefas de reconhecimentos de padres so
encontradas em toda atividade inteligente. Deste modo, no h uma s teoria de reconhe-
cimento de padres que seja capaz de cobrir a grande quantidade de problemas possveis.
Porm, existem algumas abordagens clssicas, incluindo: Reconhecimento Estatstico de
Padres, Reconhecimento de Padres usando Lgica Fuzzy, Reconhecimento de Padres
usando Redes Neurais, Reconhecimento Sinttico (ou Estrutural de Padres) e Reconhe-
cimento de Padres Baseado em Conhecimento
A abordagem mais amplamente utilizada a estatstica. Dessa forma, os proble-
mas de reconhecimentos de padres so tratados como problemas de classicao. O que
consiste em associar um conjunto de atributos (caractersticas) de entrada a uma deter-
minada categoria ou classe (sada). Em outras palavras, pode-se dizer que reconhecer
padres equivale a classicar determinado objeto fsico ou situao como pertencente ou
no a um certo nmero de categorias previamente estabelecidas. H dois mtodos de
classicao:
1. Supervisionada: em que uma amostra de dados previamente conhecida, represen-
tada por um conjunto de padres e suas respectivas classes. Neste mtodo, a regra
de deciso pode ser representada por uma funo densidade probabilidade, previa-
mente conhecida (parametrizada) ou no (no parametrizada), ou por uma funo
de classicao.
2. No-Supervisionada: em que no h associao dos padres e suas respectivas clas-
ses. O desao ser encontrar agrupamentos de dados e identicar suas respectivas
classes. Este mtodo tambm conhecido por clustering.
10.3.3. Atributos
Uma forma de classicar um objeto ou evento medindo algumas de suas caractersti-
cas ou algumas de suas propriedades mais representativas (features). Por exemplo, para
classicar uma letra impressa deve ser til conhecer sua rea e permetro.
Aespecicao das caractersticas necessrias para uma boa classicao depende
das caractersticas do problema que se deseja resolver. Especicar esses atributos uma
tarefa rdua que necessita de um elevado grau de experimentao com diferentes combi-
naes de caractersticas.
Com frequncia, um determinado objeto que se deseja classicar representado
por um conjunto xo de d atributos. Neste caso, til pensar no conjunto de atributos
226
como um vetor de atributos x, tambm chamado simplesmente de padro, tal que x um
vetor coluna de dimenso d.
10.3.4. Exemplos de Classicadores
O objetivo de um classicador dividir o espao de atributos em regies de deciso.
Dessa forma, os vetores de atributos que estiverem contidos na mesma regio de deciso
compartilham a mesma classe.
10.3.4.1. Vizinho mais Prximo
O algoritmo de classicao baseado no vizinho mais prximo (Nearest Neighbor - NN)
uma tcnica amplamente empregada para reconhecer padres. O centro de seu funci-
onamento est em descobrir o vizinho mais prximo de uma dada instncia. O NN
considerado um dos mais simples algoritmos de aprendizagem de mquina. Ele funciona
bem quando a distncia entre as mdias grande quando comparada com a disperso de
cada classe em relao a sua mdia. Um resumo do funcionamento do classicador
mostrado no Algoritmo 1.
Algoritmo 1 Algoritmo Vizinho Mais Prximo (Nearest Neighbor, NN).
1 Armazenar os exemplos em uma tabela.
2 Seja x
novo
um vetor cuja classe desconhecida, ou seja:
Classe(x
novo
) =?
3 Procurar na tabela o vetor armazenado mais prximo de x
novo
.
4 Chamar de x
prox
o vetor armazenado mais prximo de x
novo
.
5 Atribuir a x
novo
a mesma classe de x
prox
, ou seja:
Classe(x
novo
) =Classe(x
prox
)
6 Se a classicao for correta incluir x
novo
na tabela.
10.3.4.2. Distncia Mnima aos Centrides (DMC)
O algoritmo Distncia Mnima aos Centrides funciona de forma similar ao do Vizinho
Mais Prximo. No entanto, cada classe passa a ter um nico vetor que a representa,
chamado de centride. Dessa forma, no h necessidade de armazenar todos os exemplos
de uma classe o que nos leva a uma economia de memria. O centride de uma classe
o seu vetor mdio; ou seja, a mdia dos exemplos daquela classe. Assim, pode-se dizer
que o centride de uma classe um modelo que representa aquela classe. Um resumo do
funcionamento do classicador mostrado no Algoritmo 2.
227
Algoritmo 2 Algoritmo Distncia Mnima aos Centrides (DMC).
1 Armazenar apenas os centrides das classes em uma tabela.
2 Seja x
novo
um vetor cuja classe desconhecida, ou seja:
Classe(x
novo
) =?
3 Procurar na tabela o centride mais prximo de x
novo
.
4 Chamar de C
j
o centride mais prximo de x
novo
.
5 Atribuir a x
novo
a mesma classe de centride mais prximo, ou seja:
Classe(x
novo
) =Classe(C
j
)
6 Se a classicao for correta, usar x
novo
para recalcular C
j
.
10.3.4.3. Rede Neural Articial
Uma rede neural articial composta por vrias unidades de processamento, cujo funci-
onamento paralelo e, por vezes, distribudo. Essas unidades, geralmente so conectadas
por canais de comunicao que esto associados a determinado peso, que denominado
peso sinptico. As unidades fazem operaes apenas sobre seus dados locais, que so
entradas recebidas pelas suas conexes. O comportamento inteligente de uma rede neural
articial advm das interaes entre as unidades de processamento da rede. O modelo de
um neurnio articial pode ser visto na Figura 10.3.4.3.
Figura 10.7. Modelo de Neurnio Articial baseado em Haykin (2001).
O comportamento das conexes entre os neurnios simulado por meio de seus
pesos sinpticos. Os valores de tais pesos podem ser negativos ou positivos, dependendo
das conexes serem inibitrias ou excitatrias. O efeito de um sinal proveniente de um
outro neurnio determinado pela multiplicao do valor (intensidade) do sinal recebido
pelo peso da conexo correspondente (x
i
..p
i
). efetuada a soma dos valores x
i
..p
i
de
todas as conexes, e o valor resultante enviado para a funo de ativao, que dene a
sada (y) do neurnio. Combinando diversos neurnios, forma-se uma rede neural arti-
228
cial. De uma forma simplicada, uma rede neural articial pode ser vista como um grafo
onde os ns so os neurnios e as ligaes fazem a funo das sinapses.
A rede neural articial um sistema de neurnios ligados por conexes sinpticas
e dividido em neurnios de entrada, que recebem estmulos do meio externo, neurnios
internos ou hidden (ocultos) e neurnios de sada, que se comunicam com o exterior. A
forma de arranjar perceptrons em camadas denominado Multilayer Perceptron (MLP).
O MLP foi concebido para resolver problemas mais complexos, os quais no poderiam
ser resolvidos pelo modelo de neurnio bsico. Para isto so necessrias mais conexes,
os quais s existem em uma rede de perceptrons dispostos em camadas. Na Camada
escondida, camada oculta ou camada intermediria, como tambm conhecida os neur-
nios so denominados escondidos porque eles no tem acesso direto a sada da rede MLP,
onde os erros de aproximao so calculados.
10.4. Aplicaes
Nesta seo apresentamos duas aplicaes do processamento digital de imagens no diag-
nstico auxiliado por computador. A primeira a identicao de estruturas da retina. A
identicao dessas estruturas auxiliam no diagnsticos de vrias doenas como a retino-
patia diabtica e o edema macular. A segunda envolve o reconhecimento e a anlise de
posturas humanas. Estas aplicaes utilizam imagens obtidas em ambientes clnicos para
o tratamento de desvios posturais.
10.4.1. Identicao de Estruturas da Retina
A retina constitui a membrana mais interna do olho, situando-se na parede posterior.
Quando o olho focaliza uma cena, a imagem correspondente projetada sobre a retina, na
qual esto distribudos dois tipos de receptores de luz: os cones e os bastonetes. Os cones
so so responsveis pela chamada viso fotptica ou de luz clara. J os bastonetes so
teis para detectar detalhes.
Entre os padres presentes no fundo do olho, encontra-se a rede de veias da retina,
que pode revelar uma srie de doenas ligadas s variaes ocorridas no globo ocular. O
tratamento para essas doenas se torna mais ecaz quanto mais cedo elas so descobertas,
e isso se d atravs de exames oftalmolgicos peridicos [Hajer et al. 2006].
Imagens digitais de retina podem prover informaes sobre mudanas patolgicas
causadas por doenas oculares locais e sinais recentes de doenas sistemticas como a
hipertenso, a arterioesclerose e o Diabetes Mellitus (DM). Aanlise e interpretao desse
tipo de imagemvemse tornando umauxlio importante e necessrio no diagnstico dessas
doenas.
10.4.1.1. Disco ptico
Nos sitemas CAD para deteco de doenas oculares usando imagens coloridas de retina,
a localizao automtica do disco ptico (DO) e o clculo do seu contorno so passos
fundamentais, antes de qualquer anlise. A segmentao do disco ptico um passo
importante no pr-processamento de vrios algoritmos desenvolvidos para a extrao au-
229
tomtica das estruturas anatmicas e para a deteco de leses na retina. Alm disso,
esse processo tambm atua como um indicador de patologias oftalmolgicas, como o
glaucoma, que uma das causas mais comuns de cegueira [Xu et al. 2007].
A identicao do disco ptico tambm essencial na localizao dos vasos, os
quais, fornecem uma referncia que pode facilitar o processo da deteco da posio de
outras estruturas do fundo ocular e de leses. Alm disso, essencial a remoo prvia
do disco ptico nos algoritmos de deteco de exudatos
1
, dada a semelhana entre ambos
em termos de cor, brilho e contraste [Gagnon et al. 2001].
Basicamente, podemos classicar os algoritmos de deteco do disco ptico em
duas classes: abordagem geogrca e abordagem baseada em caractersticas locais. Os
algoritmos que usam a abordagem geogrca baseiam-se na informao fornecida pela
estrutura dos vasos, isto , no fato de todos os vasos da retina terem origem no disco p-
tico. Embora a deteco dos vasos seja uma operao complexa, a sua relao geomtrica
com o disco ptico pode ser utilizada para identicar a localizao deste. Uma vez conhe-
cida a localizao do disco ptico, este detectado como ponto inicial para determinar o
respectivo contorno.
Os algoritmos baseados nas caractersticas locais levam em considerao, princi-
palmente, a sua forma redonda e brilho relativamente elevado, quando comparado com o
resto da imagem. Em [Veras et al. 2011] os principais algoritmos de deteco do disco
ptico foram avaliados e o mtodo proposto por [Hoover e Goldbaum 2003].
A Figura 10.8 apresenta trs exemplos de imagens de retina. Na Figura 10.8(a) o
contorno do disco ptico bem denido o que torna mais fcil sua deteco. J na Figura
10.8(b), o plano de fundo bastante heterogneo e a regio central possui intensidade de
cor bem prxima a da regio do disco ptico. A Figura 10.8(c) apresenta uma imagem
onde no possvel a identicao do disco ptico.
(a) (b) (c)
Figura 10.8. Exemplos de imagens da base STARE
10.4.1.2. Mcula
A deteco da mcula uma tarefa relevante no processamento de imagens de fundo
de olho (retina) e utilizada em vrias aplicaes. Ela considerada um importante
1
Produto seroso, purulento, resultante de processo inamatrio.
230
marcador siolgico na anlise de imagens da retina e usada na localizao de outras
estruturas da retina como o DO, microvasos e exsudatos [Winder et al. 2009].
A mcula um ponto ovalado de cor amarela junto ao centro da retina do olho
humano e tem um dimetro de cerca 1,5 mm. A regio da mcula possui uma sub-regio
chamada fvea, que localiza-se no centro da mcula e possui uma rea menor que a m-
cula. nesta ltima que encontramos uma maior quantidade de cones (clulas respon-
sveis pela percepo de cores). A mcula contm uma pigmentao mais escura e sua
localizao aproximadamente o centro da retina. De acordo com [Tobin et al. 2007], o
raio da mcula igual ao dobro do raio do DO e a fvea mede metade do raio do DO.
Uma deteco precisa da mcula um importante primeiro parmetro para de-
terminar patologias como a Degenerao e o Edema Macular. O diagnstico de Edema
Macular, por exemplo, realizado levando-se em considerao a quantidade de exsudatos
e suas localizaes com relao regio da mcula.
O algoritmo de deteco da mcula, na maioria dos trabalhos publicados, deter-
mina uma Regio de Interesse (ROI - Region of Interest) baseado na localizao do DO,
como mostra a Figura 10.9. Aps a determinao da ROI, algoritmos especcos so exe-
cutados para denir o centro da mcula. Uma descrio e avaliao de vrios mtodos de
deteco da mcula pode ser encontrada em [Silva et al. 2011].
Figura 10.9. Ilustrao da ROI.
10.4.1.3. Microaneurismas e Exsudatos
A Retinopatia Diabtica (RD) uma doena assintomtica nas fases iniciais, o que di-
culta a sua deteco. Ela ocorre como resultado das alteraes vasculares na retina
causando inchaos de capilares, conhecidos como microaneurismas (MA). Estes podem
romper-se, e, eventualmente, se tornarem uma fonte de extravasamento de plasma cau-
sando o espessamento da retina, ou edema, se ocorrem na regio macular, e pode causar
perda de viso de alta qualidade [Fleming et al. 2007]. O espessamento da retina no
facilmente visvel nas fotograas do fundo do olho, portanto, regies de depsitos de gor-
dura, conhecidas como exsudatos, so usadas como marcadores. Exsudatos geralmente
formam aglomerados, e podem ser distribudos em toda a retina ou podem aparecer em
um anel em torno de um ponto central do vazamento.
231
A Organizao Mundial de Sade estima que 135 milhes de pessoas tenham
diabetes no mundo e que este nmero de diabticos dever aumentar para 300 milhes at
o ano de 2025 [Amos et al. 1997]. ARDafeta uma parte considervel da populao, o que
justica trabalhos avanados na rea de deteco de doenas por imagens. Desenvolvendo
tcnicas simples, e com um custo-benefcio baixo, seria possvel a deteco da RD em sua
fase inicial. Estudos comprovam que quanto mais cedo for detectada a RD mais chances
o paciente ter de no desenvolver a doena em seu grau mais elevado.
Microaneurismas se apresentam como os primeiros padres patolgicos que sur-
gem na retina humana, em portadores de Retinopatia Diabtica, e constituem uma evi-
dncia direta de isquemia, uma vez que cada microaneurisma representa a ocluso de ao
menos um vaso capilar. Portanto, existe uma relao entre o nmero de microaneurismas
e o agravamento da doena em pacientes portadores do Diabetes Mellitus, ou simples-
mente Diabetes, como popularmente conhecida. Sistemas automticos de deteco de
microaneurismas vm sendo bastante utilizados em substituio aos sistemas manuais de
contagem, uma vez que estes consomem muito tempo e so mais sujeitos a erros. Alguns
dos principais mtodos so [Fleming et al. 2007, Walter et al. 2002, Martins et al. 2008].
Com o avano da Retinopatia Diabtica aparecem os exsudatos. Quando isso
ocorre a doena j se encontra em um nivel grave, mas ainda pode ser controlada. A
Figura 10.10(a) um exemplo de retina saudvel. J na Figura 10.10(b) existe alguns
exsudatos bem pequenos na regio central da retina. A Figura 10.10(c) apresenta vrios
exsudatos e hemorragias.
(a) (b) (c)
Figura 10.10. Exemplos de imagens com e sem exsudatos
Basicamente existem trs tcnicas diferentes de deteco exsudatos em imagens
da retina. A primeira funciona atravs da denio de um limiar como foi observado em
[Kavitha e Shenbaga 2005]. Essa tcnica no possui um bom desempenho, pois como o
disco ptico possui propriedades de cor semelhante a dos exsudatos muitas vezes ele
marcado incorretamente como exsudato. Outro problema dessa tcnica ocorre quando
aparecem regies mais claras na imagem, elas tambm podem ser marcadas como exsu-
datos.
Asegunda tcnica utiliza agrupamento de pixels, como em [Sopharak et al. 2010].
Essa a principal tcnica usada para a deteco dos exsudatos, porm isoladamente ela
no produz resultados satisfatrios, pois muitas vezes necessrio o uso de classicao
ou morfologia matemtica para eliminar falsos candidatos [de Arajo et al. 2011].
A terceira tcnica faz uso de operaes de morfologia matemtica, como foi ob-
232
servado em [Walter et al. 2002]. Assim como no agrupamento, essa tcnica no produz
bons resultados isoladamente. Geralmente ela usada para remover falsos candidatos ou
pixels isolados.
10.4.1.4. Microvasos
Imagens de fundo de olho fornecem informaes sobre as mudanas patolgicas causa-
das por doenas oculares. Uma caracterstica importante para o diagnstico de doenas
como diabetes, arteriosclerose e hipertenso a aparncia dos vasos sanguneos na retina
[Li et al. 2006]. O desenvolvimento de uma soluo computacional para a segmentao
dos vasos sanguneos permite que o mdico especialista diagnostique melhor os casos
de vascularidade anormal. Em outros casos, o desempenho de mtodos automticos de
deteco (segmentao) de vasos auxilia no diagnstico de outras doenas como foi apre-
sentado em [Martins et al. 2009].
Entretanto, essa segmentao dicultada pelos seguintes fatos [Li et al. 2006]:
a largura dos vasos pode variar de muito larga a muito na e o contraste local dos vasos
no estvel. Vrias abordagens para segmentao de vasos so encontradas na literatura
[Zana e Klein 2001, Niemeijer et al. 2004, Soares et al. 2006].
A Figura 10.4.1.4 apresenta um exemplo de imagem de retina e o resultado de
dois mtodos diferentes de segmentao de vasos.
(a) (b) (c)
Figura 10.11. Imagem de retina com duas segmentaes de vasos
10.4.2. Postura
Postura geralmente denida como o arranjo relativo das partes do corpo. Dessa ma-
neira, a postura correta traduz o estado de equilbrio muscular e esqueltico que protege
as estruturas de suporte do corpo contra leso ou deformidade progressiva. Independente
da atitude assumida pelo paciente (agachada, ereta, deitada), estas estruturas esto traba-
lhando ou repousando. Os rgos torcicos e abdominais mantm-se em posies ideais
e os msculos funcionam com mais ecincia sob tais condies. [Furlaneto et al. 2007]
Consequentemente, com a m postura ocorre uma relao defeituosa entre vrias partes
do corpo. Isso produz uma maior tenso sobre estruturas de suporte e onde ocorre um
equilbrio menos eciente do corpo [Ferreira et al. 2011].
233
Entre diversos tratamentos sioteraputicos existentes, a Reeducao Postural Glo-
bal (RPG) um mtodo que atua na dor e no desconforto provocados por alteraes pos-
turais. Diferente das outras abordagens, o tratamento por RPG leva em considerao que
o corpo humano um sistema muscular integrado. Portanto, h a necessidade da obser-
vao de toda a silhueta humana independentemente da localizao do desvio de postura
[Ferreira et al. 2010].
A Figura 10.12 traz a caracterizao da coluna vertebral, que dividida em quatro
curvaturas. Duas delas com a concavidade virada para trs (lordoses nas regies cervi-
cal e lombar) e duas delas com a concavidade virada para a frente (cifoses nas regies
torxica e plvica, ver Figura 10.12(a)). Em geral, as imagens para o diagnstico so to-
madas em vrios planos de observao. Alguns desvios da postura podem ser observados
em imagens do plano frontal do paciente, como a escoliose (Figura 10.12(b)). Imagens
adquiridas em plano sagital provem conhecimento de desvios posturais, tais como hiper-
cifose dorsal, hiperlordose lombar e hiperlordose cervical. Tambm possvel mensurar
a angulao da tbia em relao ao p, exo e extenso dos joelhos e inclinao anterior
e posterior da plvis [Passarinho et al. 2006, Ferreira et al. 2011].
(a) (b)
Figura 10.12. Caracterizao da (a) coluna vertebral e suas regies ou curvatu-
ras (Fonte: Wikipdia). Como exemplo de desvio, a (b) escoliose que pode ser
percebida no plano frontal (Fonte: Wikipdia).
Passarinho e outros autores apresentaram em [Passarinho et al. 2006] uma meto-
dologia utilizada para avaliao de mudanas no equilbrio postural em pacientes subme-
tidos RPG. Este trabalho descreve uma medida de similaridade com o intuito de obter
melhor desempenho na quanticao das alteraes posturais.
O procedimento se inicia com o clculo das assinaturas das formas dos pacientes.
Estas formas so obtidas de segmentaes aplicadas sobre as imagens obtidas pelo sio-
terapeuta. Esta assinatura traz uma nova representao da forma com uma relao entre
a curvatura e a informao de ngulo, em relao ao centride, de cada um dos pontos
234
do contorno da forma. A funo de curvatura descreve a varincia da direo assumida
pelo contorno da forma [Cesar e Costa 1996]. Quanto mais ereta a postura do paciente,
sua funo de curvatura correspondente alcanar menor amplitude. A Figura 10.13(a)
mostra a comparao entre duas assinaturas polares de um mesmo paciente antes e depois
do tratamento. O mtodo descrito em [Passarinho et al. 2006] usa como medida de simi-
laridade o clculo da diferena de reas sob as assinaturas e inversamente proporcional
diferena da rea sob as curvas das assinaturas. Esta medida, SM, calculada atravs da
relao: SM = 1 1

S, em que S a diferena das reas sob as assinaturas polares dos

pers sagitais em estudo.
Este mesmo mtodo avaliou sua medida de similaridade em comparao com a
proposta em [Bernier e Landry 2003] para um conjunto de imagens adquiridas em 22 pa-
cientes. Cada um deles possibilita a aquisio de duas imagens para que sejam obtidas
suas respectivas formas. O objetivo demonstrar que a medida SM mostra-se mais sens-
vel s mudanas da postura do paciente aps o tratamento de RPG. Os resultados podem
ser vistos na Figura 10.13(b). Os valores alcanados para essa medida signicam que o
paciente em questo obteve resposta mais signicativa ao tratamento sioteraputico.
(a) (b)
Figura 10.13. Anlise de similaridade de formas: (a) h a correspondncia das
assinaturas polares de um paciente antes (azul) e aps (vermelho) o RPG; (b)
similaridade para os contornos sagitais de 22 pacientes distintos. Adaptado de
[Passarinho et al. 2006].
Uma aplicao em sioterapia utilizando o Software de Anlise Postural (SAPO)
como um sistema CAD foi proposto em [Ferreira et al. 2011]. Este possui caractersticas
distintas quando comparado com outros softwares disponveis, porque inclui a anlise
de postura global do corpo e a anlise de ngulos e distncias de maneira independente.
Permite o arquivamento e comparao de fotograas para observar a evoluo do paciente
em determinado tratamento. O software tambm permite calibrao e ajustes de foto para
evitar erros de medio pequenos e aumentar a conabilidade do mtodo.
Ferreira e outros autores, com o auxlio deste software citado, realizaram uma
avaliao quantitativa global do alinhamento postural de adultos jovens e saudveis em
p, com base em pontos de vista anterior, posterior e lateral. O trabalho envolveu 122
participantes que foram submetidos a uma anlise de agrupamento pela similaridade das
variveis do estudo. O sistema indica a marcao de 50 pontos anatmicos distribudos
entre as vises anterior, laterais e posterior, como o lbulo da orelha, a linha de juno
235
do joelho, calcneo, ngulo inferior da escpula, entre outros. Destes total, 16 deles
eram bilaterais [Ferreira et al. 2010]. Alguns destes pontos esto visveis na Figura 10.14.
Este estudo e o software esto disponveis em http://sapo.incubadora.fapesp.br, e inclui
tutoriais cientcos, bem como vrios recursos de apoio anlise de fotograas.
Figura 10.14. Pontos anatmicos e ngulos avaliados nas vises laterais. Adap-
tado de [Ferreira et al. 2011].
Os dados foram submetidos anlise estatstica descritiva. Valores quantitativos
para a cabea, membros superiores e inferiores, e alinhamento do tronco foram obtidos,
juntamente com a freqncia das inclinaes para a esquerda e direita. As medidas utili-
zadas para anlise da postura incluiram distncias (em centmetros) e ngulos (em graus),
extrados da combinao de pontos anatmicos descritos em [Ferreira et al. 2011]. As va-
riveis da avaliao postural foram analisadas atravs da mdia, desvio padro e valores
de mximo e mnimo.
Vrios valores de referncia padro de referncia foram denidos neste estudo
para avaliar o alinhamento postural. Membros inferiores mostraram alinhamento similar.
A posio da cabea, tronco e membros superiores e inferiores em vistas laterais so
apresentados na Tabela 10.2. Medidas envolvendo o quadril, tornozelo, cifose, lordose e
mostrou maior variabilidade. Existem pequenas variaes no alinhamento dos segmentos
corporais nas vises anterior e posterior em indivduos saudveis.
Os resultados do estudo demonstraram uma tendncia de assimetria entre os seg-
mentos bilaterais na viso anterior, com a plvis, ombros e tronco mostrando ligeira incli-
nao para a direita. Na viso posterior, uma pequena assimetria foi observada no posi-
cionamento da plvis e escpula. Maiores detalhes, como identicao dos outros pontos
anatmicos e o resultado detalhado da anlise das variveis da postura esto descritos em
[Ferreira et al. 2011].
236
Tabela 10.2. Valores de mdia (desvio padro), mnimo e mximo para as vari-
veis de postura observadas nas vises laterais, medidas em ngulos. Adaptado
de [Ferreira et al. 2011].
Variveis (

) Mdia (desvio padro) Mnimo Mximo

Alinhamento horizontal da cabea 47,1 (4,8) 31,2 58,4
Alinhamento horizontal da plvis 172,6 (4,8) 158,6 182,4
Alinhamento sagital do membro inferior 177,9 (4,8) 166,7 190,6
ngulo de juno do quadril 149,8 (8,0) 129,7 176,2
ngulo de juno do malolo 86,2 (2,6) 79,9 91,6
Alinhamento vertical do torso 182,4 (2,1) 177,6 187,0
Alinhamento vertical do corpo 178,2 (0,9) 175,8 180,0
Alinhamento do membro superior 155,8 (5,1) 145,7 170,7
Alinhamento sagital do corpo 186,8 (3,6) 176,4 198,5
ngulo da cifose torcica 55,4 (7,4) 39,3 68,2
ngulo da lordose lombar 47,7 (15,4) 23,3 96,4
10.5. Concluso
Estre trabalho apresentou, com base em publicaes cientcas, que a utilizao de algo-
ritmos computacionais para auxlio anlise de imagens mdicas tem-se mostrado eci-
ente na melhoria da deteco e classicao de leses e/ou patologias humanas. Existem
aplicaes em diferentes especialidades e todas com resultados ecientes para distintas
anlises clnicas.
importante ressaltar que o objetivo de um sistema CAD est na realizao de
uma anlise automatizada como forma de auxlio, e no um substituto para o especialista
da rea da sade. Portanto, exigido que toda aplicao dessa natureza apresente um
desempenho prximo ao desse especialista. O acompanhamento deste ltimo ao processo
de desenvolvimento do sistema CAD um fator que incrementa conana e ecincia aos
resultados da aplicao.
Referncias
[Amos et al. 1997] Amos, A. F., MacCarty, D. J., e Zimmet, P. (1997). The rising global
burden of diabetes and its complications: Estimates and projections to the year 2010.
Diabetc Medicine, 14:S1S85.
[Azevedo et al. 2007] Azevedo, E., Conci, A., e Leta, F. R. (2007). Computao Grca:
Processamento de Imagens Digitais, volume 2. Editora Campus.
[Bernier e Landry 2003] Bernier, T. e Landry, J.-A. (2003). A new method for represen-
ting and matching shapes of natural objects. Pattern Recognition, 36(8):17111723.
[Burger e Burge 2009] Burger, W. e Burge, M. J. (2009). Principles of Digital Image
Processing: Fundamental Techniques. Springer.
[Castleman 1996] Castleman, K. R. (1996). Digital Image Processing. Prentice Hall,
Upper Saddle River.
237
[Cesar e Costa 1996] Cesar, R. M. J. e Costa, L. F. (1996). Towards effective planar shape
representation with multiscale digital curvature analysis based on signal processing
techniques. Pattern Recognition, 28(9):15591569.
[Costa e Cesar 2009] Costa, L. F. e Cesar, R. M. J. (2009). Shape Analysis and Classi-
cation: Theory and Practice. CRC Press, 2
a
edio.
[de Arajo et al. 2011] de Arajo, F., Veras, R., e Silva, R. (2011). Aperfeioamento da
deteco de exsudatos comk-means fuzzy, deteco de vasos e morfologia matemtica.
In V Escola Regional de Computao dos Estados do Cear, Maranho e Piau.
[Doi 2007] Doi, K. (2007). Computer-aided diagnosis in medical imaging: Histori-
cal review, current status and future potential. Computerized Medical Imaging and
Graphics, 31:198211.
[Ferreira et al. 2011] Ferreira, E. A., Duarte, M., Maldonado, E. P., Bersanetti, A. A., e
Marques, A. P. (2011). Quantitative assessment of postural alignment in young adults
based on photographs of anterior, posterior, and lateral views. Journal of Manipulative
and Physiological Therapeutics, 34(6):371380.
[Ferreira et al. 2010] Ferreira, E. A. G., Duarte, M., Maldonado, E. P., Burke, T. N., e
Marques, A. P. (2010). Postural assessment software (PAS/SAPO): Validation and
reliabiliy. Clinics, 65:675681.
[F.F. et al. 1991] F.F., Y., M.L., G., K., D., C.E., M., C.J., V., e R.A., S. (1991). Com-
puterized detection of masses in digital mammograms: analysis of bilateralsubtraction
images. Med Phys, pginas 5563.
[Fleming et al. 2007] Fleming, A. D., Goatman, K. A., Philip, S., Olson, J. A., e Sharp,
P. F. (2007). Automatic detection of retinal anatomy to assist diabetic retinopathy
screening. Physics in Medicine and Biology, 52(2):331345.
[Furlaneto et al. 2007] Furlaneto, T. S., Candotti, C. T., e Loss, J. F. (2007). Desenvolvi-
mento de uma metodologia digital para avaliao postural no plano sagital. In Anais
do XII Congresso Brasileiro de Biomecnica, So Pedro - SP.
[Gagnon et al. 2001] Gagnon, L., Lalonde, M., Beaulieu, M., e Boucher, M. C. (2001).
Procedure to detect anatomical structures in optical fundus images. In Proceedings of
Conference Medical Imaging, volume 4322, pginas 12181225, San Diego.
[Gomes e Velho 1994] Gomes, J. e Velho, L. (1994). Computao Grca: Imagem.
IMPA.
[Gonzalez e Woods 2007] Gonzalez, R. C. e Woods, R. E. (2007). Digital Image Proces-
sing. Prentice Hall, Nova York, EUA, 3
a
edio.
[Hajer et al. 2006] Hajer, J., Kamel, H., e Noureddine, E. (2006). Blood vessels seg-
mentation in retina image using mathematical morphology and the STFT analysis.
Information and Communications Technologies, 1:11301134.
238
[Hong Shao 2004] Hong Shao, Wen-Cheng Cui, H. Z. (2004). Automatic analysis of
brain pathology based on image content. In IEEE International Conference on Systems.
[Hoover e Goldbaum 2003] Hoover, A. e Goldbaum, M. (2003). Locating the optic nerve
in a retinal image using the fuzzy convergence of the blood vessels. IEEE Transactions
on Medical Imaging, 22(8):951958.
[Jain et al. 2000] Jain, A. K., Duin, R. P., e Mao, J. (2000). Statistical pattern recognition:
A review. IEEE Transactions on Pattern Analysis and Machine Intelligence, 22(1):4
37.
[Kavitha e Shenbaga 2005] Kavitha, D. e Shenbaga, S. (2005). A cellular neurofuzzy
network for contrast enhancement of fundus images with retinopathies. In Proceeding
ICS06 Proceedings of the 10th WSEAS international conference on Systems.
[Li et al. 2006] Li, Q., Zhang, L., Zhang, D., e Bhattacharya, P. (2006). A new approach
to automated retinal vessel segmentation using multiscale analysis. In ICPR, pginas
7788. IEEE Computer Society.
[Marques 2001] Marques, P. (2001). Diagnstico auxiliado por computador na radiolo-
gia. Radiol Bras, 34(5):285293.
[Marques et al. 2004] Marques, R., Carvalho, E., Costa, R., e Medeiros, F. (2004).
Filtering effects on sar images segmentation. Lecture Notes in Computer Science,
3124:10411046.
[Martins et al. 2008] Martins, C., R.M.S.Veras, G.L.B.Ramalho, F.N.S.Medeiros, e
Ushizima, D. M. (2008). Automatic microaneurysm detection and characterization
through digital color fundus images. In II Workshop on Computational Intelligence -
SBRN, pginas 4550.
[Martins et al. 2009] Martins, C. I. O., Medeiros, F. N. S., e ans F. N. Bezerra ans R. M.
Cesar Jr., R. M. S. V. (2009). Evaluation of retinal vessel segmentation methods for
microaneurisms detection. In International Conference on Image Processing (ICIP),
pginas 33653368.
[Niemeijer et al. 2004] Niemeijer, M., Staal, J. J., van Ginneken, B., Loog, M., e Abr-
moff, M. D. (2004). Comparative study of retinal vessel segmentation methods on
a new publicly available database. In Fitzpatrick, J. M. e Sonka, M., editors, SPIE
Medical Imaging, volume 5370, pginas 648656.
[Passarinho et al. 2006] Passarinho, C. J. P., Cintra, L. H. S., Medeiros, F. N. S., Oli-
veira, I. N. S., e Paula, I. C. J. (2006). Anlise de similaridade e correspondncia de
formas aplicada reeducao postural global. In Anais do XX Congresso Brasileiro de
Engenharia Biomdica, pginas 117120, So Pedro - SP.
[Paula 2009] Paula, I. C. J. (2009). Livro Texto dos Minicursos - Ercemapi 2009, captulo
Tcnicas de Processamento Digital de Imagens com Java. SBC, Parnaba - PI.
239
[Paula et al. 2011] Paula, I. C. J., Medeiros, F. N. S., Bezerra, F. N., e Ushizima, D. M.
(2011). Corner detection within a multiscale framework. In Proceedings of Sibgrapi
2011 (XXIV Conference on Graphics, Patterns and Images), Macei - AL. IEEE.
[Silva et al. 2011] Silva, R., Veras, R., e de Arajo, F. (2011). Avaliao de mtodos para
deteco da mcula em imagens da retina. In V Escola Regional de Computao dos
Estados do Cear, Maranho e Piau.
[Soares et al. 2006] Soares, J. V. B., Leandro, J. J. G., Cesar-Jr., R. M., Jelinek, H. F.,
e Cree, M. J. (2006). Retinal vessel segmentation using the 2-D Gabor wavelet and
supervised classication. IEEE Transactions on Medical Imaging, 25:12141222.
[Sopharak et al. 2010] Sopharak, A., Dailey, N., Uyyanonvara, B., Barman, S., William-
son, T., New, T. N., e Moe, A. Y. (2010). Machine learning approach to automatic
exudate detection in retinal images from diabetic patients. Journal of Modern Optics,
(57):124135.
[Thurfjell et al. 1994] Thurfjell, E. L., Lernevall, K. A., e Taube, A. A. (1994). Benet of
independent double reading in a population-based mammography screening program.
Radiology, 191:241244.
[Tobin et al. 2007] Tobin, K. W., Chaum, E., Govindasamy, V. P., e Karnowski, T. P.
(2007). Detection of anatomic structures in human retinal imagery. IEEE Transactions
on Medical Imaging, 26(16):172939.
[Velho et al. 2009] Velho, L., Frery, A., e Gomes, J. (2009). Image Processing for Com-
puter Graphics and Vision. Springer, 2
a
edio.
[Veras et al. 2011] Veras, R., Arajo, F., Silva, R., Medeiros, F., e Aires, K. (2011). om-
parao e avaliao de mtodos de deteco do disco ptico. In XXXVII Conferencia
Latinoamericana de Informtica.
[Walter et al. 2002] Walter, T., Klevin, J., Massin, P., e Erginay, A. (2002). Acontribution
of image processing to the diagnosis of diabetic retinopathy-detection of exudates in
color fundus images of the human retina. IEEE Transactions on Medical Imaging,
21(10):1236 1243.
[Winder et al. 2009] Winder, R., Morrow, P., McRitchie, I., Bailie, J., e Hart, P. (2009).
Algorithms for digital image processing in diabetic retinopathy. Computerized Medical
Imaging and Graphics, page 15.
[Xu et al. 2007] Xu, J., Chutatape, O., e Chew, P. (2007). Automated optic disk boun-
dary detection by modied active contour model. IEEE Transactions on Biomedical
Engineering, 54(3):473482.
[Zana e Klein 2001] Zana, F. e Klein, J. C. (2001). Segmentation of vessel-like pat-
terns using mathematical morphology and curvature evaluation. IEEE Transactions on
Image Processing, 10:10101019.
240