Serviço de Geração de Gráfico

1. Visão Geral

Esse trabalho tem como objetivo o desenvolvimento de um sistema capaz de prover

serviços de construção de gráficos em 3D com base em parâmetros e configurações
especificadas por um usuário.

Para utilizar o serviço de construção dos gráficos, o usuário utilizará um programa

cliente que permita a entrada de instruções com regras associadas à Linguagem de Geração de
Gráfico, ou simplesmente LGG, criada durante a concepção e análise desse projeto. Depois de
submetidas, as instruções passam por um processo de análise, interpretação e processamento
para construção dos gráficos.

O sistema deve prover também um mecanismo de ajuda para auxiliar o usuário com
base em um histórico de utilização. Esse mecanismo ficará responsável por classificar os erros
cometidos pelo usuário de forma a identificar a ajuda mais adequada.

Outra restrição de uso do sistema é quanto à necessidade de autenticação do usuário

para que seja possível associar-lhe um histórico de utilização composto de: erros, facilidades,
dificuldades e classes de conhecimento específico referentes à computação gráfica, linguagem
LGG, dentre outros assuntos que poderão ser inseridos de forma dinâmica após o sistema em
funcionamento.

Para a construção dos gráficos será utilizado o GL Framework: uma biblioteca

desenvolvida com o intuito de prover a criação e representação de formas geométricas e
funções em um ambiente tridimensional. Para mais detalhes sobre o GL Framework, visite:
HTTP://www.italoherbert.com.br/projetos/gl.
2. Planejamento

Esta sessão é correspondente ao planejamento e avaliação de decisões a serem

tomadas sobre a arquitetura que podem influenciar na qualidade do serviço, levando-se em
consideração como principais os seguintes atributos de qualidade: desempenho, flexibilidade,
manutenção, adequação a mudanças, viabilidade, etc.

2.1. Centralizado X Distribuído

O Serviço de Geração de Gráficos centralizado deixa de funcionar diante de qualquer

imprevisto que impeça o funcionamento do computador hospedeiro ou do Container Web
onde o serviço está implantado, existindo também a possibilidade de sobrecarga do servidor
quando excedido o limite suportado, uma vez que, para o atendimento de cada cliente
conectado, são alocados recursos como: threads e sessões de usuário, temporizadores, etc.

Se o Serviço de Geração de Gráficos fosse distribuído, implicaria em replicar o serviço e

gerar maior possibilidade de inconsistências. Alem do mais, o sistema se tornaria mais
complexo, teria um custo mais elevado e estaria mais propenso a falhas. Porém, traria mais
desempenho e suporte para atendimento de uma demanda maior pelo serviço.

Outra decisão a ser tomada em caso de distribuir o serviço seria quanto a replicar
apenas o componente responsável pela geração de gráficos, ou, replicar também seus
componentes dependentes, o que aumentaria a disponibilidade do serviço, mas, dificultaria
ainda mais a manutenção e consistência desses componentes.

A pesar de o serviço estar centralizado por uma questão de simplicidade, os

componentes provedores e consumidores de serviço necessários na Construção do Gráfico,
estão organizados seguindo uma Arquitetura Orientada a Serviços que, em relação ao sistema
proposto, trouxe como vantagem um fraco acoplamento entre os componentes provedores de
serviço, o que resulta em maior facilidade de adequação a mudanças.

2.2. Local X Remoto

O Serviço de Geração de Gráficos segue uma arquitetura Cliente/Servidor onde o

cliente faz requisições ao servidor e espera resposta, porem, dado que o Serviço de Geração de
Gráficos dispõe de um interpretador de comandos, o processamento de instruções no lado
servidor pode se tornar inviável por uma restrição de tempo. Sendo assim, uma possível
solução seria o carregamento de recursos durante a inicialização do sistema, isso significa que
os módulos e demais recursos necessários para o funcionamento do sistema seriam baixados
de um servidor, tornando possível que, depois de inicializado, todo ou parte do processamento
possa ser feito no lado cliente. Existe também a possibilidade de manter versões desses
recursos e módulos localmente de forma a reutilizar em posteriores execuções do sistema, o
que levaria a necessidade de um gerenciamento de versões e consistência desses recursos e
módulos.

Mesmo com a grande vantagem no processamento local das instruções suportadas

pelo interpretador de comandos, para o Sistema de Geração de Gráfico, optou-se por uma
execução on-line, onde, o servidor processa, ao invés de uma instrução, um script composto
por grupos de instruções de forma a manter a flexibilidade referente à possibilidade de
integração com módulos e frameworks WEB, não perdendo em desempenho dado que as
requisições não são processadas a cada instrução digitada e necessidade de carregamento de
recursos na inicialização do sistema não é mais necessária. A desvantagem da execução on-line
está na limitação de tempo em gerar requisições a serem processadas a cada instrução
digitada, tornando viável o processamento de scripts ou grupos de instruções.
3. Documentação

A Figura 1 representa um diagrama de implantação que mostra a comunicação e

composição de alguns elementos responsáveis pelo funcionamento do sistema:

Figura 1:: Diagrama de implantação que representa alguns elementos do sistema

Como ilustra a Figura 1,

1 no lado servidor da aplicação
icação ficam componentes implantados
em um container de serviços web,
web, onde, cada componente será disponibilizado como
produtor de serviços,, de forma que possam se comunicar dadas suas dependências de uso
ilustradas em um diagrama de componentes na Figura 2.

Alguns componentes no lado servidor necessitam se comunicar com o servidor de

banco de dados através do protocolo JDBC. A comunicação cliente/servidor pode ser feita de
duas formas: via AJAX em JAVASCRIPT ou via canal de conexão estabelecido entre Applet (No
lado cliente) e Servlet implantado no container WEB utilizado: O Tomcat.. Nos dois casos a
comunicação é feita via HTTP.
HTTP
 A Figura 2 representa um diagrama de componentes e suas dependências de uso:

Figura 2:: Diagrama sobre os principais componentes do sistema

 A Figura 3 pode ilustrar através de um diagrama de atividades a forma de
comunicação entre as atividades envolvidas no processo de construção do gráfico pelo
sistema:

Figura 3:: Diagrama de atividades envolvidas na construção do gráfico

 A Figura 4 ilustra um modelo de entidade e relacionamento inicial representado
através de um diagrama de classes.
classes

Figura 4: Diagrama de classes que representa um modelo inicial de entidade e relacionamento

 Abaixo, alguns exemplos de scripts escritos em linguagem LGG:

Exemplo 1:

CREATE SHAPE BICUBIC B1;

Add SHAPE VIRTUALUNIVERSE B1;

SET VIRTUALUNIVERSE {
SCREEN {
WIDTH:500px;
HEIGHT:500px;
BACKGROUND:000F0F;
}
PROJECTION:PERSPECTIVE;
}

SET SHAPE BICUBIC B1 {

DIAGONALMESH:TRUE;
DIVISIONS:32;

DIMENSIONS {
X:300px;
Y:300px;
Z:300px;
}

APPEARANCE {
VERTEX { VISIBLE:TRUE; COLOR:0000FF; }
EDGE { VISIBLE:true; COLOR:FFFFFF; }
}
}

Exemplo 2:
CREATE SHAPE GROUP G1;
CREATE SHAPE PARALELEPIPEDO CUBO;
CREATE SHAPE BICUBIC B1;

CREATE FUNCTION3D GAUSSIAN GFUNC;

ADD SHAPE VIRTUALUNIVERSE G1;

ADD SHAPE VIRTUALUNIVERSE B1;

ADD SHAPE G1 CUBO;

ADD FUNCTION3D B1 GFUNC;

SET VIRTUALUNIVERSE {
SCREEN {
WIDTH:500px;
HEIGHT:500px;
BACKGROUND:000F0F;
}
PROJECTION:PERSPECTIVE;
}

SET SHAPE BICUBIC B1 {

DIAGONALMESH:TRUE;
DIVISIONS:32;

COORDINATES { X:0px; Y:0px; Z:0px; }

DIMENSIONS {
X:300px;
Y:300px;
Z:300px;
}

TRANSFORM {
ROTATION { X:320; Y:45; Z:0 }
TRANSLATION { X:0; Y:0; Z:0 }

SCALE { X:1.0; Y:1.0; Z:1.0; }

}
 APPEARANCE {
VERTEX { VISIBLE:true; COLOR:0000FF; }
EDGE { VISIBLE:true; COLOR:FFFFFF; }
}
}

SET SHAPE PARALELEPIPEDO CUBO {

DIMENSIONS { X:250px; Y:200px; Z:100px; }

TRANSFORM {
ROTATION { X:30; Y:20; Z:0 }
TRANSLATION { X:10; Y:0; Z:0 }

SCALE { X:0.3; Y:0.3; Z:0.3; }

}

APPEARANCE {
VERTEX { VISIBLE:TRUE; COLOR:FFFFFF }
EDGE { VISIBLE:TRUE; COLOR:FFFF00 }
}
}

SET FUNCTION3D GAUSSIAN GFUNC {

RADIAL:75px;
HEIGHT:200px;
}

REMOVE SHAPE VIRTUALUNIVERSE G1;