RENATO LENZ COSTA LIMA - UNIVERSIDADE ESTADUAL ......RENATO LENZ COSTA LIMA Um ambiente inteligente para desenvolvimento hipermídia/web interativo nas nuvens Dissertação de mestrado

UNIVERSIDADE ESTADUAL DO CEARÁ

DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO

CURSO DE MESTRADO ACADÊMICO EM CIÊNCIA DA COMPUTAÇÃO

RENATO LENZ COSTA LIMA

UM AMBIENTE INTELIGENTE PARA DESENVOLVIMENTO HIPERMÍDIA/WEB

INTERATIVO NAS NUVENS

FORTALEZA

2009

RENATO LENZ COSTA LIMA

Um ambiente inteligente para desenvolvimento hipermídia/web interativo nas nuvens

Dissertação de mestrado submetida à Coor-

denação do Curso de Mestrado Acadêmico

em Ciência da Computação, da Universidade

Estadual do Ceará, como parte dos requisitos

exigidos para obtenção do grau de Mestre em

Ciência da Computação.

Orientador: Prof. Dr. Gustavo Augusto Lima de

Campos

Co-Orientador: Prof. Dr. Cidcley Teixeira de

Souza

FORTALEZA

2009

Aos meus pais,

Rubens e Paula,

porque me fizeram o que sou.

i

ii

Agradecimentos

Primeiramente, Àquele que lutou todas as nossas guerras e possibilitou este trabalho: Deus.

Aos meus orientadores, os professores doutores Cidcley e Gustavo, que me guiaram e

apoiaram durante o desenvolvimento do trabalho. Agradeço principalmente pela confiança e

liberdade que me deram para criar novas idéias e depois pela paciência e ajuda para que en-

tendêssemos, eu e eles, essas idéias inicialmente tão “nebulosas”. Aos membros da banca - os

professores doutores Jerffeson, com quem aprendi a ouvir críticas, e Milton - cujas sugestões

contribuíram para a melhoria deste trabalho.

Ao Emmanuel por participar da idealização do ambiente DIS após um encontro casual no

Dragão do Mar. Aos amigos Amauri e Robson que estavam sempre presentes para ajudar, em-

prestar o computador, discutir idéias e lembrar deadlines. Ao meu primo Ricardo por, além

de diversas sugestões, cunhar a frase que se torna lema de nossa aplicação web para difusão

de conhecimento, o site “Encontro de estudantes”, e ao Breno por colaborar em seu desen-

volvimento. Aos amigos conquistados na PC4 (Adriano, Camila, Cauê, Erika, Felipe, João,

Maurício, Renata e Yuri) que tiveram a paciência e o interesse de discutir algumas das idéias

que deram origem a este trabalho em pleno churrasco. Aos amigos conquistados durante o curso

de mestrado: Alex, Carlos Cidade, Daladier, Fabiano, Gilzamir, Marcelo, Márcia, Mário, Tar-

ciane, Vigno, Viviane e Wallison, sempre dispostos a ajudar em qualquer problema, começando

pelo café. “Queres um cafezinho, Renato?”, “Hoje não. Obrigado, Fabiano!”.

À Karla por seu enorme companheirismo e incentivo, sem a qual eu não seria capaz de

terminar este trabalho. A todos os amigos que não se interessam pelo conteúdo deste trabalho,

mas foram importantes nos momentos de lazer, essenciais para tornar as horas de trabalho mais

produtivas. Para citar alguns: Bárbara, Bruno, Eduardo, Lemi, Levi, Júlio, Ian, Maira, Maryllin,

Melânia, Natália e Virgínia. Aos meus pai, Rubens e Paula, por suas valiosas revisões, pela

atenção, por todo o suporte fisíco e emocional e por tudo que sempre me ensinaram, de raiz

quadrada a diferentes formas de ver o mundo. Enfim, por a vida ser boa.

Finalmente, à FUNCAP (Fundação Cearense de Apoio ao Desenvolvimento Científico e

Tecnológico) pelo suporte financeiro e à UECE (Universidade Estadual do Ceará) por disponi-

bilizar e me acolher neste curso de mestrado.

iii

Resumo

O desenvolvimento hipermídia/web apresenta diversas dificuldades. Ao longo dos anos,

surgiram várias funcionalidades para auxiliar o processo de desenvolvimento, que, de uma

forma ou de outra, são tentantivas de diminuir a distância entre a edição da aplicação e a vi-

sualização de seu resultado, seja através de uma pré-visualização, seja através da automação e

agilização de etapas. Entretanto, nos ambientes disponíveis, a visualização do resultado ainda

requer um número insatisfatório de etapas.

Com o desafio de encontrar novas funcionalidades para diminuir ainda mais a distância en-

tre a edição de documentos hipermídia/web e a visualização do resultado, este trabalho propõe

a abordagem de desenvolvimento interativo DIA, que, assim como a Web 2.0, ao invés de

uma tecnologia nova, é uma nova forma de usar as tecnologias antigas. Procurando por um

modelo de representação de documentos hipermídia de forma distribuída, o modelo Nós foi

idealizado, sugerindo o armazenamento de informações em um cérebro baseado em símbolos

e nós. Obtido sucesso na descrição de documentos de texto e informações genéricas, propôs-

se o modelo cognitivo MAU, baseado no modelo Nós, para escolha de ações de um agente

reativo com aprendizado, denominado AgenteNós. Sua implementação JavaScript, chamada

de agente virtual, na prática, é um objeto JavaScript extensível, instanciado em uma página

web por um browser, que vence as limitações de acesso a memórias persistentes do JavaScript

através de requisições HTTP assíncronas para o webservice Lumen, uma solução nas nuvens

para armazenamento de informações genéricas. A uma instância de agente virtual, batizada de

ce, foram ensinadas funcionalidades para criar uma interface gráfica para usuário dinâmica que,

apoiada pelo webservice Lumen, compõe DIS, um ambiente inteligente para desenvolvimento

hipermídia/web interativo nas nuvens.

Palavras-chave: Desenvolvimento hipermídia/web, Computação nas nuvens, Inteligência

artificial, Representação do conhecimento.

iv

Abstract

The hypermedia/web development has several difficulties. Over the years, several function-

alities emerged to support the development process, that, in one way or another, are attempts to

decrease the distance between the edition of the application and the visualization of its result, by

offering a preview or through automatization of steps. However, in the available environments,

the visualization of results demands an insatisfatory number of steps.

With the challenge of finding new functionalities to decrease even further the distance be-

tween the edition of hypermedia/web documents and the visualization of its result, this thesis

introduces DIA, a script-based interactive approach to hypermedia/web development, which,

like Web 2.0, rather than a new technology, is a new way of using the same old technologies.

Looking for a model to represent hypermedia documents in a distributed way, the Nós model

was idealized, suggesting the storage of information in a brain based on symbols and ties,

which represent any type of association between symbols. Succeeding in the description of text

documents and generic-information storage, this thesis proposes the cognitive model MAU,

based on the Nós model, to choose the actions of a learning reactive agent, called AgenteNós.

Their JavaScript implementations, called virtual agents, are, in practice, JavaScript extensible

objects, created inside a web page by a browser, that overcome JavaScript limitations of persis-

tent memory access through asynchronous HTTP requests to the webservice Lumen, a solution

for generic-information storage in the clouds. Basic functionalities were taught to an instance

of the virtual agent class, called ce, in order to create a dynamic graphical user interface that,

supported by the webservice Lumen, composes DIS, an inteligent environment for interactive

hypermedia/web development in the clouds.

Keywords: Hypermedia/Web development, Cloud computing, Artificial inteligence, Knowl-

edge representation.

v

Lista de Figuras

2.1 Arquitetura de um agente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2 Arquitetura de um agente reativo simples. . . . . . . . . . . . . . . . . . . . . 18

2.3 Arquitetura de um agente reativo simples com aprendizado. . . . . . . . . . . . 18

3.1 Assistente de criação do Caspio Bridge. . . . . . . . . . . . . . . . . . . . . . 21

3.2 Formulário construído pelo assistente de criação do Caspio Bridge. . . . . . . . 22

3.3 Tela de edição do Google Sites. . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.4 Tela de visualização do Google Sites, após persistência. . . . . . . . . . . . . . 23

3.5 Visualização do código e WYSIWYG no Adobe Dreamweaver. . . . . . . . . . 24

3.6 Página inicial do Aptana Studio. . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.7 Edição no Aptana Studio feita a partir do código com complementação e destaque

de código. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1 Visualização rápida do resultado com a abordagem DIA. . . . . . . . . . . . . 32

4.2 Teste do componente através da interface gráfica com a abordagem DIA. . . . . 33

4.3 Novo teste da aplicação com a abordagem DIA: apenas um segundo clique. . . 33

5.1 Diagrama de classes do modelo Nós. . . . . . . . . . . . . . . . . . . . . . . . 38

5.2 Diagrama de estados de um AgenteNós. . . . . . . . . . . . . . . . . . . . . . 44

6.1 DIS - Desenvolvimento Inteligente de Sistemas. . . . . . . . . . . . . . . . . . 51

6.2 Diagrama de classes do ambiente DIS. . . . . . . . . . . . . . . . . . . . . . . 52

6.3 Diagrama de estados de um agente virtual. . . . . . . . . . . . . . . . . . . . . 54

7.1 Mostrando o primeiro símbolo ao agente virtual ce. . . . . . . . . . . . . . . . 59

7.2 Ensinando uma regra ao agente virtual ce. . . . . . . . . . . . . . . . . . . . . 60

7.3 Novos símbolos, novas regras. . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Lista de Figuras vi

7.4 Interface inicial do ambiente DIS. . . . . . . . . . . . . . . . . . . . . . . . . 61

7.5 Título do site “Encontro de estudantes” visível após a execução do comando de

sua criação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

7.6 Protótipo funcionando com componentes de teste. . . . . . . . . . . . . . . . . 63

7.7 Agentes virtuais podem aprender novas funcionalidades a qualquer momento. . 64

7.8 Teste dos componentes através do protótipo da interface gráfica. . . . . . . . . 65

7.9 Refinando o leiuate através de documentos CSS. . . . . . . . . . . . . . . . . . 65

7.10 Primeira versão do site “Encontro de estudantes”. . . . . . . . . . . . . . . . . 66

vii

Lista de Tabelas

1.1 Dificuldades do desenvolvimento hipermídia . . . . . . . . . . . . . . . . . . . 3

1.2 Dificuldades específicas do desenvolvimento web . . . . . . . . . . . . . . . . 4

2.1 Definições de inteligência artificial . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1 Requisitos de HADMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.1 Comparação entre as etapas da abordagem “Editar-salvar-atualizar” e DIA . . . 28

4.2 Comparação entre as etapas da abordagem script e DIA . . . . . . . . . . . . . 29

viii

Lista de Siglas

AHM Amsterdam hypermedia model

AJAX Asynchronous Javascript and XML

API Application programming interface

ASDF AJAX sem dor, fácil!

ASP Active server pages

CORBA Common object request broker architecture

CSS Cascading style sheets

DIA Desenvolvimento interativo de aplicações

DIS Desenvolvimento inteligente de sistemas

DOM Document object model

FTP File transfer protocol

HADMS Hypermedia application development and management system

HTML Hypertext markup language

HTTP Hypertext transfer protocol

IA Inteligência artificial

IDE Integrated development environment

JSP Java server pages

MAU Modelo automático de utilização de um cérebro

MVC Model-view-controller

NCL Nested context language

NCM Nested context model

OOHDM Object-oriented hypermedia design model

PHP PHP hypertext preprocessor

SBTVD Sistema brasileiro de TV digital

SMIL Synchronized multimedia integration language

TAD Tipo abstrato de dados

W3C World wide web consortium

WYSIWYG What you see is what you get

XML Extensible markup language

ix

Sumário

Resumo iii

Abstract iv

Lista de Figuras vi

Lista de Tabelas vii

Lista de Siglas viii

1 Introdução 1

1.1 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.1.1 Objetivos específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3 Estrutura da dissertação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Referencial teórico 7

2.1 Evolução do conteúdo da Internet . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Desenvolvimento Hipermídia . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3 Desenvolvimento Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4 Desenvolvimento baseado em script . . . . . . . . . . . . . . . . . . . . . . . 12

2.5 Inteligência Artificial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.5.1 Agindo como humano: a abordagem do teste de Turing . . . . . . . . . 14

2.5.2 Pensando como humano: a abordagem de modelo cognitivo . . . . . . 15

Sumário x

2.5.3 Pensando racionalmente: a abordagem das “leis do pensamento” . . . . 16

2.5.4 Agindo racionalmente: a abordagem do agente racional . . . . . . . . . 17

2.6 Resumo do capítulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Trabalhos relacionados 20

3.1 Caspio Bridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2 Google Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.3 Adobe Dreamweaver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.4 Aptana Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24


4 DIA - Desenvolvimento Interativo de Aplicações 27

4.1 Passos da abordagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.2 Descrição de aplicações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.3 Utilização da abordagem DIA . . . . . . . . . . . . . . . . . . . . . . . . . . 32


5 Modelo de representação de conhecimento: Nós 35

5.1 Conceitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.1.1 Símbolo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.1.2 Nó . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.1.3 Cérebro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.1.4 Interpretador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.2 Utilização do modelo Nós . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.2.1 Descrição de TADs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.2.2 Descrição de documentos e mídias . . . . . . . . . . . . . . . . . . . . 41

5.3 MAU e AgenteNós . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.4 Considerações finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Sumário xi

5.4.1 Sobre o modelo Nós . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.4.2 Sobre racionalidade e aprendizado . . . . . . . . . . . . . . . . . . . . 46

6 DIS - Desenvolvimento Inteligente de Sistemas 47

6.1 Requisitos obrigatórios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6.1.1 Suporte à abordagem DIA . . . . . . . . . . . . . . . . . . . . . . . . 47

6.1.2 Manutenabilidade e extensibilidade dinâmicas . . . . . . . . . . . . . 48

6.1.3 Aplicação como serviço . . . . . . . . . . . . . . . . . . . . . . . . . 48

6.2 Requisitos Desejáveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6.2.1 Suporte ao desenvolvimento de componentes . . . . . . . . . . . . . . 48

6.2.2 Complementação e destaque de código . . . . . . . . . . . . . . . . . 48

6.2.3 Visualização WYSIWYG . . . . . . . . . . . . . . . . . . . . . . . . . 49

6.2.4 Desenvolvimento colaborativo com controle de versões . . . . . . . . . 49

6.2.5 Gerenciamento do espaço nas nuvens . . . . . . . . . . . . . . . . . . 49

6.2.6 Suporte a sincronismo temporal de mídias . . . . . . . . . . . . . . . . 49

6.2.7 Suporte a etapas de conceitualização e modelagem . . . . . . . . . . . 49

6.3 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

6.4 Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

6.4.1 Lumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.4.2 Asdf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.4.3 Agentes virtuais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6.5 Considerações finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

7 Estudo de caso - Encontro de estudantes 56

7.1 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

7.1.1 Requisitos obrigatórios . . . . . . . . . . . . . . . . . . . . . . . . . . 56

7.1.2 Requisitos desejáveis . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Sumário xii

7.2 Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

7.2.1 Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

7.2.2 Visualização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

7.2.3 Controle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

7.3 Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

7.3.1 Instanciando ce pela primeira vez . . . . . . . . . . . . . . . . . . . . 58

7.3.2 Construindo protótipo da interface . . . . . . . . . . . . . . . . . . . . 61

7.3.3 Implementando componentes . . . . . . . . . . . . . . . . . . . . . . 64

7.3.4 Refinando o leiaute . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

7.3.5 Persistindo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66


8 Conclusões e trabalhos futuros 68

Referências Bibliográficas 71

Apêndice A -- Pensamentos 76

A.1 Nós (20/02/2006) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

A.2 Dar nome aos bois (09/11/2005) . . . . . . . . . . . . . . . . . . . . . . . . . 79

Apêndice B -- Implementação de TADs utilizando Cérebro 81

B.1 Fila . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

B.2 Lista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

1

1 Introdução

Mídias são ferramentas que nos permitem expressar idéias em forma de textos, imagens,

vídeos, áudios, apresentações, softwares, entre outras. Cada uma delas envolve um tipo dife-

rente de dificuldade em seu desenvolvimento. Enquanto editores de texto precisam, de alguma

forma, capturar as palavras que se quer, editores de vídeos precisam capturar imagens ao longo

do tempo. Dessa forma, diversas ferramentas têm sido desenvolvidas para auxiliar a construção

de cada mídia específica. Por exemplo, existem editores de texto que lêem símbolos emitidos

pelo teclado e outros que utilizam microfone e reconhecedor de voz para capturar o texto.

Cada mídia por si só é capaz de expressar idéias, porém, percebeu-se a oportunidade de

combinar a capacidade de expressão dos diversos tipos de mídia para a construção de uma mí-

dia composta, chamada multimídia (STEWART; KOWALTZKE, 1997). Nesse caso, além das

dificuldades envolvidas para a construção de cada mídia individualmente, também aparecem

novas dificuldades específicas para conseguir unir os diferentes tipos de mídias em um único

documento. Um dos grandes problemas é estabelecer como as mídias compartilham o espaço

e o tempo da apresentação. Duas funcionalidades são de grande ajuda para resolver esse pro-

blema de sincronismo espacial e temporal: a pré-visualização WYSIWYG (“What You See Is

What You Get”1), onde é possível posicionar os elementos no espaço através de uma interface

gráfica com recursos do tipo “arrastar e soltar”; e o timeline, onde os elementos são descritos

como blocos de tamanho proporcional ao espaço que a mídia ocupa na dimensão do tempo,

sendo possível posicioná-los ao longo de uma linha do tempo que indica o tempo da apresen-

tação. Uma terceira funcionalidade, apresentada, por exemplo, no editor multimídia Windows

MovieMaker (MICROSOFT, 2009b), pode ainda contribuir bastante para o sincronismo tem-

poral: a execução de mídias em tempo de edição. No caso do sincronismo de um vídeo com

uma legenda, o timeline permite ver a legenda posicionada como um bloco de 5 segundos a

partir do segundo 10 da apresentação, por exemplo. Contudo, faz-se necessário poder executar

o vídeo no próprio editor. Caso contrário, não será possível identificar qual cena acontece entre

os segundos 10 e 15 e se a legenda está sincronizada no tempo correto.

1Em português, o que se vê é o que se tem.

1 Introdução 2

O surgimento da multimídia trouxe uma revolução na área, mas o mercado ainda reservava

outra surpresa. Observando a crescente popularização da Internet, percebeu-se a oportunidade

de combinar as diferentes mídias não mais em uma sequência única de apresentação, mas de

acordo com o paradigma de hipertexto, onde “hipersaltos” permitem aos usuários escolherem

suas próprias sequências de apresentação. Enquanto as mídias são relacionadas apenas nas

dimensões de espaço e tempo na multimídia, na hipermídia, as mídias podem estar relacionadas

de inúmeras outras formas, em uma dimensão da lógica, muito mais complexa e dinâmica,

que permite não só os “hipersaltos” do hipertexto, mas uma nova árvore de possibilidades que

inclui desde a definição de diferentes níveis de acesso à informação até a geração de conteúdo

por parte dos usuários. Naturalmente que, junto com novas possibilidades, aparecem novas

dificuldades. Nesse caso, a principal dificuldade é como gerenciar esse sincronismo lógico, ou

seja, como descrever todas as novas formas de interações entre as mídias.

Existem diversos modelos, ferramentas e metodologias para tentar expressar os novos con-

ceitos da hipermídia. De acordo com Christodoulou et al. (1998), os modelos devem não só

conseguir expressar os atuais conceitos, como estar preparados para o surgimento de novos con-

ceitos ainda não imaginados. Assim, esses modelos devem tentar abstrair a comunicação entre

as mídias, permitindo que haja comunicação, mesmo com tipos ainda desconhecidos. Não é

possível, portanto, definir um limite para a hipermídia, o que gera dificuldade para entender as

possibilidades, até mesmo para a equipe de desenvolvimento. Como, então, fazer um cliente

entender, por exemplo, o significado de “links ativos animados que estão disponíveis por um

determinado período na apresentação e que trazem resultados baseados em buscas semânticas”

e que esta é apenas uma das inúmeras possibilidades?

Dentre os sistemas hipermídia, os mais populares são a TV Digital e a Internet. Cada

um apresenta suas particuliaridades e dificuldades. A Internet, com a Web 2.0, possibilitou a

geração de conteúdo por parte dos usuários, formando sistemas hipermídia distribuídos com in-

teratividade semelhante a de sistemas desktop, porém acessível através de qualquer browser de

um dispositivo em qualquer lugar do mundo conectado à Internet. Contudo, uma vez encerrada

a conexão com a Internet, perde-se também o acesso aos dados. A revolução se desenvolve com

o paradigma da computação nas nuvens (WEISS, 2007), no qual se pretende oferecer softwares

como serviços apoiados em uma plataforma na Internet com distribuição de armazenamento e

carga de processamento, e culmina no paradigma Dev 2.0 (SHROFF, 2008), onde as próprias

ferramentas de desenvolvimento de aplicações nas nuvens são também aplicações nas nuvens.

Entre as novas dificuldades de desenvolvimento, está a necessidade de envio dos arquivos em

um servidor para então acessá-los através de um web browser. Isso gera um ciclo de desen-

volvimento conhecido como “editar-salvar-atualizar”, ou seja, editar o documento utilizando

1 Introdução 3

um editor qualquer, salvar o arquivo em um servidor e recarregar a visualização no browser.

A computação nas nuvens e Dev 2.0 também têm suas próprias dificuldades, tais como

questões de armazenamento de informações de forma distribuída e distribuição de carga de pro-

cessamento. Surgem, então, funcionalidades para tentar minimizar essas dificuldades, como

integração do ambiente de desenvolvimento com softwares de envio FTP e web browsers e a vi-

sualização dinâmica, como encontrada no Adobe Dreamweaver (ADOBE, 2009a), que permite

rodar scripts de cliente e servidor, após a configuração de um servidor local. Há também frame-

works para lidar com questões de distribuição de carga de processamento e armazenamento,

como o Google App Engine, e inúmeras outras APIs para diversas etapas do desenvolvimento

web, como Prototype (STEPHENSON, 2005), ExtJS (EXT, 2009), Rico (SCOTT et al., 2009)

e as APIs desenvolvidas pelo Google (GOOGLE, 2009a).

A TV Digital, por sua vez, propõe aumentar a interatividade dos programas de televisão,

apresentando dificuldades como edição de programas ao vivo, isto é, documentos que já começaram

a ser executados e precisam ser modificados dinamicamente, além de questões de transmissão,

como a dificuldade de enviar conteúdo privado e personalizado através de uma transmissão

por broadcast, e canal de retorno, que permita que usuários enviem informações de volta para

a emissora de conteúdo. Neste trabalho, foca-se no desenvolvimento web. Contudo, os con-

ceitos, modelos e ferramentas desenvolvidos foram idealizados para abranger sistemas hiper-

mídia genéricos e podem e devem ser estendidos para atender às necessidades específicas do

desenvolvimento de aplicações hipermídia genéricas e para TV Digital.

A Tabela 1.1 resume as principais dificuldades e respectivas funcionalidades de apoio en-

contradas no desenvolvimento hipermídia.

Tabela 1.1: Dificuldades do desenvolvimento hipermídiaDificuldades Funcionalidades de apoio

Específica de mídia

Sincronismo espacial WYSIWYG

Sincronismo temporal Timeline, execução de mídias em tempo de edição

Descrição hipermídia e Modelos, metodologias e ferramentas, como

necessidade de suportar NCM (CASANOVA et al., 1991),

funcionalidades futuras AHM (HARDMAN et al., 1994),

OOHDM (SCHWABE; ROSSI, 1995) e a

estrutura xanalógica (NELSON, 1999b)

Entendimento das possibilidades

1.1 Objetivo 4

Além de todas as características e dificuldades da hipermídia, o desenvolvimento web apre-

senta dificuldades e respectivas funcionalidades de apoio próprias, resumidas na Tabela 1.2.

Tabela 1.2: Dificuldades específicas do desenvolvimento webDificuldades Funcionalidades de apoio

Distância entre edição e visualização da WYSIWYG, suporte a FTP,

abordagem “Editar - Salvar - Atualizar” integração com servidor local,

integração com browsers e

visualização dinâmica

Distribuição de processamento e armazenamento APIs e frameworks de desenvolvimento

1.1 Objetivo

As ferramentas de desenvolvimento hipermídia/web começaram como simples editores de

texto, uma vez que, independente das funcionalidades oferecidas pela ferramenta, o resultado

final é um documento de texto escrito nas mais variadas linguagens. Ao longo dos anos, foram

incorporadas funcionalidades para facilitar a escrita do código, tais como as citadas anterior-

mente, ou seja, complementação e destaque do código, interfaces WYSIWYG, que permitem

que o autor pré-visualize o resultado dentro do ambiente de edição, a execução de mídias em

tempo de edição, a visualização dinâmica e a integração com softwares FTP e browsers, como

tentativa de agilizar o processo de publicação e visualização do resultado final que o usuário

receberá.

Todas essas funcionalidades são uma tentantiva de diminuir a distância entre a edição e

a visualização do resultado, seja através de uma pré-visualização, seja através da automação

e agilização de etapas. Entretanto, a visualização do resultado ainda requer um número in-

satisfatório de etapas. Assim, o desafio deste trabalho é encontrar novas funcionalidades para

diminuir ainda mais a distância entre a edição de documentos hipermídia/web e a visualização

do resultado.

1.1.1 Objetivos específicos

Este trabalho procura funcionalidades para diminuir a distância entre a edição e a visuali-

zação de documentos hipermídia/web buscando principalmente:

• Aumentar o entendimento do processo de desenvolvimento hipermídia/web através da

1.2 Metodologia 5

aproximação entre a codificação e a interação com o resultado.

• Permitir a execução de mídias em tempo de edição a fim de facilitar o sincronismo demídias.

• Desenvolver um software capaz de evoluir para suportar funcionalidades futuras do de-senvolvimento hipermídia.

1.2 Metodologia

Em trabalho de introspecção - que considera 5 anos de experiência no desenvolvimento de

aplicações web; 2 anos de estudo no projeto do SBTVD (Sistema Brasileiro de TV Digital),

focados principalmente no modelo NCM (Nested Context Model)(CASANOVA et al., 1991) e

na linguagem NCL (Nested Context Language)(SOARES; RODRIGUES, 2005); bem como o

período de curso das disciplinas do Mestrado Acadêmico de Ciência da Computação, princi-

palmente as disciplinas de inteligência artificial - foi idealizada uma abordagem de desenvolvi-

mento interativa, à qual denominamos DIA (Desenvolvimento interativo de aplicações). Da

mesma forma, foi idealizado um modelo de representação de conhecimento genérico, chamado

posteriormente Nós, na tentativa de encontrar um modelo para descrever documentos hipermí-

dia/web de forma distribuída. Representando a informação de acordo com o modelo Nós, o

webservice Lumen provê uma solução para armazenamento de informação genérica nas nu-

vens.

Baseado no modelo Nós foi proposto MAU, um modelo cognitivo para escolher as ações

de um agente reativo com aprendizado, chamado AgenteNós. Sua implementação JavaScript,

chamada agente virtual, é na prática um objeto JavaScript extensível, que provê uma interface

para a definição de novos métodos e vence as limitações de persistência do JavaScript através

de requisições HTTP assíncronas para o webservice Lumen. Instanciando, em uma página web,

um agente virtual, batizado de ce, foram ensinados métodos para suportar o desenvolvimento

de aplicações de acordo com a abordagem DIA. O suporte à criação de agentes virtuais e o

mecanismo de persistência, oferecido pelo webservice Lumen, acessados através da interface

gráfica dinâmica, construída, em tempo de execução, pelo agente virtual ce, formam o ambiente

DIS (Desenvolvimento inteligente de sistemas). A partir dessas implementações, iniciou-se,

então, uma pesquisa bibliográfica para validar e amadurecer os conceitos da abordagem DIA e

do modelo Nós.

1.3 Estrutura da dissertação 6

1.3 Estrutura da dissertação

Este trabalho está organizado em oito capítulos. Inicialmente, no Capítulo 2, estão descritas

as principais tecnologias envolvidas. No Capítulo 3, são analisadas outras ferramentas para

desenvolvimento web disponíveis no mercado. A abordagem DIA é explicada no Capítulo 4. O

modelo de representação de conhecimento Nós é introduzido no Capítulo 5. No Capítulo 6, é

apresentado o ambiente DIS. Como estudo de caso, o desenvolvimento de uma aplicação web

para proporcionar um espaço para difusão de conhecimento, o site “Encontro de estudantes”,

é mostrado no Capítulo 7. Finalizando, conclusões e trabalhos futuros são apresentados no

Capítulo 8. Para melhor entendimento, as idéias que deram origem ao modelo Nós são expostas

no Apêndice A e sua utilização é exemplificada no Apêndice B.

7

2 Referencial teórico

2.1 Evolução do conteúdo da Internet

O conteúdo e a utilização da Internet têm mudado desde sua criação. Inicialmente, páginas

web baseadas em HTML exibiam conteúdo estático sem nenhuma interatividade. Procurando

fornecer mais interatividade, foram inseridos applets, pedaços de código Java executados no

computador do usuário. Esses applets, verdadeiros aplicativos carregados por download e exe-

cutados no computador do usuário, têm acesso limitado a recursos de persistência. Uma alter-

nativa encontrada foi executar códigos em servidores da Internet e enviar novamente o HTML

puro para o usuário. Dessa forma, é possível construir páginas dinâmicas que oferecem serviços

interativos com recursos de persistência de dados e código protegido no servidor. Além disso,

conseguem-se outras vantagens, como não ser necessário realizar o download dos códigos e a

possibilidade de processamento distribuído na Internet.

A simples mistura de código de servidor, como ASP ou PHP, com código HTML resolve

muitos problemas, porém, a comunicação com o servidor era, inicialmente, feita através de

requisições síncronas. Nesse caso, é necessário descarregar a memória para enviar e receber

informações para o servidor. O conteúdo das páginas é dinâmico, mas qualquer pequena al-

teração na tela, como uma nova hora ou uma mensagem de boas-vindas para o usuário que

acaba de se identificar, necessita recarregar e renderizar a página inteira com todas as tabelas,

figuras etc. Esses serviços acabam por se tornar lentos, portanto, com interatividade limitada,

uma vez que a troca de informações com o servidor - e, consequentemente, o processamento

- é esporádica. Entretanto, o aumento da velocidade de conexão à Internet e, principalmente,

o melhor aproveitamento da banda, através de técnicas de requisição assíncrona trazidas pela

Web 2.0 (O’REILLY, 2005), permitiram criar serviços web com complexidade e interatividade

semelhantes às de sistemas desktop. A revolução da Web 2.0 é uma nova forma de usar tecnolo-

gias antigas, alterando principalmente a relação entre o usuário e o conteúdo da Internet. Um

melhor aproveitamento dos recursos permitiu maior interatividade, permitindo que usuários

não sejam apenas consumidores, mas também fornecedores de conteúdo. Diferentemente de

2.1 Evolução do conteúdo da Internet 8

serviços P2P (Peer-to-Peer), uma forma de transferência de arquivos entre usuários, a Web 2.0

permite criar verdadeiras bibliotecas de conhecimento, como a Wikipedia (WIKIPEDIA, 2009),

cujo conteúdo é gerado por usuários, ao invés de um gerador de conteúdo centralizado.

Assim como a revolução da Web 2.0, que trouxe uma nova forma de manipulação das tec-

nologias antigas, Weiss (2007) apresenta o paradigma de computação nas nuvens (do inglês,

Cloud computing), que propõe concentrar o poder de processamento em uma nuvem de com-

putadores e acessar seus serviços por meio de interfaces e dispositivos leves. Dessa forma,

não é necessário realizar downloads ou instalações no computador do usuário. Também não

é necessário espaço para armazenamento, pois as aplicações nas nuvens fornecem espaço de

memória para armazenar arquivos em servidores na Internet, acessíveis de qualquer computa-

dor. O objetivo da computação nas nuvens é que o usuário tenha acesso a todos os seus dados

a partir de qualquer dispositivo conectado à Internet e possa manipulá-los através de seus edi-

tores favoritos. O principal problema desse paradigma é a dependência da Internet, uma vez

sem conexão à Internet, perde-se o acesso aos dados. Também existe discusão em torno da pro-

priedade sobre os dados, se pertencem ao usuário que os gera ou ao servidor que os armazena?

O fato é que o atual conteúdo das páginas web é tão dinâmico que Google (2008) as considera

verdadeiras aplicações.

O atual conteúdo da Internet é um excelente exemplo de uma aplicação hipermídia. Apli-

cações web são compostas por diferentes mídias (textos, imagens, vídeos, animações etc) que

se iniciam em diferentes momentos. Além disso, o usuário pode escolher a sequência de apre-

sentação dessas mídias. Para desenvolver essas aplicações web, existem inúmeras tecnologias

disponíveis, cada uma com sua particularidade. Neste trabalho, será analisado o desenvolvi-

mento utilizando HTML/CSS + AJAX + PHP, por ter um funcionamento parecido com outras

linguagens de servidor e seu entendimento ser mais simples que soluções baseadas em Java.

HTML, CSS, AJAX e PHP são essencialmente texto, por isso, podem ser desenvolvidos a

partir de um simples editor de textos. Contudo, visando aumentar a produtividade, ferramentas

de desenvolvimento agregaram funcionalidades como complementação e destaque de código.

A evolução dessas ferramentas trouxe edição gráfica no estilo WYSIWYG e gerenciamento do

sistema de arquivos local e remoto. Seguindo a tendência da computação nas nuvens, Shroff

(2008) propõe como o próximo passo para as ferramentas de desenvolvimento web que, assim

como as demais aplicações, elas também sejam fornecidas como serviços na Internet. Começa,

então, um novo ciclo. As ferramentas, agora na Internet, iniciam como simples editores de

texto e agregam novas funcionalidades para aumentar a produtividade. Como exemplo, pode-

se citar as aplicações web Caspio Bridge (CASPIO, 2009), Coghead (COGHEAD, 2009) e

2.2 Desenvolvimento Hipermídia 9

AppExchange (SALESFORCE, 2009), que fornecem plataformas para o desenvolvimento de

aplicações web orientadas a bancos de dados. Além dessas, o Google Sites (GOOGLE, 2009b)

é uma aplicação web que fornece uma interface amigável para a construção de websites. É pos-

sível adicionar diversos tipos de mídia, como textos, imagens, vídeos, tabelas etc. Entretanto,

não são suportados scripts ou acesso a banco de dados.

2.2 Desenvolvimento Hipermídia

A autoria de um documento hipermídia consiste em descrever como as mídias estão rela-

cionadas entre si. Para isso, o autor deve definir como as mídias estão organizadas logicamente

e como elas estão posicionadas ao longo do tempo e do espaço (SAADE et al., 2003). A descri-

ção de documentos hipermídia pode ser feita através da linguagem HTML (RAGGETT et al.,

1999), que permite estabelecer relações espaciais e algumas relações lógicas entre os elemen-

tos. Relações temporais podem ser definidas através de scripts embarcados no HTML, como

JavaScript. Na tentativa de manter as vantagens das linguagens de marcação no estilo XML,

surgiram linguagens específicas para descrição hipermídia, como SMIL (AYARS et al., 2001),

recomendação do consórcio W3C, e NCL (SOARES; RODRIGUES, 2005), a linguagem para

descrição de aplicações do SBTVD (Sistema Brasileiro de TV Digital).

Diversas ferramentas surgiram para auxiliar o processo de sincronismo de mídias. Entre as

mais conhecidas estão Microsoft Expression Web (MICROSOFT, 2009a) e Adobe Dreamweaver

(ADOBE, 2009a). Essas duas ferramentas, porém, foram criadas para editar um tipo específico

de hipermídia muito utilizado atualmente, os websites ou páginas web. Assim, elas permitem

o sincronismo lógico e espacial, mas não suportam o sincronismo temporal. Contudo, outras

ferramentas permitem a autoria de documentos hipermídia genéricos, disponibilizando funcio-

nalidades para sincronismo lógico, espacial e temporal. Pode-se citar: Cardinal Studio (CAR-

DINAL, 2007), Alti Composer (ALTICAST, 2007), GRiNS (BULTERMAN et al., 1998), Lim-

See2 (WAM, 2007), Adobe Flash (ADOBE, 2009b) e o brasileiro Composer (GUIMARAES,

2007), desenvolvido pelo laboratório de TeleMídia da PUC-Rio.

É comum que editores hipermídia implementem o conceito de WYSIWYG, permitindo que

o autor posicione as mídias através de uma interface gráfica - o que facilita o trabalho de sin-

cronismo espacial. Entretanto, esses editores não costumam permitir a execução de mídias

dinâmicas, como áudio ou vídeo, em tempo de edição. Implementada, por exemplo, pelo editor

multimídia Microsoft MovieMaker (MICROSOFT, 2009b), a falta dessa funcionalidade difi-

culta o trabalho de sincronismo temporal entre as mídias. Um exemplo simples disso é o sin-

2.2 Desenvolvimento Hipermídia 10

cronismo de uma legenda com um vídeo. Nesse caso, o autor precisa conhecer os tempos onde

as falas acontecem, chamados de pontos de sincronismo. Se o editor hipermídia não executar

a mídia em tempo de edição, será necessário algum outro aplicativo que execute a mídia para

descobrir esses pontos de sincronismo. Em seguida, será necessário voltar ao editor e anotá-los

manualmente.

Buscando ferramentas mais adequadas para descrição hipermídia, Bieber et al. (1997a)

apresentam funcionalidades de sistemas hipermídia de terceira e quarta geração, como “links

tipados”, atributos de links, links com consultas baseadas na estrutura ou na semântica, trans-

clusões (NELSON, 1995) etc. Christodoulou et al. (1998) reconhecem a grande contribuição do

maior sistema hipermídia, a Internet, e apontam como questões principais a necessidade de os

designers reutilizarem experiências anteriores, a necessidade de os autores conseguirem alterar

facilmente a estrutura e o conteúdo e a necessidade de os usuários poderem definir suas próprias

formas de visualização e navegação das informações. Assim, um HADMS (“Hypermedia Ap-

plication Development and Management System”1) deve pelo menos:

1. Fornecer um modelo hipermídia abstrato capaz de organizar e estruturar semanticamente

a informação de forma eficiente, suportando as funcionalidades hipermídia de terceira e

quarta geração apresentadas por Bieber et al. (1997a). O modelo deve ser extensível para

integrar futuras funcionalidades.

2. Ser capaz de converter o conteúdo descrito de acordo com o modelo em uma aplicação

hipermídia estática ou dinâmica.

3. Suportar integração ou importação de conteúdo de outras bases de informação e permitir

reutilização de aplicações existentes.

4. Ser capaz de reutilizar facilmente o conteúdo para criar diferentes tipos de aplicações

hipermídias em diferentes sistemas hipermídia, como a Internet, TVDigital etc.

As metodologias para construção de sistemas desktop ou hipertexto foram, inicialmente,

aplicadas ao desenvolvimento hipermídia. Contudo, diversos trabalhos mostram que essas

metodologias não conseguem expressar adequadamente os conceitos hipermídia/web. Assim

são propostas novas metodologias com suas respectivas ferramentas de suporte, como as apre-

sentadas em (STREITZ et al., 1992; BIEBER et al., 1997b; FIELDING et al., 1998; GRIF-

FITHS et al., 2002; DÍAZ et al., 2005; ARMANI, 2005; AVGERIOU; RETALIS, 2005). Ou-

tros trabalhos acreditam que o modelo Dexter (HALASZ; SCHWARTZ, 1990), utilizado para

1Sistema de gerenciamento e desenvolvimento de aplicações hipermídia.

2.3 Desenvolvimento Web 11

descrição de documentos hipertexto, também não é suficiente para descrever sistemas hipermí-

dia/web, por isso, propõem novos modelos como o NCM (CASANOVA et al., 1991), o AHM

(HARDMAN et al., 1994) e o OOHDM (SCHWABE; ROSSI, 1995). Preocupado em descrever

as informações naturalmente distribuídas da hipermídia, Nelson (1999b) propõe uma estrutura

xanalógica que descreve a informação baseada em nós de conteúdo, associados por dois tipos

de links: links de conteúdo e transclusões. O primeiro é o link normal, ao qual estamos acos-

tumados, que indica que determinada informação está do outro lado do link. O segundo serve

para indicar que a informação exibida é a mesma informação apontada pelo link. Dessa forma,

é possível reutilizar o conteúdo sem perder informações sobre o documento original e a autoria.

Caumanns (1998) ressalta que a interconexão estática entre o ambiente de execução, a apli-

cação e as mídias (textos, imagens, vídeos etc) leva a um software monolítico, de forma que para

realizar pequenas alterações na aplicação, pode ser necessário modelar, compilar e publicar no-

vamente a aplicação inteira. Essa lentidão pode ser ainda mais maléfica para o entendimento do

poder da hipermídia. Uma vez que as mídias podem se relacionar de muito mais formas do que

a simples união do hipertexto com a multimídia, torna-se difícil imaginar as possibilidades sem

de fato interagir com o resultado. Para se ter uma idéia a hipermídia tem permitido ao usuário,

não só escolher a forma de apresentação do conteúdo, mas também adicionar e alterar o próprio

conteúdo. A hipermídia é baseada em opções e escolhas.

2.3 Desenvolvimento Web

O sistema hipermídia mais utilizado atualmente é a Internet. Fernandes (2003) explica que

aplicações web, de acordo com o modelo MVC (Model-View-Controller), são divididas em 3

camadas: serviços para o usuário, lógica de negócio e serviço de dados. Os serviços para usuário

oferecem uma interface gráfica que permite ao usuário interagir com a aplicação. Para isso, o

HTML tem sido utilizado para descrever elementos estáticos, enquanto JavaScript, applets Java

ou componentes em Flash acrescentam alguma interatividade no computador do cliente. A

interface gráfica acessa as funcionalidades descritas na lógica de negócio. Esta é responsável

por realizar operações complexas e pode ser desenvolvida com PHP, ASP, JSP, CORBA, Perl

etc. Por fim, o serviço de dados permite persistir dados em bancos de dados, no sistema de

arquivos ou em mídias graváveis. Bancos de dados são mais utilizados devido à praticidade

para armazenar, recuperar e alterar informações de uma forma organizada.

Para Bauer (2005), ferramentas e metodologias para o desenvolvimento web devem levar

em consideração algumas diferenças em relação ao desenvolvimento desktop, como: limites de

2.4 Desenvolvimento baseado em script 12

tempo menores, pouco entendimento por parte do cliente sobre o que é possível ser feito, rápidas

mudanças na tecnologia e o fato de tudo se resumir em uma única interface para o usuário

(o browser). Embora muito esforço tenha sido concentrado nas etapas de conceitualização e

projeto, pouca atenção foi dada ao processo de codificação dos arquivos.

O desenvolvimento de aplicações web no estilo HTML/CSS + AJAX + alguma linguagem

de servidor, como PHP ou ASP, leva a um ciclo conhecido como “editar-salvar-atualizar”, isto

é, depois de editar o documento, é necessário salvá-lo em um servidor web e, através de um

browser, recarregar a página inteira. No caso de a lógica de negócio ser implementada com

Java ou .NET, para que uma pequena alteração em uma das classes seja publicada, é preciso

re-enviar para o servidor a aplicação inteira. Esse ciclo é comparável a ser necessário clicar

em três botões de “ok” cada vez que se desejasse abrir uma pasta ao explorar o sistema de

arquivos. Na prática, para visualizar o documento, é necessário pressionar um botão para salvar

o documento, pressionar outro botão para enviar o documento para o servidor e, terminando

o upload, pressionar um último botão para iniciar o browser e recarregar a aplicação. Mesmo

que cada etapa demore muito pouco (o que nem sempre é verdade), um grande número de

etapas entre a edição e a visualização do resultado pode desmotivar o programador, diminuindo

sua produtividade e desestimulando testes. Apesar disso, esse detalhe tem sido ignorado pela

literatura.

Di Iorio & Vitali (2003) avançaram um pouco nesse sentido ao integrar o browser com

ferramentas de edição, como o MS Word. Em um cenário típico, o usuário está navegando pelo

browser quando decide editar a página. Clicando em um botão, o programa de edição, no caso

o MS Word, é iniciado. Depois que as alterações são feitas, o arquivo é salvo em um servidor,

onde é feito um controle de versões. De volta ao browser, a nova versão pode ser observada

graças a um script que verifica, periodicamente, mudanças nos arquivos visualizados.

2.4 Desenvolvimento baseado em script

Linguagens de script como JavaScript, Tcl e Lua fornecem mecanismos de teste de apli-

cações, como a linha de comando, na qual é possível executar comandos e acompanhar seu

resultado em tempo real. Normalmente, a linha de comando é utilizada para criar protótipos e

rapidamente testá-los, o que, no nosso ponto de vista, traria um benefício também para desen-

volvedores de aplicações hipermídia/web.

Apesar de eficazes, os protótipos criados pela linha de comando não costumam ser aproveita-

dos para a aplicação real. O código precisa ser re-escrito em um editor de textos comum que

2.5 Inteligência Artificial 13

não permite seu teste. Para testar, é preciso armazenar o script em um documento, sair do editor

e executar o arquivo salvo através de um ambiente de execução. A linha de comando não con-

segue agrupar os comandos executados para criar o protótipo e persisti-los em arquivos. Acaba

sendo necessário escrever o código duas vezes, uma para testar e outra para realmente escrever

a aplicação. Isso acontece, principalmente, porque linguagens de script costumam apresentar

limitações em relação a persistência. No caso de documentos web, o JavaScript é executado no

browser do usuário, e, por óbvias medidas de segurança, não tem acesso ao sistema de arquivos

do usuário.

Segundo Ousterhout (1998), linguagens de script foram feitas para unir componentes pré-

existentes, normalmente desenvolvidos em linguagens de sistema. Prechelt (2003) lembra que

linguagens de script costumam não ser tipadas para facilitar o trabalho de conectar diferentes

tipos de componentes. Assim, tornam-se ideais para a descrição hipermídia, onde elementos de

diversos tipos de mídia devem estar interconectados.

2.5 Inteligência Artificial

O homem se autodenomina homo sapiens, homem sábio, devido à grande importância que

dá às capacidades mentais. Há milhares de anos, cientistas e filósofos tentam entender como

pensamos, isto é, como é possível um aglomerado de matéria conseguir perceber, entender,

predizer e manipular um mundo muito maior e mais complicado que ele. A área de inteligência

artificial, IA, vai mais além, com o objetivo não só de entender, mas de construir entidades

inteligentes (RUSSELL et al., 1995).

Definições de inteligência artificial variam em duas dimensões. Como mostra a Tabela

2.1, as definições da primeira linha se preocupam com os processos do pensamento e com

o raciocínio, enquanto que as da segunda linha descrevem comportamentos. As definições

da primeira coluna medem o sucesso em termos de fidelidade com a performance humana,

enquanto que as da segunda coluna comparam com um conceito ideal de inteligência, chamado

racionalidade. Um sistema é racional se ele faz a “coisa certa”, dado o que ele “sabe”.


Tabela 2.1: Definições de inteligência artificialComo humano Racionalmente

“O excitante novo esforço para fazer

computadores pensarem... máquinas

com mentes, no sentido completo e lit-

eral.’ (HAUGELAND, 1985)

“O estudo das faculdades mentais

através da utilização de modelos

computacionais.” (MCDERMOTT;

CHARNIAK, 1985)

Pensam “[A automação de] atividades que

nós associamos como pensamento hu-

mano, atividades como tomadas de de-

cisão, resolução de problemas e apren-

dizado...” (BELLMAN, 1978)

“O estudo da computação que permite

perceber, raciocinar e agir.” (WIN-

STON, 1992)

“A arte de criar máquinas que real-

izam funções que requerem inteligên-

cia quando realizadas por pessoas.”

(KURZWEIL, 1990)

“Inteligência computacional é o es-

tudo de projetar agentes inteligentes.”

(POOLE et al., 1998)

Agem “O estudo de como fazer computa-

dores realizarem tarefas que, no mo-

mento, as pessoas são melhores.”

(RICH; KNIGHT, 1991)

“IA... está preocupada com o com-

portamento inteligente dos artefatos.”

(NILSSON, 1998)

Historicamente, todas as quatro abordagem de IA foram seguidas. As abordagens centradas

em humanos precisam ser uma ciência empírica, envolvendo hipóteses e confirmação experi-

mental, enquanto que as abordagens racionalistas envolvem uma combinação de matemática e

engenharia.

2.5.1 Agindo como humano: a abordagem do teste de Turing

O teste de Turing (RUSSELL et al., 1995) foi desenvolvido para fornecer uma definição

operacional satisfatória de inteligência. Turing definiu o comportamento inteligente como a

habilidade de alcançar o nível da performance humana em todas as tarefas cognitivas suficiente

para enganar um interrogador. Nesse teste, um computador deve ser interrogado por um hu-

mano através de um terminal remoto. No final, o computador passa no teste se o humano não

conseguir dizer se tem um computador ou um humano do outro lado. Existe controvérsia em re-

lação ao computador ser realmente inteligente pelo simples fato de passar no teste. De qualquer

forma, para que isso seja possível, o computador precisa das seguintes habilidades cognitivas:


1. Processamento de linguagem natural, para conseguir se comunicar em alguma língua

humana, como o português.

2. Representação do conhecimento, para armazenar informações fornecidas antes e du-

rante o interrogatório.

3. Raciocínio automático, para usar a informação armazenada para responder as questões

e tirar novas conclusões.

4. Aprendizado de máquina, para se adaptar a novas circunstâncias e detectar padrões não

imaginados.

O teste de Turing, deliberadamente, evitou a interação física direta entre o interrogador

e o computador, porque a simulação física de uma pessoa não é necessária para a inteligên-

cia. Contudo, o chamado teste total de Turing inclui um sinal de vídeo e a oportunidade de

o interrogador passar objetos através de uma escotilha, para que o interrogador possa testar as

habilidades perceptuais do computador. Assim, também são necessários:

1. Visão computacional, para perceber os objetos.

2. Robótica, para mover os objetos.

A IA não concentrou muito esforço para tentar passar no teste de Turing. Essa questão

de agir como humano aparece primordialmente quando programas precisam interagir com hu-

manos, como em um sistema especialista explicando como chegou a um diagnóstico ou em um

diálogo de um sistema de processamento de linguagem natural com um usuário. Nesses casos,

os programas precisam seguir algumas convenções de interação humana para se fazerem enten-

didos. A representação interna e o raciocínio de tais sistemas podem ou não ser baseados em

um modelo humano.

2.5.2 Pensando como humano: a abordagem de modelo cognitivo

Para dizer que um programa pensa como um humano é necessário determinar de alguma

forma como os humanos pensam, é necessário descobrir como funcionam os mecanismos in-

ternos da mente humana. Existem duas formas de fazer isso: através de introspecção, tentando

capturar o pensamento enquanto ele acontece; ou através de experimentos psicológicos. Ao

alcançar uma teoria suficientemente precisa, é possível expressá-la como um programa de com-

putador. Se os comportamentos de entrada/saída e tempo nesse programa forem parecidos com


o comportamento humano, há evidência de que o mecanismo proposto pode ser semelhante

àquele operando na mente humana.

Johnson-Laird (1983) nos lembra que a tecnologia é criada a partir de modelos funcionais

capazes de reproduzir determinadas características da natureza. Para isso, não é necessário que

o modelo construído seja exatamente igual ao real, basta que o resultado seja o mesmo. Assim,

ele propõe sete critérios para validar um possível modelo cognitivo humano, a saber:

1. Uma teoria adequada deve levar em consideração a tirada de conclusões, a relativa dificul-

dade de diferentes inferências e os erros sistemáticos e vieses que ocorrem em conclusões

espontâneas.

2. A teoria deve explicar a diferença das habilidades de inferência entre um indivíduo e

outro.

3. A teoria deve ser extensível de forma natural para ser aplicada em uma variedade de

inferências, ao invés de um tipo específico de deduções.

4. A teoria deve explicar como crianças adquirem a habilidade de fazer inferências válidas.

5. A teoria deve permitir que pessoas sejam capazes de fazer inferências válidas, isto é, elas

são potencialmente racionais.

6. A teoria deve mostrar porque a lógica formal foi inventada e como ela foi desenvolvida.

7. A teoria deve idealmente ter aplicações práticas no ensino de técnicas de raciocínio.

2.5.3 Pensando racionalmente: a abordagem das “leis do pensamento”

O filósofo grego Aristóteles foi um dos primeiros a tentar codificar o “pensamento correto”,

isto é, um processo de raciocínio irrefutável. Seus silogismos permitem estruturas que sempre

chegam a conclusões corretas dadas premissas corretas. Essas “leis do pensamento” suposta-

mente governam as operações da mente e seu estudo gerou a área chamada lógica clássica ou

simplesmente lógica (RUSSELL et al., 1995).

O desenvolvimento da lógica formal permitiu uma notação precisa para criar argumentos

sobre todas as coisas no mundo e as relações entre elas. Dessa forma, foi possível criar progra-

mas de computadores que, dados tempo e espaço suficientes, recebem a descrição do problema

em notação lógica e encontram uma solução. Contudo, existem dois grandes obstáculos para

essa abordagem. Primeiro, não é tão simples descrever o conhecimento informal do mundo


nos termos formais necessários para a lógica, principalmente quando tratando com informações

incertas ou imprecisas. Segundo, o domínio de soluções pode ser muito grande, mesmo em

problemas com poucos fatos, excedendo os recursos do computador, a não ser que sejam apli-

cadas heurísticas para indicar quais passos do raciocínio tentar primeiro. Mesmo considerando

esses obstáculos, a lógica é muito utilizada por causa de seu poder de representação e pelo fato

de sistemas de raciocínio serem bem definidos e entendidos.

2.5.4 Agindo racionalmente: a abordagem do agente racional

Figura 2.1: Arquitetura de um agente.

Para a IA, um agente é alguma coisa que percebe o ambiente através de seus sensores e

age modificando o ambiente através de seus atuadores, conforme ilustrado na Figura 2.1 (RUS-

SELL et al., 1995). Agir racionalmene significa agir de forma a atingir o objetivo do agente.

Para identificar a realização dos objetivos, o agente tem uma medida de utilidade embutida

implicitamente, através de suas regras, ou explicitamente, através de metas ou funções de uti-

lidade. Nessa abordagem, a IA é vista como o estudo e a construção de agentes racionais.

Na abordagem das “leis do pensamento”, a ênfase está em realizar inferências corretas. Fazer

inferências corretas faz parte de agir racionalmente, porque uma forma de agir racionalmente

é raciocinar logicamente para chegar à conclusão que uma determinada ação irá atingir o ob-

jetivo e então executar a ação encontrada. Entretanto, a racionalidade pode ser atingida não

somente através de inferências corretas, uma vez que existem situações em que provalmente

não há nenhuma ação correta e, mesmo assim, alguma ação precisa ser executada. Em outras

situações, agir racionalmente não envolve necessariamente inferências. No caso de soltar um

objeto quente, uma ação por reflexo é mais efetiva do que uma ação concluída depois de um

lento processo de deliberação.

As habilidades cognitivas necessárias para o teste de Turing também possibilitam ações

racionais. É necessário representar o conhecimento e o raciocínio para poder chegar a boas

decisões em diversas situações. O aprendizado é necessário para ter uma idéia melhor de como

o mundo funciona e assim gerar estratégias mais efetivas para lidar com ele. Percepção visual


é necessária para entender o resultado que a ação é capaz de alcançar. Assim, trabalhar com

agentes racionais é mais abrangente do que a abordagem das “leis do pensamento”, uma vez

que pensar racionalmente pode ajudar a agir racionalmente, mas isto pode não ser necessário.

Essa abordagem também é mais simples que as abordagens focadas em humanos, já que a

racionalidade é um conceito bem definido, enquanto que o comportamento humano é muito

mais complicado e difícil de entender.

Agentes reativos e agentes reativos com aprendizado

Agentes reativos simples, segundo Russell et al. (1995), percebem o ambiente através de

sensores que interpretam o ambiente em sinais de formato conhecido. Esses sinais ativam regras

pré-definidas que indicam a ação a ser executada por seus atuadores, conforme ilustrado na

Figura 2.2.

Figura 2.2: Arquitetura de um agente reativo simples.

Russell et al. (1995) também mostram a arquitetura de agentes com aprendizado, agentes

que possuem um mecanismo de aprendizado. No caso de agentes reativos com aprendizado, o

mecanismo de aprendizado é responsável pela atualização e criação de regras, como ilustrado

na Figura 2.3.

Figura 2.3: Arquitetura de um agente reativo simples com aprendizado.

2.6 Resumo do capítulo 19

2.6 Resumo do capítulo

Neste capítulo, discutiu-se a evolução do conteúdo da Internet partindo de páginas estáti-

cas, passando por páginas dinâmicas com código no servidor, até chegar ao paradigma de com-

putação nas nuvens, que incentiva a migração das aplicações para servidores na Internet, e

ao conceito de Dev 2.0, que sugere que as ferramentas para desenvolvimento também sejam

aplicações nas nuvens. Foi visto que a evolução de sistemas hipertexto ou multimídia para sis-

temas hipermídia trouxe complexidade e possibilidades muito maiores do que a simples união

do hipertexto com a multimídia, gerando dificuldade para entender o potencial da hipermídia.

Como entender, por exemplo, a criação de links animados, que aparecem apenas durante um

determinado período de um vídeo e que, ao serem selecionados, geram resultados baseados em

buscas semânticas?

Também foi visto que os modelos e metodologias hipertexto/desktop não se adequaram

às necessidades da hipermídia/web. Assim, vários pesquisadores procuram modelos que con-

sigam expressar os conceitos hipermídia e trabalhar com as diferenças do desenvolvimento

web, como limites menores de tempo e menor entendimento sobre as possibilidades. Discutiu-

se o problema da abordagem convencional para codificação dos documentos, sendo necessário

codificar, salvar o documento em um servidor e recarregar a página para finalmente visualizar

o resultado. Esse ciclo, conhecido como “editar-salvar-atualizar”, pode desestimular testes e

diminuir a produtividade do programador.

Em seguida, foram mostradas algumas características das linguagens de script e que elas

se tornam ideais para uma linguagem de descrição hipermídia. Destacou-se a possibilidade

de rápida prototipação através de uma linha comando, porém, com limitações em relação a

persistência. Finalizando, foi introduzido o conceito de inteligência artificial, mostrando as

principais abordagens seguidas ao longo da história.

Na Seção 2.2, foram apresentadas as características que uma ferramenta para desenvolvi-

mento hipermídia deve ter. No próximo capítulo, serão identificadas as características conside-

radas mais importantes para uma ferramenta de desenvolvimento especificamente web, anali-

sando algumas ferramentas encontradas no mercado.

20

3 Trabalhos relacionados

Ferramentas para desenvolvimento hipermídia/web tentam diminuir o esforço do usuário

enquanto aumentam sua capacidade de expressão. Elas são necessárias para fazer a ponte entre

o código que o computador entende e a intenção do usuário. Essa é uma tarefa difícil e se torna

ainda mais difícil se levado em consideração que muitas vezes o usuário nem sabe o que quer,

ou mesmo sabendo, não tem a habilidade de fazer a programação exigida. Dessa forma, as

ferramentas disponibilizam editores gráficos no estilo “arrastar e soltar”, barras de ferramen-

tas, caixa de propriedades etc. Os usuários leigos podem criar aplicações através de assistentes

de criação. Os usuários mais avançados podem visualizar o código gerado automaticamente e

alterá-lo com a ajuda de destaque e complementação de código. Algumas ferramentas utilizam

o conceito de computação nas nuvens, tornando os dados acessíveis de qualquer lugar, e dispen-

sando instalações no computador do usuário. Outras seguem o paradigma desktop, necessitando

de espaço no computador do usuário, mas ainda independente do acesso à Internet.

A seguir, serão apresentadas algumas ferramentas para o desenvolvimento web encontradas

no mercado. As aplicações vistas neste capítulo são focadas no desenvolvimento web, por

isso ignoram as funcionalidades para o desenvolvimento hipermídia propostas por Bieber et al.

(1997a) e Christodoulou et al. (1998), apresentadas no capítulo anterior. Este trabalho con-

sidera importantes para uma ferramenta de desenvolvimento especificamente web as seguintes

características:

• Plataforma da ferramenta: se a ferramenta é desktop e, portanto, depende de instalaçãoe recursos do computador, ou é uma aplicação nas nuvens, portanto, independente de

instalação e acessível a partir de qualquer computador conectado à Internet;

• Pré-visualização WYSIWYG: a aplicação deve disponbilizar uma interface gráfica quepermita posicionar os elementos através do recurso de “arrastar e soltar” com o mouse,

sem necessidade de escrita de código, o que facilita o trabalho para leigos;

• Execução de mídias interna ao editor: no caso de aplicações web, as mídias importantesde serem executadas são os componentes do lado do servidor;

3.1 Caspio Bridge 21

• Tipo de aplicação suportado: se a ferramenta permite a criação de aplicações genéricasou aplicações baseadas em modelos.

3.1 Caspio Bridge

Caspio Bridge (CASPIO, 2009) é uma aplicação web que oferece uma plataforma para criar

e publicar aplicações web baseadas em banco de dados de forma rápida e sem a necessidade de

programação. Sendo fornecida como um serviço na Internet, não é necessário instalar no com-

putador do usuário. A criação de tabelas, formulários e relatórios é feita através de assistentes

de criação, como ilustrado na Figura 3.1. É possível aplicar estilos nos resultados gerados e

incrementá-los com add-ons ou customizá-los com JavaScript.

Figura 3.1: Assistente de criação do Caspio Bridge.

As aplicações são construídas a partir de modelos pré-definidos como mostrado na Figura

3.2. Para criar aplicações customizadas, o ambiente permite a edição do código HTML, mas não

oferece funcionalidades de apoio, como barra de ferramentas ou complementação e destaque

de código.

3.2 Google Sites 22

Figura 3.2: Formulário construído pelo assistente de criação do Caspio Bridge.

3.2 Google Sites

Também baseado no conceito de computação nas nuvens, o Google Sites (GOOGLE, 2009b),

ilustrado na Figura 3.3 permite a criação de sites com conteúdo multimídia. Componentes -

como imagens, vídeos, tabelas, apresentações de slides - podem ser adicionados e modificados

através de menus.

Figura 3.3: Tela de edição do Google Sites.

Para visualizar mídias dinâmicas como vídeos ou apresentações de slides é preciso salvar a

página e parar de editar, como mostrado na Figura 3.4.

3.3 Adobe Dreamweaver 23

Figura 3.4: Tela de visualização do Google Sites, após persistência.

Google Sites provê uma interface amigável para criação de websites com páginas web de

conteúdo genérico, entretanto, o ambiente não oferece suporte à utilização de JavaScript ou

linguagens de servidor, como PHP, ASP, JSP etc. Também não é oferecido acesso a bancos

de dados. Dessa forma, as páginas web construídas apresentam interatividade limitada e não

processam informações provenientes do usuário.

3.3 Adobe Dreamweaver

Uma das ferramentas líder do mercado, o Adobe Dreamweaver (ADOBE, 2009a) traz

grande suporte ao desenvolvimento de websites. É possível editar páginas graficamente ou

visualizando diretamente o código, como ilustrado na Figura 3.5. Entre auxílios oferecidos,

estão pré-visualização WYSIWYG, diversas barras de ferramentas, caixa de propriedades, assis-

tentes de criação e gerenciamento de arquivos locais e remotos. Na visualização do código, é

oferecido destaque e complementação de código para diversas linguagens, como HTML, Cold-

fusion, PHP, ASP, ASP .NET C#, JSP, JavaScript, CSS. O fato de ser uma ferramenta desktop o

torna dependente de instalação e de recursos do computador.

3.4 Aptana Studio 24

Figura 3.5: Visualização do código e WYSIWYG no Adobe Dreamweaver.

O ambiente ainda permite a comunicação com um servidor remoto através de FTP e a

possibilidade de criar templates para reutilização de código. A versão mais nova dá um passo

na direção apontada por este trabalho com a funcionalidade de visualização dinâmica. Esta

permite interagir com os componentes da página como em um browser, executando scripts do

lado do cliente. Nessa plataforma, pode-se configurar um servidor a fim de executar scripts

do lado do servidor, contudo, as requisições assíncronas não suportam envio de parâmetros.

Assim, componentes do lado do servidor que dependem de informações enviadas por usuários

são apenas parcialmente testados.

3.4 Aptana Studio

Assim como o Adobe Dreamweaver, o Aptana Studio (APTANA, 2009) também é uma

aplicação desktop. Exibido na Figura 3.6, ele é focado na construção de aplicações nas nuvens

e provê um mecanismo de gerenciamento de espaço nas nuvens e de utilização do Jaxer, um

servidor AJAX.

3.4 Aptana Studio 25

Figura 3.6: Página inicial do Aptana Studio.

A edição é feita diretamente através de código. Para facilitar essa tarefa, são fornecidos

botões que adicionam blocos comuns de código HTML, JavaScript ou CSS. Também estão

presentes as funcionalidades de complementação e destaque de código, conforme ilustrado na

Figura 3.7.

Figura 3.7: Edição no Aptana Studio feita a partir do código com complementação e destaque de código.

A visualização é feita através da instanciação de browsers disponíveis no computador, como

o Firefox ou o Internet Explorer. O ambiente ainda simula um servidor localmente, permitindo

a execução de componentes de servidor.

3.5 Resumo do capítulo 26

3.5 Resumo do capítulo

Percebendo a dificuldade do cliente de entender as possibilidades da hipermídia e a perda

de produtividade devido à distância entre a edição e a obtenção do resultado, este trabalho visa

diminuir a distância entre a codificação de documentos e a visualização de seu resultado. Dessa

forma, são consideradas importantes as funcionalidades que contribuem para a visualização do

resultado mais cedo no processo de produção, como pré-visualização WYSIWYG e a possibili-

dade de executar mídias dinâmicas, como vídeos, apresentações e componentes de servidor. De

acordo com Weiss (2007) e Shroff (2008), a ferramenta de desenvolvimento deve ser uma apli-

cação nas nuvens, permitindo a edição de documentos a partir de qualquer dispositivo ligado

à Internet, sem necessidade de downloads ou instalações. Também é considerado importante a

capacidade de um HADMS expandir para suportar funcionalidades futuras, além de se adequar

à construção de qualquer tipo de sistema hipermídia, conforme sugerido por Christodoulou et

al. (1998), para evitar a necessidade de várias ferramentas de autoria. Assim, na Tabela 3.1, são

apresentadas as funcionalidades oferecidas pelos ambientes que foram destacadas como mais

importantes para este trabalho, a saber:

• F1: Plataforma da ferramenta;

• F2: Pré-visualização WYSIWYG;

• F3: Execução de mídias interna ao editor;

• F4: Tipo de aplicação suportado.

Tabela 3.1: Requisitos de HADMSCaspio Bridge Google Sites Adobe Dreamweaver Aptana Studio

F1 web web desktop desktop

F2 não sim sim sim1

F3 sim não sim2 sim1

F4 Orientada a banco de dados Genérica2 Genérica Genérica

Neste capítulo foram identicadas as características consideradas mais importantes para uma

ferramenta de desenvolvimento web. No próximo capítulo, será apresentada a abordagem in-

terativa DIA, que, com o objetivo de permitir a execução de mídias em tempo de edição, sugere

criar um ambiente de edição em tempo de execução.1Browser intanciado dentro do editor2Não processa informações enviadas pelo usuário

27

4 DIA - Desenvolvimento Interativo deAplicações

Conforme visto no Capítulo 2, o desenvolvimento de aplicações web no estilo HTML/CSS

+ AJAX + alguma linguagem de servidor, como PHP ou ASP, leva a um ciclo conhecido como

“editar-salvar-atualizar”, que pode desestimular testes e diminuir a produtividade do progra-

mador. Percebendo a dificuldade em identificar e consertar bugs com esse ciclo, Hewitt et al.

(2008) - com o Firebug, um add-on do Firefox que provê, dentre outras funcionalidades, uma

linha de comando JavaScript - propõe um live editing, isto é, a possibilidade de editar scripts,

HTML e CSS da página que o usuário estiver acessando. É possível editar e debugar a página

inteira, ou criá-la do zero. Contudo, o Firebug não oferece nenhum mecanismo de persistência.

Se o usuário quiser publicar as alterações feitas na página, será necessário re-escrever todas as

modificações nos documentos que estão salvos no servidor. A proposta deste trabalho, então, é

simples: superar as limitações das linguagens de script, adicionando persistência ao live editing.

Da mesma forma que Beitner & Goble (1995) apontam a necessidade de “links ativos”, que

mostre, por exemplo, pedaços do vídeo que está do outro lado do link, este trabalho aponta a

necessidade de uma “programação ativa”, que mostre o resultado da aplicação durante a etapa de

desenvolvimento. Com essa motivação, surge DIA (Desenvolvimento interativo de aplicações),

uma abordagem interativa para desenvolvimento hipermídia/web. Levando em consideração as

características das linguagens de scripts, vistas na seção 2.4, DIA sugere unir componentes e

mídias de diferentes linguagens através de uma sequência de comandos de uma linguagem de

script. Após escrever cada linha, o comando é executado, mostrando seu resultado em tempo

real. O teste é feito após cada comando e a visualização do resultado acontece antes de qualquer

etapa de persistência. Dessa forma, são minimizados erros simples, como erros de digitação ou

parênteses e chaves desbalanceados. Ver o resultado de cada comando também pode trazer

maior entendimento da linguagem para o programador. A criação de protótipos também pode

melhorar o entendimento do cliente sobre a própria aplicação e sobre o que é possível ser feito.

A idéia da abordagem DIA é criar e testar protótipos rapidamente e, caso os protótipos fiquem

4 DIA - Desenvolvimento Interativo de Aplicações 28

bons, armazená-los em documentos sem a necessidade de re-escrever todo o código.

A abordagem DIA diminui o número de etapas entre a codificação e a visualização do re-

sultado quando comparada com a abordagem de desenvolvimento web convencional, conhecida

como “editar-salvar-atualizar”. Na abordagem DIA, é necessário iniciar apenas um programa, o

IDE (Integrated development environment1), tornando o resultado disponível após cada ação do

usuário. Na abordagem convencional, inicia-se o IDE e escreve-se o código. Em seguida, o do-

cumento é persistido em um servidor local ou remoto. Para visualizar o resultado, é necessário

iniciar o browser e carregar a página. Para visualizar alguma alteração, é necessário voltar ao

IDE, escrever o código, persistir, voltar ao browser e re-carregar a página. A Tabela 4.1 mostra

uma comparação entre a abordagem “editar-salvar-atualizar” e a abordagem DIA.

Tabela 4.1: Comparação entre as etapas da abordagem “Editar-salvar-atualizar” e DIA“Editar-salvar-atualizar” DIA

Iniciar IDE Iniciar IDE em tempo de execução

Ciclo de desenvolvimento: Ciclo de desenvolvimento:

Descrever Descrever

Persistir Resultado

Iniciar browser Alterar

Carregar página Novo resultado

Resultado Persistir

Voltar ao IDE

Alterar

Persistir

Voltar ao browser

Recarregar página

Novo resultado

A abordagem de desenvolvimento com linguagens de scripts é baseado em rápida pro-

totipação. Através de uma linha de comandos são construídos protótipos disponíveis após a

execução de cada comando. O resultado das alterações é acompanhado em tempo real. Ao

atingir um resultado satisfatório, o código deve ser re-escrito em um editor de textos. A Tabela

4.2 mostra uma comparação da abordagem do desenvolvimento com linguagens de scripts e a

abordagem DIA.

1Ambiente de desenvolvimento integrado.

4.1 Passos da abordagem 29

Tabela 4.2: Comparação entre as etapas da abordagem script e DIADesenvolvimento script DIA

Iniciar linha de comando Iniciar IDE em tempo de execução

Ciclo de desenvolvimento: Ciclo de desenvolvimento:

Descrever Descrever

Resultado do protótipo Resultado

Re-escrever código no editor de texto Persistir

Persistir

Carregar em ambiente real

Resultado real

4.1 Passos da abordagem

Baseada em rápida prototipação, DIA, então, sugere que seja criada, primeiramente, a in-

terface gráfica da aplicação, a partir da qual serão realizados os testes através de chamadas aos

componentes. Essa interface deve ser criada a partir de uma sequência de comandos de uma

linguagem de script. Os elementos essenciais do sistema devem ser adicionados em tempo de

execução. Dessa forma, os componentes e mídias estarão prontos para serem utilizados logo

após a execução de cada comando. A interface gráfica mostra como será possível interagir com

a aplicação. Assim, sua visualização e a possibilidade de, de fato, interagir com ela melhora o

entendimento do sistema.

Nesse ponto, um protótipo da interface gráfica está pronto para interagir com o usuário.

Antes de construir os componentes reais - que são complexos, portanto, mais custosos - podem

ser construídos componentes de testes, que simulem a lógica de negócio com respostas escritas

diretamente no código. Dessa forma, é possível mostrar rapidamente para o cliente um exemplo

da aplicação funcionando.

Idealmente, o protótipo é construído durante a reunião com o cliente, contando com sua

participação. Se a ferramenta de desenvolvimento for uma aplicação nas nuvens, enquanto o

representante faz a reunião na empresa do cliente, uma equipe de suporte pode estar preparada

na sede da empresa de desenvolvimento, acompanhando a evolução do protótipo e desenvol-

vendo alguns componentes que possam potencializar o entendimento do sistema por parte tanto

do cliente, quanto da equipe de desenvolvimento. Com um protótipo da interface gráfica, con-

tendo os elementos essenciais do sistema, a equipe responsável pelo leiaute pode trabalhar

através da definição de estilos para os elementos, criando documentos CSS (Cascading Style

4.1 Passos da abordagem 30

Sheet (LIE; BOS, 1996)) independentes. Enquanto isso, a equipe responsável pelos compo-

nentes pode implementá-los e testá-los através do protótipo, em constante evolução, da interface

gráfica.

A construção da aplicação a partir de uma sequência de comandos torna o resultado disponível

para visualização e interação logo após a execução de cada comando. Os componentes são in-

seridos e configurados no ambiente de execução. Isso quer dizer que mais do que executar as

mídias em tempo de edição, a abordagem DIA cria um ambiente de edição em tempo de execu-

ção. Além do resultado disponível mais cedo no processo de desenvolvimento, uma vez que as

mídias podem ser executadas, é possível definir relacionamentos baseados em comportamentos

dinâmicos das mídias, como definição de relações de sincronismo baseado no tempo. Não só

isso, a abordagem DIA elimina a necessidade de uma pré-visualização, o resultado visualizado

é o resultado real da aplicação. Também não é necessário alternar entre IDE e o ambiente de

execução (o browser, por exemplo), pois o ambiente de edição é criado dentro do ambiente de

execução. Finalizando, a etapa de persistência dos comandos em um documento é opcional e

pode ser executada após a visualização do resultado.

Qualquer metodologia de desenvolvimento hipermídia/web pode ser escolhida para as eta-

pas de modelagem e conceitualização, uma vez que a abordagem DIA se concentra na etapa de

codificação. Seguem-se os passos:

1. Construir um protótipo da interface gráfica através de uma sequência de comandos de

uma linguagem de script: essa etapa consiste em executar comandos de uma linguagem

de script - a partir de uma linha de comando, por exemplo - para adicionar os elementos

essenciais que compõem o sistema. O protótipo inicial deve fazer a chamada a compo-

nentes de teste que exemplifiquem o funcionamento do sistema. Ao final dessa etapa, é

possível testar um exemplo de utilização da aplicação.

2. Implementar e testar os componentes da aplicação: essa etapa consiste em desenvolver

componentes ou mídias, utilizando a tecnologia que melhor atender aos requisitos de cada

componente/mídia. Os componentes podem ser testados através do protótipo da interface

gráfica.

3. Refinar leiaute: essa etapa tem o objetivo de refinar o leiaute através da definição de estilos

para os elementos da interface gráfica. Os estilos devem ser escritos em documentos CSS

referenciados pela aplicação. Essa etapa pode ser realizada concomitantemente à etapa

de implementação dos componentes.

4. Persistir o código da aplicação: uma vez atingido um resultado esperado, é possível ar-

4.2 Descrição de aplicações 31

mazenar o código executado em uma memória persistente.

Uma vez que as aplicações utilizam componentes descritos em linguagem de sistema e

linguagens de script, um ambiente DIA ideal deve dar suporte ao desenvolvimento de qualquer

tipo de componente. Porém, co

Documents

RENATO LENZ COSTA LIMA - UNIVERSIDADE ESTADUAL ......RENATO LENZ COSTA LIMA Um ambiente inteligente para desenvolvimento hipermídia/web interativo nas nuvens Dissertação de mestrado