Embed Size (px)
Citation preview
UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE CIÊNCIAS DA COMPUTAÇÃO – BACHARELADO
SISTEMA DE PROGRAMAÇÃO DE PRODUÇÃO COM
REPRESENTAÇÃO GRÁFICA UTILIZANDO
OPENGL EM JAVA
JAQUES DOUGLAS CLAUDINO
BLUMENAU 2007
2007/1-17
JAQUES DOUGLAS CLAUDINO
SISTEMA DE PROGRAMAÇÃO DE PRODUÇÃO COM
REPRESENTAÇÃO GRÁFICA UTILIZANDO
OPENGL EM JAVA
Trabalho de Conclusão de Curso submetido à Universidade Regional de Blumenau para a obtenção dos créditos na disciplina Trabalho de Conclusão de Curso II do curso de Ciências da Computação — Bacharelado.
Prof. Paulo César Rodacki Gomes, Dr. - Orientador
BLUMENAU 2007
2007/1-17
SISTEMA DE PROGRAMAÇÃO DE PRODUÇÃO COM
REPRESENTAÇÃO GRÁFICA UTILIZANDO
OPENGL EM JAVA
Por
JAQUES DOUGLAS CLAUDINO
Trabalho aprovado para obtenção dos créditos na disciplina de Trabalho de Conclusão de Curso II, pela banca examinadora formada por:
______________________________________________________ Presidente: Prof. Paulo César Rodacki Gomes, Dr. – Orientador, FURB
______________________________________________________ Membro: Prof. Mauro Marcelo Mattos, Dr. – FURB
______________________________________________________ Membro: Prof. Dalton Solano dos Reis – FURB
Blumenau, 9 de julho de 2007
Dedico este trabalho a todos aqueles que me ajudaram diretamente na realização deste, em especial à minha família, meu orientador e meus amigos.
AGRADECIMENTOS
À minha família, que soube ensinar os valores de um bom trabalho.
À empresa Multitherm Sistemas e Automação, que forneceu a idéia de desenvolver
este trabalho.
Aos meus amigos, pelos empurrões e cobranças.
Ao meu orientador, Paulo César Rodacki Gomes, por ter mostrado os caminhos e
positivismo para a conclusão deste trabalho.
Nossas dúvidas são traidoras e nos fazem perder o bem que poderíamos conquistar se não fosse o medo de errar.
William Shakespeare
RESUMO
Este trabalho descreve o desenvolvimento de um sistema de programação de produção, onde as programações são representadas em um gráfico em escala de tempo. O sistema foi desenvolvido na linguagem de programação Java, utilizando a biblioteca gráfica OpenGL para o desenvolvimento do gráfico das programações. Para poder usar a OpenGL na linguagem Java, foi utilizado a biblioteca JOGL. Utilizou-se a biblioteca Swing para a construção das interfaces do sistema.
Palavras-chave: Computação gráfica. OpenGL. Programação de produção. PCP.
ABSTRACT
This work describes the development of a production programming system, where the programmed processes are represented in a time scale chart. The system was developed in Java programming language, using OpenGL graphic library to develop the programmed processes chart. For use OpenGL in Java language, was used JOGL library. To build graphics interfaces, was used Swing library.
Key-words: Computer graphics. OpenGL. Production programming. PCP.
LISTA DE ILUSTRAÇÕES
Figura 1 – Processo de transformação......................................................................................16
Figura 2 – Gráfico de Gantt......................................................................................................18
Figura 3 – OPs programadas aleatoriamente............................................................................19
Figura 4 – OPs programadas visando minimizar o tempo de fabricação .................................19
Figura 5 – Processo de comunicação da biblioteca JOGL com a OpenGL..............................22
Quadro 1 – Código fonte da janela principal............................................................................22
Quadro 2 – Código fonte da classe Listener ..........................................................................23
Figura 6 – Execução da aplicação Java utilizando a biblioteca JOGL.....................................24
Figura 7 – Exemplo de uma interface Swing utilizando o Look and Feel Metal .....................25
Figura 8 – Exemplo de uma interface Swing utilizando o Look and Feel Windows...............25
Figura 9 – Gráfico das programações do software Preactor.....................................................27
Figura 10 – Gráfico das programações do sistema de produção da empresa Multitherm........28
Figura 11 – Gráfico de programações hipotético .....................................................................29
Figura 12 – Diagrama de casos de uso .....................................................................................31
Figura 13 – Diagrama de atividades .........................................................................................32
Figura 14 – Diagrama de estados .............................................................................................33
Figura 15 – Diagrama de pacotes .............................................................................................33
Figura 16 – Diagrama de classes do pacote data.....................................................................34
Figura 17 – Diagrama de classes do pacote graficoprogramacao.........................................37
Figura 18 – Diagrama de entidade relacionamento ..................................................................38
Figura 19 – Tela principal do sistema ......................................................................................40
Figura 20 – Viewports utilizadas no gráfico das programações ...............................................43
Quadro 3 – Código fonte que define as windows, viewports e chama funções de desenho .....44
Figura 21 – Limite da programação pai na alteração de programação.....................................46
Figura 22 – Limite da programação filha na alteração de programação ..................................46
Figura 23 – Alteração automática de programações filhas.......................................................47
Figura 24 – Programações filhas alteradas automaticamente...................................................47
Figura 25 – Localização de programações de uma OP ............................................................48
Figura 26 – Programações sem intervalo .................................................................................49
Figura 27 – Programações com intervalos das 19:00h às 21:00h ............................................49
Figura 28 – Menu popup das programações.............................................................................50
Figura 29 – Recursos e programações com bordas arredondadas ............................................51
Figura 30 – Recursos e programação com recurso de antialiasing desabilitado......................52
Figura 31 – Utilização de transparência ...................................................................................52
Figura 32 – Utilização de texturas............................................................................................53
Quadro 4 – Rotinas usadas para desenhar os shapes com cantos arredondados ......................54
Figura 33 – Tela padrão de cadastro.........................................................................................55
Quadro 5 – Comparação de recursos do gráfico das programações.........................................59
Quadro 6 – Comparação de recursos do sistema......................................................................59
Figura 34 – Execução do sistema no Linux openSUSE 10.2 ...................................................59
LISTA DE TABELAS
Tabela 1 – Comparação de desempenho ..................................................................................58
LISTA DE SIGLAS
API – Application Program Interface
AWT – Abstract Window Toolkit
DAO – Data Access Object
DTO – Data Transfer Object
ERP – Enterprise Resource Planning
GUI – Graphic User Interface
JDBC – Java Database Connectivity
JNI – Java Native Interface
MRP – Material Requirements Planning
MRP II – Manufacturing Resource Planning II
OP – Ordem de Produção
OpenGL – Open Graphics Library
PCP – Planejamento e Controle da Produção
PERT-CPM – Program Evaluation and Review Technique - Critical Path Method
RF – Requisito Funcional
RNF – Requisito Não Funcional
SGBD – Sistema Gerenciador de Banco de Dados
SQL – Structured Query Language
UML – Unified Modeling Language
TO – Transfer Object
VO – Value Object
SUMÁRIO
1 INTRODUÇÃO..................................................................................................................13
1.1 OBJETIVOS DO TRABALHO ........................................................................................14
1.2 ESTRUTURA DO TRABALHO ......................................................................................15
2 FUNDAMENTAÇÃO TEÓRICA....................................................................................16
2.1 ADMINISTRAÇÃO DA PRODUÇÃO............................................................................16
2.2 PLANEJAMENTO E CONTROLE DA PRODUÇÃO (PCP) .........................................17
2.3 GRÁFICO DE GANTT.....................................................................................................18
2.4 OBJETIVOS DA PROGRAMAÇÃO DE PRODUÇÃO..................................................19
2.5 OPENGL ...........................................................................................................................20
2.5.1 OpenGL em Java.............................................................................................................21
2.5.2 Exemplo de uma aplicação utilizando JOGL..................................................................22
2.6 SWING..............................................................................................................................24
2.7 TRABALHOS CORRELATOS........................................................................................25
2.7.1 Preactor ...........................................................................................................................26
2.7.2 Sistema de produção da empresa Multitherm Sistemas e Automação Ltda. ..................27
3 DESENVOLVIMENTO DO SISTEMA..........................................................................29
3.1 REQUISITOS PRINCIPAIS .............................................................................................29
3.2 ESPECIFICAÇÃO ............................................................................................................31
3.2.1 Diagrama de casos de uso ...............................................................................................31
3.2.2 Diagrama de atividades ...................................................................................................32
3.2.3 Diagrama de estados .......................................................................................................32
3.2.4 Diagrama de pacotes .......................................................................................................33
3.2.5 Diagrama de classes do pacote data...............................................................................34
3.2.6 Diagrama de classes do pacote graficoprogramacao...................................................35
3.2.7 Diagrama de entidade relacionamento ............................................................................38
3.3 IMPLEMENTAÇÃO ........................................................................................................39
3.3.1 Tela principal do sistema ................................................................................................39
3.3.2 Técnicas e ferramentas utilizadas....................................................................................41
3.3.3 Gráfico das Programações...............................................................................................42
3.3.3.1 Definição dos universos OpenGL.................................................................................42
3.3.3.2 Adicionar programação ................................................................................................45
3.3.3.3 Excluir programação.....................................................................................................45
3.3.3.4 Validar programação ....................................................................................................45
3.3.3.5 Alterar programação .....................................................................................................45
3.3.3.6 Executar programação ..................................................................................................47
3.3.3.7 Finalizar programação ..................................................................................................47
3.3.3.8 Localizar programação .................................................................................................48
3.3.3.9 Intervalos não produtivos .............................................................................................49
3.3.3.10 Manipulação Interativa ...............................................................................................50
3.3.3.11 Alinhamento de programações ...................................................................................50
3.3.3.12 Zoom...........................................................................................................................51
3.3.3.13 Pan ..............................................................................................................................51
3.3.3.14 Técnicas de visualização ............................................................................................51
3.3.3.15 Otimizações de renderização ......................................................................................53
3.3.4 Sistema de programação de produção.............................................................................55
3.3.4.1 Cadastro de grupo de recursos ......................................................................................55
3.3.4.2 Cadastro de recursos .....................................................................................................56
3.3.4.3 Cadastro de etapas ........................................................................................................56
3.3.4.4 Cadastro de processos...................................................................................................56
3.3.4.5 Cadastro de intervalos não produtivos..........................................................................56
3.3.4.6 Geração de OP ..............................................................................................................57
3.3.4.7 Adicionar programação ................................................................................................57
3.3.4.8 Localizar programação .................................................................................................57
3.3.4.9 Importação de dados do Sistema de Produção da Empresa Multitherm.......................58
3.4 RESULTADOS E DISCUSSÃO ......................................................................................58
4 CONCLUSÕES..................................................................................................................60
4.1 EXTENSÕES ....................................................................................................................61
REFERÊNCIAS BIBLIOGRÁFICAS .................................................................................63
13
1 INTRODUÇÃO
Na corrida para atender à demanda do mercado, as indústrias buscam soluções que as
diferenciem e aumentem a sua competitividade. Uma dessas soluções é o Planejamento e
Controle da Produção (PCP), que também está entre os principais fatores que influenciam a
produtividade industrial. Segundo Burbidge (1988, p. 27) o PCP tem como objetivo alocar a
mão-de-obra e equipamentos com o máximo de aproveitamento, sempre com a preocupação
de que os produtos produzidos sejam entregues nas datas prometidas. Para atender a estas
necessidades são desenvolvidos sistemas de programação de produção. Segundo Brito (2000,
p. 79), estes sistemas aplicam-se a todas as empresas que precisem considerar o problema de
filas de espera e seqüenciamento de operações para o balanceamento entre ocupação e
capacidade de produção. Estão incluídas por exemplo, indústrias têxteis, metalúrgicas,
cerâmicas, etc.
Sendo assim, o sistema de programação de produção é o responsável por emitir as
ordens de produção1 (OPs) a serem produzidas e liberar as OPs já finalizadas pela produção.
Deve organizar em seqüência todas as OPs seguintes, distribuindo-as em todos os recursos da
produção2, de forma que o término da OP não ultrapasse a data de entrega previamente
estipulada.
Para atender a estas necessidades, desenvolveu-se neste trabalho um sistema de
programação de produção, onde as OPs programadas são representadas graficamente para o
usuário. A representação gráfica é semelhante a um gráfico de Gantt3, onde as OPs
programadas são representadas em escala de tempo, conforme o seu tempo estimado de
duração.
O sistema possibilita o cadastramento de recursos e processos. Um processo é uma
seqüência de tarefas que podem ser feitas em um ou mais recursos. A cada tarefa é possível
definir o seu tempo estimado de duração. Após efetuar o cadastro de recursos e processos, o
sistema permite alocar os processos em seus determinados recursos. Estes processos alocados
1 Ordens de produção são seqüências de atividades que transformam um determinado produto (NOGUEIRA, 2002, p. 1), ou seja, são processos programados para serem produzidos. Uma ordem de produção geralmente é representada por uma seqüência numérica. 2 Recursos da produção são equipamentos e mão-de-obra que a empresa dispõe. 3 Gráfico de Gantt é um tipo de gráfico de barras que representa as tarefas a serem feitas em uma escala temporal. Ele também ajuda a mostrar os relacionamentos entre as tarefas (DAVIS; AQUILANO; CHASE, 2001, p. 554).
14
são chamados de programações. O sistema também possui funções para excluir, alterar,
iniciar (emitir) e finalizar (liberar) programações. Estas funções podem ser acessadas
interativamente, através do gráfico das programações.
O desenvolvimento do sistema foi feito em Java utilizando a Open Graphics Library
(OpenGL) (OPENGL, 2006) para a geração e manipulação do gráfico das programações. A
OpenGL que pode ser definida como um uma “interface para hardware gráfico”, é uma
biblioteca de rotinas gráficas e de modelagem, bidimensional (2D) e tridimensional (3D),
extremamente portável e rápida (COHEN; MANSSOUR, 2006, p. 18).
Obteve-se com a OpenGL um bom desempenho na geração do gráfico das
programações. Este é um dos diferenciais, já que alguns sistemas de programação de
produção existentes, por utilizarem recursos gráficos menos eficientes, possuem problemas de
desempenho quando a fila de programações é muito grande. Também foi possível com a
OpenGL, desenvolver um ambiente mais amigável, como por exemplo aplicação de texturas
sobre as programações, localização e identificação de relacionamentos e efeito de zoom sobre
todo o gráfico, permitindo visualizar uma quantidade maior de OPs em um período maior.
1.1 OBJETIVOS DO TRABALHO
O objetivo deste trabalho é desenvolver um sistema de programação de produção
utilizando a OpenGL para geração do gráfico das programações.
Os objetivos específicos do trabalho são:
a) disponibilizar o cadastramento de processos e recursos da produção;
b) permitir a programação de OPs;
c) representar graficamente todas as OPs programadas, semelhante a um gráfico de
Gantt;
d) permitir através do gráfico das programações, a manipulação interativa das OPs
programadas.
15
1.2 ESTRUTURA DO TRABALHO
Este trabalho está divido em quatro capítulos. O primeiro traz uma introdução ao
assunto e do que se trata o trabalho. O segundo apresenta uma fundamentação teórica dos
conhecimentos necessários para a realização do trabalho. O terceiro descreve como foi
realizado o desenvolvimento. O quarto capítulo trata das conclusões e resultados obtidos.
16
2 FUNDAMENTAÇÃO TEÓRICA
No presente capítulo são apresentados alguns aspectos teóricos relacionados ao
trabalho. Na seção 2.1 é apresentado o conceito de administração da produção. Na seção 2.2
são apresentados conceitos e funções do Planejamento e Controle da Produção (PCP). Em
seguida, na seção 2.3 é apresentado o gráfico de Gantt, uma das primeiras ferramentas de
controle de produção. Na seção 2.4 são apresentados os objetivos e benefícios da
programação de produção. Na seção 2.5 é apresentada a biblioteca gráfica OpenGL e como é
feita a sua integração na linguagem Java. Na seção 2.6 é apresentado a biblioteca Swing,
usada para desenvolver interfaces gráficas em Java. Na última seção 2.7 são descritos alguns
trabalhos correlatos.
2.1 ADMINISTRAÇÃO DA PRODUÇÃO
A Administração da Produção é o coração dos processos produtivos. Ela tem o objetivo de planejar e controlar o processo de manufatura em todos os seus níveis, incluindo materiais, equipamentos, pessoas, fornecedores e distribuidores. É através da Administração da Produção que a organização garante que suas decisões operacionais sobre o que, quando, quanto e com o que produzir e comprar sejam adequados a suas necessidades estratégicas, que por sua vez são ditadas por seus objetivos e seu mercado. (RIBEIRO, 2005).
Davis, Aquilano e Chase (2001, p. 25), definem a administração da produção como
sendo a gestão do processo de conversão de insumos, em resultados na forma de produtos
acabados e serviços. Essa conversão de insumos é denominada processo de transformação. O
processo de transformação é composto por um conjunto de componentes, que podem ser
máquinas, pessoas, ferramentas ou um sistema gerencial. Um insumo pode ser uma matéria-
prima, uma pessoa ou um produto acabado de outro processo. A figura 1 ilustra o processo de
transformação.
Fonte: Davis, Aquilano e Chase (2001, p. 25).
Figura 1 – Processo de transformação
São exemplos de transformações: física, como na manufatura; de local, como no
17
transporte; de troca, como no varejo; de estocagem, como no armazenamento; fisiológica,
como nos programas de saúde; informacional, como nas telecomunicações.
2.2 PLANEJAMENTO E CONTROLE DA PRODUÇÃO (PCP)
O PCP é o setor da indústria responsável pelo planejamento e controle da produção.
No planejamento é definido como, por quem, com que recursos, onde e quando um
determinado processo pode ser feito. No controle da produção é verificado se o desempenho
da produção está de acordo com o planejado. Caso não esteja de acordo, o planejamento deve
ser alterado para assim atender seus objetivos.
Em um sistema de manufatura, toda vez que são formulados objetivos, é necessário formular planos de como atingi-lo, organizar recursos humanos e físicos necessários para a ação, dirigir a ação dos recursos humanos sobre os recursos físicos e controlar esta ação para a correção de eventuais desvios. No âmbito da administração da produção, este processo é realizado pela função de Planejamento e Controle da Produção (PCP). (MOURA JR, 1996).
Atualmente, o PCP é considerado uma importante ferramenta da produção. O PCP é
um conceito que casa uma filosofia de planejamento com um conjunto de ferramentas para
implementar a filosofia de modo a otimizar o processo (DAVIS; AQUILANO; CHASE,
2001, p. 549).
Russomano (2000, p. 55), define o PCP como sendo a função de apoio das atividades
de produção, visando que os programas acertados previamente possam ser atendidos com
eficiência. Segundo Russomano (2000, p. 52), o PCP exerce as seguintes funções:
a) gestão de estoques: cuida da disponibilidade dos materiais necessários à produção;
b) emissão de ordens de produção: toma providências para ter a tempo todos os itens
necessários à produção, tais como matérias-prima, peças compradas, peças
fabricadas e produtos acabados;
c) programação das ordens de produção: estabelece em que recursos e quando cada
etapa do processo deve ser executada;
d) movimentação das ordens de produção: registra, informa e transfere o material
fabricado;
e) acompanhamento da produção: compara o planejamento com a execução e controla
sua correção.
Atender os prazos de entrega e aumentar a capacidade de produção, são os principais
18
objetivos do PCP. Para atender estes objetivos, deve haver um planejamento e controle da
produção. No planejamento é definido a estratégia para programar as OPs, de forma que
sejam produzidas dentro de seu prazo de entrega, visando utilizar ao máximo os recursos da
produção. Quanto melhor forem utilizados os recursos, menor será o tempo de ociosidade e
conseqüentemente haverá um aumento na capacidade de produção. Além de planejar, é
necessário controlar a produção, verificando se o desempenho da produção está de acordo
com o planejado. Caso ocorram desvios, deve-se alterar o planejamento de forma que atenda
aos objetivos. Falta de mão-de-obra e equipamentos quebrados são exemplos de desvios que
podem ocorrer no planejamento da produção.
O PCP é um elemento decisivo na estratégia das empresas para enfrentar as crescentes
exigências dos consumidores por melhor qualidade, maior variação de modelos e entregas
mais confiáveis. Por isso, existe a necessidade de se buscar uma maior eficiência nos sistemas
de PCP.
2.3 GRÁFICO DE GANTT
O gráfico de Gantt foi desenvolvido em 1917 pelo engenheiro e cientista social Henry
L. Gantt, com o objetivo de ser uma ferramenta de controle de produção (AGUIAR, 2003). O
gráfico de Gantt é formado por um retângulo divido por uma série de linhas paralelas
horizontais e verticais, como ilustrado na figura 2. As linhas verticais dividem a escala
horizontal em unidade de tempo. Já as linhas horizontais dividem o gráfico em seções,
representando as tarefas a serem realizadas (BURBIDGE, 1988, p. 193).
Fonte: Burbidge (1988, p. 194).
Figura 2 – Gráfico de Gantt
As tarefas representadas no gráfico de Gantt possuem um tempo estimado de duração
19
conhecido. Essas tarefas podem ser produtos a serem montados, peças a serem feitas, ou
operações a serem realizadas ao longo da fabricação (BURBIDGE, 1988, p. 194). Também
pode ser facilmente identificado no gráfico de Gantt, o relacionamento entre as tarefas,
permitindo assim uma visualização clara de todo o fluxo de uma OP.
2.4 OBJETIVOS DA PROGRAMAÇÃO DE PRODUÇÃO
Segundo Burbidge (1988, p. 199), os principais objetivos da programação de produção
podem ser relacionados da seguinte maneira:
a) entrega dos produtos na data prevista: este é considerado o objetivo principal da
programação. A finalidade deve ser planejar a seqüência de trabalho de tal forma
que todos os produtos sejam concluídos na data prevista;
b) tempo de fabricação mínimo: tem como objetivo produzir as OPs no menor tempo
possível, possibilitando assim, oferecer prazos de entrega mais curtos. Na figura 3
é ilustrado um gráfico de Gantt representando as OPs programadas aleatoriamente,
enquanto na figura 4, as mesmas programações foram planejadas de forma que
minimizaram o tempo de fabricação. Além da redução do tempo de fabricação
também foram diminuídos os tempos ociosos entre as programações;
Fonte: Burbidge (1988, p. 200).
Figura 3 – OPs programadas aleatoriamente
Fonte: Burbidge (1988, p. 200).
Figura 4 – OPs programadas visando minimizar o tempo de fabricação
c) tempo ocioso mínimo (máquinas): este objetivo visa a máxima utilização do
equipamento, para assim gerar uma maior produtividade;
20
d) tempo ocioso mínimo (empregados): tem como objetivo programar o trabalho de
tal forma que os empregados estejam sempre ocupados, possibilitando assim, a
minimização do custo de salários;
e) tempo de preparação mínimo: tempo de preparação é o tempo que o recurso levará
para poder iniciar a sua tarefa. Um exemplo a ser utilizado em empresas de
tinturaria, são tingimentos de cores escuras e claras em uma mesma máquina. Após
efetuado um processo de tingimento de cor escura, para tingir uma cor clara,
primeiramente a máquina deverá sofrer um processo de lavação. Este processo será
caracterizado como um tempo de preparação. Para minimizar os tempos de
preparação neste exemplo, bastaria agrupar em seqüência todas as OPs de cores
claras ou escuras, possibilitando assim, evitar o processo de lavação da máquina
entre uma programação e outra.
2.5 OPENGL
Segundo Shreiner et al (2005, p. 13), a OpenGL (Open Graphics Library) é uma
biblioteca que faz a interface para o hardware gráfico. Esta interface consiste em
aproximadamente 150 comandos distintos que podem ser usados para especificar objetos e
operações para produzir aplicações interativas em duas ou três dimensões.
O desenvolvimento de aplicações gráficas de alto desempenho costumava ser exclusividade de instituições de pesquisa ou empresas que dispunham de hardware gráfico veloz e especificado, além de programadores experientes. Há alguns anos, essa situação modificou-se com o surgimento do mercado de placas gráficas para computadores pessoais e o desenvolvimento de bibliotecas gráficas que não exigiam conhecimentos extensivos de programação ou de hardware. Uma dessas bibliotecas, hoje o padrão da indústria para aplicações profissionais, é a OpenGL. (COHEN; MANSSOUR, 2006, p. 15).
Pode-se definir a OpenGL como uma especificação aberta e multiplataforma de uma
biblioteca de rotinas gráficas e de modelagem utilizada para o desenvolvimento de aplicações
de Computação Gráfica, tais como jogos ou sistemas de visualização. A maior vantagem da
OpenGL é a velocidade, uma vez que incorpora vários algoritmos otimizados, incluindo o
desenho de primitivas gráficas, o mapeamento de textura e outros efeitos especiais (COHEN;
MANSSOUR, 2006, p. 15). Segundo McReynolds e Blythe (2005, p. XXIV), a OpenGL pode
ser obtida gratuitamente para quase todas as arquiteturas hoje existentes: Apple Machintosh,
Microsoft Windows e praticamente todos Unix com algumas variantes incluindo Linux e
21
OS/2.
Na próxima seção é apresentada uma das formas para implementar aplicações
OpenGL, utilizando a linguagem de programação Java.
2.5.1 OpenGL em Java
Existe mais de uma alternativa para implementar aplicações OpenGL utilizando a
linguagem de programação Java. Entretanto, de acordo com a página oficial da API OpenGL,
o projeto JOGL é a implementação de referência de uma API que permite o desenvolvimento
de programas Java com OpenGL (COHEN; MANSSOUR, 2006, p. 364).
A JOGL não é uma nova implementação de uma interface OpenGL para acessar o
hardware gráfico, mas sim uma biblioteca que faz a ligação da linguagem Java com a
biblioteca OpenGL. Esta biblioteca OpenGL é encontrada em praticamente todos sistemas
operacionais e é ela que faz a comunicação com o hardware gráfico.
A biblioteca JOGL fornece o acesso completo à OpenGL 2.0 integrando-a com os
componentes gráficos Abstract Window Toolkit (AWT) (ZUKOWSKI, 1997) e Swing (SUN
MICROSYSTEMS, 2006). Segundo Collabnet Inc (2006a), a JOGL é open-source e seu
desenvolvimento foi iniciado em 2003 pelo Game Technology Group da Sun Microsystems.
Para poder utilizá-la, é necessário que a máquina virtual Java versão 1.4.2 (SUN
MICROSYSTEMS, 2003a) ou superior esteja instalada.
Segundo Collabnet Inc (2006b), a distribuição da JOGL para desenvolvedores contém
duas partes: uma biblioteca independente de plataforma que contém as classes em Java e outra
biblioteca que é dependente de plataforma e contém o código Java Native Interface (JNI) que
faz as chamadas às funções da OpenGL. A JNI é um padrão de programação que permite que
a máquina virtual da linguagem Java acesse bibliotecas construídas com o código nativo de
um sistema operacional (SUN MICROSYSTEMS, 2003b). No caso da JOGL, a JNI é usada
para acessar a biblioteca OpenGL, que possui código nativo.
A JOGL foi quase completamente escrita na linguagem Java. Apenas a biblioteca
dependente de plataforma foi escrita na linguagem C. Existem aproximadamente 150 linhas
desse código fonte que foram escritas a mão, sendo que 100 delas são usadas para corrigir
problemas na utilização de bibliotecas OpenGL mais antigas do sistema operacional
Windows. O restante desse código fonte foi gerado automaticamente durante o processo de
22
construção, por um utilitário chamado GlueGen (COLLABNET INC, 2006b).
A Figura 5 ilustra o processo de comunicação de uma aplicação Java com a OpenGL,
utilizando a JOGL. Como pode ser visto, a aplicação Java precisa apenas acessar a biblioteca
JOGL escrita em Java. Esta biblioteca se comunica com a biblioteca JOGL que é dependente
de plataforma. Por sua vez, esta biblioteca utiliza a JNI para se comunicar com a biblioteca
OpenGL, que também é dependente de plataforma.
Figura 5 – Processo de comunicação da biblioteca JOGL com a OpenGL
2.5.2 Exemplo de uma aplicação utilizando JOGL
Esta seção mostra um exemplo de uma aplicação utilizando a biblioteca JOGL. O
quadro 1 mostra o código fonte usado para gerar uma janela em Java. É inserido nesta janela
um componente GLCanvas. GLCanvas é um componente AWT que provê o suporte à
renderização OpenGL (SUN MICROSYSTEMS, 2005a). Há um outro componente Swing
chamado GLJPanel, mas ainda está em desenvolvimento e atualmente apresenta alguns
problemas (SUN MICROSYSTEMS, 2005b). É atribuído neste componente GLCanvas, uma
instância da classe Listener, que é apresentada no quadro 2.
import javax.media.opengl.GLCanvas;
import javax.swing.JFrame;
public class Main extends JFrame {
public Main() {
GLCanvas glCanvas = new GLCanvas(); //cria o componente de desenho
glCanvas.addGLEventListener(new Listener()); //seta nova instância da classe Listener
this.add(glCanvas);
this.setTitle("Exemplo JOGL");
this.setSize(300, 300);
this.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
this.setVisible(true);
}
public static void main(String[] args) {
new Main();
}
}
Quadro 1 – Código fonte da janela principal
23
A classe Listener implementa a interface GLEventListener que pertence à
biblioteca JOGL. Ela contém os métodos que implementam os eventos da OpenGL. São eles:
a) init: é chamado logo após inicializar a OpenGL. É usado para inicialização de
parâmetros. Neste exemplo (quadro 2), é definido a cor de fundo e definição do
universo OpenGL;
b) display: é através deste método que devem ser enviados os comandos OpenGL
para desenhar os objetos desejados. Neste exemplo, são enviados os comandos para
definir a cor de desenho e para desenhar um quadrado e o texto “Exemplo JOGL”;
c) reshape: é chamado toda vez que o componente de desenho é redimensionado;
d) displayChanged: é chamado ao alterar propriedades de vídeo do sistema
operacional, como resolução e quantidade de cores.
import com.sun.opengl.util.GLUT;
import javax.media.opengl.GL;
import javax.media.opengl.GLAutoDrawable;
import javax.media.opengl.GLEventListener;
import javax.media.opengl.glu.GLU;
public class Listener implements GLEventListener {
private GLU glu = new GLU();
private GLUT glut = new GLUT();
private int width, height; //atributos utilizados para definir o tamanho da viewport
public void init(GLAutoDrawable gLAutoDrawable) {
GL gl = gLAutoDrawable.getGL();
gl.glClearColor(1.0f, 1.0f, 1.0f, 1.0f); //define cor de fundo (branco)
gl.glViewport(0, 0, width, height); //define viewport
gl.glMatrixMode(GL.GL_PROJECTION);
gl.glLoadIdentity();
glu.gluOrtho2D(-10.0f, 10.0f, -10.0f, 10.0f); //define window
}
public void display(GLAutoDrawable gLAutoDrawable) {
GL gl = gLAutoDrawable.getGL();
gl.glClear(GL.GL_COLOR_BUFFER_BIT);
gl.glColor3f(0.0f, 0.0f, 0.0f); //define cor de pintura (preto)
gl.glBegin(GL.GL_LINE_LOOP); //desenha um quadrado
gl.glVertex2f(5.0f, 5.0f);
gl.glVertex2f(5.0f, -5.0f);
gl.glVertex2f(-5.0f, -5.0f);
gl.glVertex2f(-5.0f, 5.0f);
gl.glEnd();
gl.glPushMatrix(); //desenha o texto "Exemplo JOGL"
gl.glTranslatef(-5.0f, 6.0f, 0.0f);
gl.glScalef(0.011f, 0.011f, 0.0f);
glut.glutStrokeString(glut.STROKE_ROMAN, "Exemplo JOGL");
gl.glPopMatrix();
}
public void reshape(GLAutoDrawable gLAutoDrawable, int x, int y, int width, int height) {
this.width = width;
this.height = height;
}
public void displayChanged(GLAutoDrawable gLAutoDrawable, boolean b, boolean b0) {
}
}
Quadro 2 – Código fonte da classe Listener
24
A figura 6 ilustra a execução da aplicação Java utilizando a biblioteca JOGL.
Figura 6 – Execução da aplicação Java utilizando a biblioteca JOGL
2.6 SWING
Swing é uma biblioteca de classes para construir interfaces gráficas em ambientes
desktop, na linguagem de programação Java. Tecnicamente é chamada de Graphic User
Interface (GUI) toolkit. GUI toolkits são a base para a construção de interfaces gráficas. Elas
são compostas por componentes widgets, que podem ser janelas, menus, botões, tabelas,
caixas de texto, entre outros.
Nas primeiras versões do Java, a única forma de fazer programas gráficos era através
da Abstract Window Toolkit (AWT). A AWT é uma GUI composta por bibliotecas de baixo-
nível que dependem de código nativo da plataforma onde roda. Ela traz alguns problemas de
compatibilidade entre as plataformas, fazendo que nem sempre o programa tenha aparência
desejada em todos os sistemas operacionais, sendo também mais difícil de ser usada. Para
suprir as necessidades cada vez mais freqüentes de uma API mais estável e fácil de usar, o
Swing foi criado como uma extensão do Java a partir da versão 1.2. Swing fornece
componentes de mais alto nível, possibilitando assim uma melhor compatibilidade entre os
vários sistemas onde Java roda (STEIL, 2006).
Ao contrário da AWT, Swing não contém uma única linha de código nativo, e permite
que as aplicações tenham diferentes tipos de visuais, os chamados “Look and Feel”. Já com
AWT isso não é possível, tendo todos os programas a aparência da plataforma onde estão
rodando (STEIL, 2006). Nas figuras 7 e 8 são ilustradas duas imagens da mesma aplicação,
apenas mudando o seu “Look and Feel”. Na figura 7 a aplicação usa o “Look and Feel” Metal,
25
enquanto na figura 8 foi usado o “Look and Feel” Windows.
FONTE: Grouchnikov (2006).
Figura 7 – Exemplo de uma interface Swing utilizando o Look and Feel Metal
FONTE: Grouchnikov (2006).
Figura 8 – Exemplo de uma interface Swing utilizando o Look and Feel Windows
2.7 TRABALHOS CORRELATOS
Em Volkmann (1998), é apresentado um protótipo para auxiliar a programação de
produção. Este protótipo utiliza técnicas de Program Evaluation and Review Technique -
Critical Path Method (PERT-CPM) (VOLKMANN, 1998, p. 38) para programar a produção,
e técnicas de Manufacturing Resource Planning II (MRP II) (VOLKMANN, 1998, p. 17)
para planejar a produção. As técnicas de PERT-CPM são usadas para calcular a data de início
da primeira e a última tarefa de um processo. Já as técnicas de MRP II são usadas para
calcular a capacidade mensal dos recursos e para calcular a quantidade de dias com tarefas
alocadas (VOLKMANN, 1998, p. 66). A representação e manipulação das programações é
feita através de uma grade.
Em Loffi (1999), é apresentado um protótipo para controlar a utilização de recursos da
produção. Segundo Loffi (1999, p. 36), “o protótipo tem como finalidade demonstrar a
programação da produção para as indústrias de manufatura utilizando técnicas de PERT-
26
CPM.” A representação e manipulação das programações também é feita por uma grade. Há
uma função no sistema, que gera um gráfico de Gantt com todas as tarefas programadas
(LOFFI, 1999, p. 67). Não é possível manipular interativamente este gráfico. É apenas gerado
uma visualização para fins de consulta.
Nas duas seções seguintes serão apresentadas ferramentas existentes no mercado, que
desempenham papel semelhante ao trabalho proposto. Na seção 2.7.1 será apresentado o
sistema Preactor, e na seção 2.7.2 o sistema de produção da empresa Multitherm, onde o autor
deste trabalho atualmente exerce a função de desenvolvedor.
2.7.1 Preactor
O Preactor é um software especializado em programação da produção de bens e
serviços, que utiliza o conceito de seqüenciamento em capacidade finita. As programações
geradas pelo Preactor são altamente realistas e confiáveis porque respeitam a disponibilidade
efetiva dos recursos da produção, a existência de restrições operacionais, as condições de
demanda e as políticas de atendimento da empresa (PREACTOR, 2003).
O Preactor é desenvolvido pela Preactor International da Inglaterra e distribuído na
América do Sul pela empresa Tecmaran. É um sistema de programação de produção muito
completo, podendo fazer a integração com vários sistemas do tipo Enterprise Resource
Planning (ERP) e Material Requirements Planning (MRP). Segundo Preactor (2003), o
software Preactor é líder mundial em sua categoria com mais de 4.500 licenças
comercializadas para pequenas, médias e grandes empresas em todo o mundo.
Segundo Tecmaran (2004), o retorno do investimento no Preactor é medido em
semanas e os resultados chegam a:
a) 15% de aumento na produtividade;
b) 25% de redução dos estoques;
c) 40% de redução dos materiais em processo;
d) 60% de melhoria na performance de entrega.
Mesmo com todo o seu sucesso, o Preactor não utiliza recursos avançados para a
geração do gráfico das programações, que é semelhante a um gráfico de Gantt. A visualização
é composta por gráficos simples sem efeitos, o que o torna pouco amigável. A figura 9 mostra
o gráfico das programações do software Preactor. Nesta figura é apresentado um exemplo
27
aplicado a uma metalúrgica, onde pode-se verificar o nome dos recursos da produção sendo
representados verticalmente no lado esquerdo. Na área central da figura, são representadas
todas as programações de seus respectivos recursos.
Fonte: Tecmaran (2004).
Figura 9 – Gráfico das programações do software Preactor
2.7.2 Sistema de produção da empresa Multitherm Sistemas e Automação Ltda.
O sistema de produção da empresa Multitherm é um módulo do sistema de gestão
destinado ao mercado têxtil, chamado Gestum (MULTITHERM SISTEMAS E
AUTOMAÇÃO, 2006). Neste sistema de produção, além de ser possível programar as OPs, é
feita conexão a controladores de máquinas têxteis e coletores de dados, que emitem comandos
para as programações do sistema iniciarem e finalizarem. Este sistema também faz a
monitoração dos controladores das máquinas, onde os dados são informados ao usuário e
coletados para futura geração de relatórios e gráficos. Atualmente o sistema é utilizado em
lavanderias industriais, lavanderias de beneficiamento e tinturarias.
O gráfico das programações deste sistema também é semelhante a um gráfico de Gantt.
28
É possível fazer a manipulação interativa diretamente por este gráfico, como excluir, alterar,
iniciar e finalizar programações. Pode-se alterar a programação de seqüência ou de recursos,
apenas arrastando-a para a posição desejada. Este sistema é desenvolvido na linguagem
Delphi e utiliza recursos gráficos nativos, que são limitados e geram problema de desempenho
quando há uma grande quantidade de programações. Este gráfico das programações não
dispõe do recurso de zoom, o que dificulta a visualização das programações em um período
maior.
A técnica utilizada para desenvolver o gráfico das programações desse sistema não
possui um sistema de coordenadas, como existe na OpenGL. Todos os gráficos são
desenhados passando diretamente as coordenadas na tela, o que o torna complexo para
manutenção e implementação de novas técnicas, como por exemplo o recurso de zoom.
Também devido à técnica utilizada, o tempo para carregar e ajustar as programações na tela é
grande.
A figura 10 apresenta a tela principal do sistema de produção da empresa Multitherm.
Esta tela principal contém o gráfico das programações, com os recursos de produção listados à
esquerda e as OPs programadas sendo representadas na área central.
Fonte: Multitherm (2006).
Figura 10 – Gráfico das programações do sistema de produção da empresa Multitherm
29
3 DESENVOLVIMENTO DO SISTEMA
O presente capítulo descreve a especificação do projeto e detalha funcionalidades e
implementações do sistema desenvolvido.
3.1 REQUISITOS PRINCIPAIS
O sistema de programação de produção a ser implementado neste trabalho deverá:
a) ter um cadastro de recursos da produção (requisito funcional - RF);
b) ter um cadastro de processos (RF);
c) permitir a geração de OPs, sendo que cada OP deverá estar associada a um
processo (RF);
d) permitir a programação de OPs em seus determinados recursos (RF);
e) apresentar as programações graficamente, semelhante a um gráfico de Gantt. Este
gráfico será chamado de gráfico das programações. O tamanho da representação
horizontal de cada programação, deverá variar de acordo com o tempo estimado
cadastrado em seu processo. Cada linha do gráfico corresponderá a um recurso da
produção, contendo a sua descrição ao lado esquerdo de cada linha. É apresentado
na figura 11 um gráfico de programações hipotético. À esquerda da figura são
listados os recursos da produção. Ao lado de cada recurso estão representadas as
programações alocadas. No topo do gráfico há uma escala de tempo em horas.
Também são representados na figura 11 os tempos ociosos, que são os períodos em
que o recurso permanece sem produzir (RF);
Figura 11 – Gráfico de programações hipotético
f) permitir através do gráfico das programações, a manipulação interativa das OPs
30
programadas, como exclusão, alteração, emissão e liberação (RF);
g) possibilitar a aplicação de texturas sobre as OPs representadas no gráfico das
programações. Essa textura poderá ser definida ao gerar uma nova OP. Um
exemplo a ser usado em empresas têxteis, poderia ser uma imagem identificando
artigos jeans ou malha, com suas respectivas cores. Sendo assim, essa textura
poderá ser aplicada nas OPs programadas, facilitando a identificação dos processos
que estão sendo produzidos (RF);
h) identificar no gráfico das programações, as OPs que estão com a data de entrega
em atraso. Ao gerar uma nova OP, o usuário deverá fornecer a data de entrega
prevista. Após programar a OP, caso o término estimado ultrapasse a data de
entrega definida, as programações desta OP serão realçadas no gráfico. Sendo
assim, caso o usuário queira cumprir a data de entrega, ele deverá alterar as
programações para seqüências que atendam ao término estimado (RF);
i) ter o recurso de localizar OPs no gráfico das programações. Esta função realçará no
gráfico das programações, apenas as programações da OP informada. Todas as
demais programações deverão ficar com cores transparentes, para que a OP
localizada possa ser melhor visualizada. Também deverão ser apresentadas setas,
apontado os relacionamentos entre as programações da OP localizada (RF);
j) ter o recurso de zoom. Este recurso poderá ser aplicado em todo o gráfico das
programações, permitindo assim uma melhor visualização das OPs programadas
em um período maior (RF);
k) ter o recurso de pan. Este recurso permite a rolagem vertical e horizontal do gráfico
das programações (RF);
l) ser implementado na linguagem de programação Java (requisito não-funcional –
RNF);
m) utilizar a OpenGL para a geração e manipulação interativa do gráfico das
programações (RNF);
n) utilizar a biblioteca JOGL (COLLABNET INC, 2006a) para acesso às funções da
OpenGL (RNF);
o) utilizar a biblioteca Swing (SUN MICROSYSTEMS, 2006) para a criação de
interfaces (RNF);
p) ser portável (RNF).
31
3.2 ESPECIFICAÇÃO
Para especificação deste trabalho é utilizada a Unified Modeling Language (UML),
com auxílio da ferramenta Enterprise Architect (SPARX SYSTEMS, 2007), para gerar os
diagramas de casos de uso, de atividades, de estados e de classes. Para gerar o diagrama de
entidade relacionamento, foi utilizada a ferramenta PowerDesigner (SYBASE, 2007).
3.2.1 Diagrama de casos de uso
O diagrama de casos de uso ilustrado na figura 12 retrata todos os casos de uso
existentes entre o usuário e o sistema. No gráfico das programações o usuário dispõe das
funções para adicionar, excluir, validar, alterar, iniciar, finalizar e localizar programações.
Também poderá executar as operações de zoom e pan. No sistema que utiliza o gráfico das
programações, será possível cadastrar grupos de recursos, recursos, etapas, processos,
intervalos não produtivos e gerar OP.
Figura 12 – Diagrama de casos de uso
32
3.2.2 Diagrama de atividades
Na figura 13 é apresentado o diagrama de atividades do sistema. Ao abrir o sistema, o
usuário poderá executar operações de:
a) cadastros do sistema;
b) programação, onde poderá ser feito várias operações sobre elas;
c) gerar OP;
d) visualização do gráfico, onde poderá ser alterado zoom e pan;
e) fechamento do sistema.
Figura 13 – Diagrama de atividades
3.2.3 Diagrama de estados
Uma programação poderá ter um dos seguintes estados: programado, executando ou
produzido. Conforme pode ser visto na figura 14, o estado “programado” é atribuído ao
33
programar uma OP na produção. O estado “executando” é atribuído ao iniciar uma
programação na produção. Por fim, o estado “produzido” é atribuído ao finalizar uma
programação em estado “executando”, ou ao validar uma programação que está em estado
“programado”.
Figura 14 – Diagrama de estados
3.2.4 Diagrama de pacotes
Na figura 15 é ilustrado o diagrama de pacotes do sistema desenvolvido. O sistema foi
desenvolvido de forma que o gráfico das programações fosse totalmente independente da
aplicação. Todas as classes referentes ao gráfico das programações estão no pacote
graficoprogramacao, enquanto as classes do sistema estão no pacote producao. As classes
que podem ser vistas no pacote producao, são as interfaces do sistema. O pacote data contém
as classes que fazem recuperação e persistência no banco de dados. O pacote images contém
as imagens utilizadas nos botões das interfaces. E o pacote importacao contém as classes que
fazem a importação de dados do sistema de produção da empresa Multitherm. O pacote
graficoprogramacao e suas classes são apresentadas na seção 3.2.6.
Figura 15 – Diagrama de pacotes
34
3.2.5 Diagrama de classes do pacote data
O pacote data contém todas as classes necessárias para fazer recuperação e
persistência no banco de dados. A figura 16 ilustra o diagrama de classes do pacote data. A
classe DbConnection é utilizada para estabelecer uma conexão com o SGBD. Ela utiliza o
padrão de projeto Singleton (GAMMA, 1995, p. 127), para assim garantir uma única instância
e também neste caso, apenas uma única conexão com o SGBD. O pacote data contém outros
3 pacotes:
a) dao: as classes deste pacote utilizam o padrão de projeto Data Access Object
(DAO) (ALUR; CRUPI; MALKS, 2004, p. 416), com exceção da classe BaseDAO,
que herda todas as outras classes DAO. A classe BaseDAO contém funções que
facilitam a implementações das classes herdadas. Estas classes contém os métodos
que implementam os comandos SQL para recuperação e gravação de dados no
banco;
b) vo: as classes deste pacote utilizam o padrão de projeto Value Object (VO)
(FOWLER, 2003a). Estas classes não são herdadas de nenhuma outra classe e
contém apenas seus atributos e os métodos de recuperação e atribuição. Elas são
utilizadas na recuperação de dados do banco;
c) service: as classes deste pacote utilizam o padrão de projeto Session Facade
(ALUR; CRUPI; MALKS, 2004, p. 303). São nestas classes que são
implementadas as lógicas de negócio. No sistema desenvolvido, elas são usadas
para implementar a geração e programação de OPs.
Figura 16 – Diagrama de classes do pacote data
35
3.2.6 Diagrama de classes do pacote graficoprogramacao
A figura 17 ilustra o diagrama de classes do gráfico das programações. Neste diagrama
foram adicionados apenas os métodos e atributos relevantes para seu entendimento.
A classe GraficoProgramacao foi desenvolvida a fim de simplificar a utilização do
Gráfico das Programações. É através desta classe que são feitas as chamadas de funções para
acrescentar, excluir, validar programações, operações de zoom, pan, entre outras.
Basicamente, o sistema precisará instanciar apenas esta classe para manipular todo o gráfico
das programações.
GraficoProgListener, GraficoProgDrawer e GraficoProgOperation são as
principais classes do Gráfico das Programações. A classe GraficoProgListener implementa
as interfaces que contém os eventos da OpenGL, eventos de teclado, eventos de mouse e
também parte da manipulação interativa. Esta classe também possui os métodos para alteração
de zoom e pan. É no método display desta classe que devem ser enviados os comandos
OpenGL para a geração de desenhos desejados. Todas as rotinas que geram estes desenhos,
foram implementadas na classe GraficoProgDrawer. Estes desenhos são todos os gráficos
que podem ser vistos no gráfico das programações, como recursos de produção,
programações, escala de horas, etc. Parte do conteúdo a ser desenhado, como recursos da
produção e programações, precisam estar em alguma estrutura. Esta estrutura é acessada
através da classe GraficoProgOperation. Além de conter as estruturas, possui os métodos
para adicionar, excluir e alterar o seu conteúdo. Esta classe também possui instâncias de
outras classes que exercem diversas funções sobre o gráfico das programações. Estas classes e
suas respectivas funções são descritas a seguir.
A classe Shape possui as coordenadas e dimensões que são utilizadas para desenhar
uma barra horizontal no gráfico das programações. Esta classe é herdada por outras duas:
ShapeProg e ShapeIntervalo. ShapeProg é a representação gráfica de uma programação e
ShapeIntervalo é a representação gráfica de um intervalo de tempo não produtivo de um
recurso da produção. O tamanho horizontal de um ShapeProg é definido pelo tempo estimado
da programação. Este tempo estimado e demais informações da programação estão na classe
Programacao. Já o tamanho horizontal de um ShapeIntervalo é definido pelo seu tempo de
duração, que é encontrado na classe Intervalo. Sendo assim, todos os Shapes contidos no
gráfico das programações estarão em uma escala de tempo.
Pode-se imaginar a classe RecursoShapes como sendo uma linha horizontal do gráfico
36
das programações, onde cada linha possui um recurso da produção, uma lista de
programações e uma lista de intervalos não produtivos. É na classe Recurso que são
atribuídas informações como o seu código, descrição e índice a ser representado.
A classe LeftGenerator é uma classe muito importante utilizada pela
GraficoProgOperation. É nesta classe que é calculado a coordenada X de um Shape.
Também é usada na alteração de programação, para checar a seqüência correta na fila de
programações.
A classe ThreadAtualiza é utilizada para mover as programações que estão em
estado “executando”. A cada minuto as programações em execução são movidas para a
esquerda, respeitando assim o seu tempo de início em relação a escala de tempo.
Consequentemente, todas as programações posteriores às programações em execução também
deverão ser movidas para a esquerda.
A classe ThreadTooltip monitora a posição do mouse no gráfico das programações.
Caso o mouse permaneça posicionado mais de 500 milisegundos sobre uma programação,
então é disparado um evento para desenhar um tooltip. O tooltip contém informações da
programação, como número da OP, seqüência, tempo estimado, entre outros.
A classe HashShapeProg herda a classe HashMap e contém todos os ShapeProg
adicionados no gráfico. Ela é utilizada para facilitar a recuperação de objetos ShapeProg, já
que pode se recuperar um item através de uma chave. Neste caso, é utilizado como chave o
código da programação.
A classe LocalizaProgramacao é utilizada para auxiliar a localização de
programações no gráfico das programações. Ao localizar uma OP, são traçadas setas
indicando os relacionamentos das programações respectivas. O cálculo dos pontos necessários
para desenhar estas setas, é feito pela classe Arrow. A classe Arrow é uma adaptação do
código fonte de Coenen (2003). São passadas para a classe as coordenadas de início e fim do
segmento de reta e ela calcula as coordenadas da cabeça da seta. Sendo assim, estas
coordenadas são utilizadas para desenhar as setas que indicam o relacionamento entre as
programações.
Por fim, a classe GraficoProgTexture que é usada para carregar as texturas sobre as
programações. Texturas são imagens que poderão ser aplicadas sobre a representação gráfica
das programações. Esta classe utiliza três outras classes que estão no pacote texture:
BitmapLoader, TextureReader e ResourceRetriever. Estas três classes foram obtidas de
Eeckhoudt e Bezrati (2006) e fazem a leitura dos arquivos de textura.
37
Figura 17 – Diagrama de classes do pacote graficoprogramacao
38
3.2.7 Diagrama de entidade relacionamento
É ilustrado na figura 18, o diagrama de entidade relacionamento do banco de dados
utilizado no sistema desenvolvido. É neste banco de dados que são persistidos todos os dados
do sistema, como cadastro de recursos, etapas, processos, etc. Também são persistidas todas
as OPs geradas e programadas na produção.
Figura 18 – Diagrama de entidade relacionamento
Cada entidade ilustrada na figura 18, representa uma tabela no banco de dados. Estas
tabelas são:
a) recurso: contém todos recursos de produção cadastrados;
b) intervalo: contém todos os intervalos não produtivos cadastrados;
c) gruporecurso: contém todos os grupos de recurso cadastrados;
d) programacao: contém todas as programações do sistema, inclusive as finalizadas;
39
e) programacaopai: contém o código das programações antecessoras e sucessoras;
f) etapa: contém todas etapas cadastradas;
g) processo: contém todos processos cadastrados;
h) etapaprocesso: contém os dados que fazem a ligação da tabela etapa com a
tabela processo. Um processo pode conter várias etapas, assim como uma etapa
pode estar contida em vários processos;
i) op: contém todas as OPs geradas;
j) opetapa: contém os dados que fazem a ligação das tabelas op, etapa e
programacao. Os registros dessa tabela são inseridos ao gerar uma nova OP. A
tabela foi criada para manter a mesma ordem e quantidade de etapas pertencentes
ao processo, na situação em que é gerado a OP. Caso não fossem mantidas estas
informações, futuramente poderia ocorrer de o usuário alterar a ordem, ou inserir
novas etapas no processo. Sendo assim, perderia-se o histórico das etapas
executadas.
3.3 IMPLEMENTAÇÃO
Nas seções a seguir estão descritas as funcionalidades e implementações realizadas no
sistema.
3.3.1 Tela principal do sistema
A figura 19 ilustra a tela principal do sistema, utilizando o gráfico das programações.
As principais funções foram identificadas e numeradas na figura, sendo elas:
1) barra de menu: contém os menus Programação, Cadastro e Zoom. O menu
Programação contém as funções de manipulação das programações, sendo elas:
adicionar, excluir, validar, alterar e importar dados. O menu Cadastro contém os
itens que correspondem aos cadastros: grupo de recursos, recursos, etapa, processo
e intervalos. O menu Zoom contém os itens: Mais zoom, Menos zoom e Reset
zoom;
2) barra de botões: contém os botões das principais funções do sistema;
40
3) gráfico das programações: toda esta área abaixo da barra dos botões é desenhada
usando a OpenGL. Ela contém a lista de recursos da produção à esquerda e todas
as programações em sua área central;
4) hora atual: é representada por uma linha vermelha vertical e é atualizada a cada
minuto. Como pode ser visto, a hora atual no momento que foi gerada a figura 19,
era 18:00h;
5) escala de tempo: contém as horas e pontos a cada 15 minutos;
6) programação em estado “executando”;
7) localizar: deve ser informado uma OP na caixa de diálogo e pressionar a tecla enter
ou o botão Localizar para o sistema realçar todas as programações da OP
informada. Caso haja mais de uma programação, é possível navegar entre elas
pressionando novamente a tecla enter ou o botão Localizar para ir à próxima
programação. Também pode-se usar as teclas F5 a F8, que executam as respectivas
funções: primeira, anterior, próxima e última programação localizada;
8) programação em estado “produzido”;
9) recursos da produção: representa os equipamentos e mão-de-obra que a empresa
dispõe;
10) programações em estado “programado”.
Figura 19 – Tela principal do sistema
41
3.3.2 Técnicas e ferramentas utilizadas
O sistema desenvolvido neste trabalho foi implementado na linguagem Java. O gráfico
das programações utilizado no sistema, foi desenvolvido em OpenGL utilizando a biblioteca
JOGL para fazer a integração da linguagem Java com os drivers nativos da OpenGL. Para a
geração de interfaces gráficas foi utilizada a biblioteca Swing. Para a persistência dos dados
do sistema, foi utilizado o Sistema Gerenciador de Banco de Dados (SGBD) MySQL. Para o
desenvolvimento de todo o código fonte, foi utilizado o ambiente de desenvolvimento
Netbeans 5.5 (NETBEANS COMMUNITY, 2006).
Foram utilizados na implementação, os seguintes padrões de projeto:
a) Singleton (GAMMA, 1995, p. 127): utilizado na classe GraficoProgramacao,
para que a aplicação não precise criar várias instâncias, ou passar uma instância
para várias partes do sistema. Basta utilizar seu método getInstance para obter a
sua única instância;
b) Value Object (VO) (FOWLER, 2003a): também conhecido como Data Transfer
Object (DTO) (FOWLER, 2003b) ou Transfer Object (TO) (ALUR; CRUPI;
MALKS, 2004, p. 374), são classes que possuem apenas seus atributos e métodos
para atribuir e recuperar os valores dos atributos. No sistema desenvolvido, as
classes VO são utilizadas no retorno de métodos das classes DAO;
c) Data Access Object (DAO) (ALUR; CRUPI; MALKS, 2004, p. 416): é uma
camada que abstrai e encapsula o acesso a uma fonte dados, possibilitando assim,
ser feito a gravação e recuperação de dados apenas por classes DAO. No sistema
desenvolvido, as classes DAO possuem métodos que executam comandos SQL via
Java Database Connectivity (JDBC) para gravar e recuperar dados de um banco de
dados;
d) Facade (GAMMA, 1995, p. 185): classes facade tem a finalidade de abstrair
classes mais complexas. Uma classe que usa esse padrão no sistema desenvolvido,
é a GraficoProgramacao. Esta classe possui métodos que acessam métodos de
outras classes, a fim de facilitar a utilização do gráfico das programações no
sistema desenvolvido;
e) Session Facade (ALUR; CRUPI; MALKS, 2004, p. 303): é uma camada que
encapsula as regras de negócio. No sistema desenvolvido, as classes que utilizam
esse padrão são chamadas de Service.
42
3.3.3 Gráfico das Programações
O gráfico das programações é um conjunto de classes totalmente independente do
sistema desenvolvido. Para a sua utilização, o sistema apenas instancia um componente
chamado GLCanvas e uma classe chamada GraficoProgramacao, que foi apresentada na
especificação.
Nas próximas seções são apresentados detalhes da implementação do gráfico das
programações.
3.3.3.1 Definição dos universos OpenGL
Para poder criar uma área de desenho em OpenGL, deve-se que definir dois
parâmetros: window e viewport. Uma window é a definição do universo a ser trabalhado, ou
seja, a porção do plano cartesiano que será trabalhada. A viewport é a definição da área no
monitor, em que esta window será apresentada.
No desenvolvimento deste trabalho, optou-se usar 5 windows com suas respectivas
viewports. Conforme pode ser verificado na figura 20, são elas:
1) título das lista de recursos da produção, que contém apenas o texto “Recursos /
Hora”;
2) escala de tempo, que está no topo do gráfico;
3) tooltip das programações, também conhecido como hint, é uma caixa de
informações que é mostrada ao posicionar o cursor do mouse sobre uma
programação. Esta viewport é apresentada sobre a viewport da lista das
programações. Foi utilizada uma nova viewport porque o tooltip não deve mudar
de tamanho ao executar as operações de zoom in e zoom out no gráfico das
programações. O tooltip possuirá sempre as mesmas dimensões;
4) lista de recursos da produção, que está no lado esquerdo do gráfico das
programações;
5) lista das programações, que é toda a área central do gráfico, onde são representadas
as programações e é feito a manipulação interativa sobre elas.
43
Figura 20 – Viewports utilizadas no gráfico das programações
No quadro 3 é ilustrado o código fonte do método display da classe
GraficoProgramacaoListener. Neste método são definidas as windows, viewports e
chamados os métodos da classe GraficoProgramacaoDrawer que desenham os objetos na
tela.
44
public void display(GLAutoDrawable gLAutoDrawable) {
GL gl = gLAutoDrawable.getGL();
gl.glClear(GL.GL_COLOR_BUFFER_BIT);
this.gl = gl;
//glViewPort: define viewport
//glu.gluOrtho2D: define window
//Título Recursos
gl.glViewport(0, height-heightRegua, widthRecursos, heightRegua);
gl.glMatrixMode(GL.GL_PROJECTION);
gl.glLoadIdentity();
glu.gluOrtho2D(getRecursosLeft(),getRecursosRight(),getReguaBottom(),getReguaTop());
drawer.drawTituloRecursos(gl);
//Recursos
gl.glViewport(0, 0, widthRecursos, height-heightRegua);
gl.glMatrixMode(GL.GL_PROJECTION);
gl.glLoadIdentity();
glu.gluOrtho2D(getRecursosLeft(),getRecursosRight(),getWinBottom(),getWinTop());
drawer.drawRecursos(gl);
//Régua (escala de tempo)
gl.glViewport(widthRecursos, height-heightRegua, width-widthRecursos, heightRegua);
gl.glMatrixMode(GL.GL_PROJECTION);
gl.glLoadIdentity();
glu.gluOrtho2D(getWinLeft(),getWinRight(),-heightRegua, heightRegua);
drawer.drawRegua(gl);
//Programações
gl.glViewport(widthRecursos, 0, width-widthRecursos, height-heightRegua);
gl.glMatrixMode(GL.GL_PROJECTION);
gl.glLoadIdentity();
glu.gluOrtho2D(getWinLeft(),getWinRight(),getWinBottom(),getWinTop());
if (mousePress != null) {
double[] wcoords = getWindowCoordinatesByMouse(gl,mousePress);
drawer.getOperations().setShapeProgPressed(wcoords);
drawer.getOperations().setShapeProgDrag(wcoords);
}
drawer.drawDivRecursos(gl);
drawer.drawProgramacoes(gl);
drawer.drawIntervalos(gl);
drawer.drawArrowsLocaliza(gl);
drawer.drawLinhaHoraAtual(gl);
//Tooltip
if (showTooltip && (mouseMove != null) && (mousePress == null)) {
double[] wcoords = getWindowCoordinatesByMouse(gl,mouseMove);
int x=(int)wcoords[0],y=(int)wcoords[1];
ShapeProg shapeProg = drawer.getOperations().getShapeProg(x, y);
if (shapeProg != null) {
gl.glViewport(
mouseMove.getX(),
height-mouseMove.getY()-(int)drawer.getHeightTooltip(),
(int)drawer.getWidthTooltip(),
(int)drawer.getHeightTooltip());
gl.glMatrixMode(GL.GL_PROJECTION);
gl.glLoadIdentity();
glu.gluOrtho2D(
drawer.getLeftTooltip(),
drawer.getRightTooltip(),
drawer.getBottomTooltip(),
drawer.getTopTooltip());
drawer.drawShapeTooltip(gl, shapeProg);
}
}
}
Quadro 3 – Código fonte que define as windows, viewports e chama funções de desenho
45
3.3.3.2 Adicionar programação
A operação de adicionar programação é utilizada para adicionar uma nova
representação gráfica de uma programação. Para adicionar uma nova programação, deve ser
informado o recurso de produção e qual a seqüência na fila de programações. Esta seqüência
não poderá ser anterior às programações pai. Entende-se que programações pai são todas as
programações da OP, antecessoras à programação corrente.
3.3.3.3 Excluir programação
A exclusão de programações é utilizada para remover uma ou mais programações, para
que elas possam ser novamente acrescentadas em outra oportunidade. Ao excluir uma
programação, todas as programações filhas serão recursivamente excluídas. Entende-se que
programações filhas são todas as programações da OP, sucessoras à programação corrente.
3.3.3.4 Validar programação
A validação de programações consiste em remover uma ou mais programações, a fim
de informar ao sistema que a programação já foi iniciada e finalizada pela produção. Ao
validar uma programação, todas as programações pai serão recursivamente validadas.
3.3.3.5 Alterar programação
A alteração de programação consiste em alterar a programação de recurso e/ou de
seqüência na fila de programações. Portanto, ao alterar uma programação há algumas regras a
serem respeitadas:
a) uma programação só poderá ser alterada de recurso de produção, se o recurso de
destino pertencer ao mesmo grupo de recurso da posição de origem. A função do
grupo de recurso é detalhada na seção 3.3.4.1;
b) se alterar para uma seqüência menor e houver uma programação pai, então a
46
seqüência não poderá ser menor que a seqüência relacionada ao término da
programação pai. A figura 21 exemplifica esta situação, onde a programação
circulada não poderá ser alterada para uma seqüência anterior à linha que indica o
limite;
Figura 21 – Limite da programação pai na alteração de programação
c) se alterar para uma seqüência maior e tiver programações filhas no recurso de
destino, então a seqüência não poderá ser maior que da programação filha. A figura
22 exemplifica esta situação, onde a programação circulada não poderá ser alterada
para uma seqüência posterior à linha que indica o limite;
Figura 22 – Limite da programação filha na alteração de programação
d) se alterar para uma seqüência maior e não tiver programações filhas no recurso de
destino e tiver programações filhas em outros recursos que estão anteriores à
seqüência de destino, então estas programações deverão ser alteradas para
seqüências que estejam após a programação pai alterada. As figuras 23 e 24
exemplificam esta situação. A figura 23 identifica a programação a ser alterada e a
figura 24 ilustra a situação após ser feita a alteração da programação. Na figura 24
pode ser visualizado as programações filhas alteradas automaticamente. As setas
ilustram a seqüência de origem para destino.
47
Figura 23 – Alteração automática de programações filhas
Figura 24 – Programações filhas alteradas automaticamente
3.3.3.6 Executar programação
Consiste em alterar o estado da programação de “programado” para “executando”. Ao
executar uma programação, caso não esteja na primeira posição da fila, ela será alterada para
a primeira posição e então a cada minuto é atualizado a sua posição na tela. A sua posição de
início estará de acordo com a escala de tempo, que pode ser visualizada no topo do gráfico
das programações.
3.3.3.7 Finalizar programação
É a operação feita para finalizar uma programação que está executando. Ela deve ser
executada pelo sistema ao terminar uma etapa do processo no recurso. Ao finalizar a
programação, o seu tamanho não será mais ajustado, assim representando na escala de tempo
a hora que foi iniciada e finalizada.
48
3.3.3.8 Localizar programação
A localização de programações pode ser feita de duas formas: Localização por OP ou
por data de entrega em atraso. Na localização por OP, é informado o seu número e assim são
realçadas no gráfico todas suas respectivas programações. Também são traçadas setas que
representam os relacionamentos das programações. As setas oferecem uma visão clara do
fluxo da OP, ou seja, informa por quais recursos a OP passará e quais são as programações
sucessoras e antecessoras. A figura 25 ilustra a localização de programações de uma OP.
Neste exemplo são localizadas as programações da OP de número 3.
Figura 25 – Localização de programações de uma OP
Para fazer a localização por data de entrega em atraso, basta chamar seu respectivo
método. Serão realçadas no gráfico, todas as programações em que seu tempo estimado de
término ultrapasse a data de entrega fornecida ao gerar a OP. Assim é passado ao usuário uma
visão clara das programações que estão em atraso. Caso seja possível, o usuário poderá alterar
interativamente as programações, de forma que possa ser produzido dentro de seu prazo de
entrega.
49
3.3.3.9 Intervalos não produtivos
Os intervalos não produtivos são intervalos de tempo em que o recurso da produção
permanece sem executar processos. Na prática, este intervalo poderia ser um feriado, ou um
recurso em manutenção ou até mesmo um horário em que o recurso não é utilizado para
produção. Uma programação que estiver dentro de um intervalo não produtivo é
automaticamente alterado o seu tempo de término para a soma do tempo estimado de início,
com o tempo do intervalo. A figura 26 ilustra uma fila de programações sem intervalos,
enquanto na figura 27, foram adicionados intervalos para todos os recursos, das 19:00h às
21:00h. Os intervalos são representados em uma barra vertical, na cor amarelo transparente.
Pode-se ver que o tempo estimado de término das programações que possuem intervalo ficou
maior. Neste exemplo foram adicionados intervalos para todos os recursos, mas também é
possível adicionar intervalos individuais para cada recurso da produção.
Figura 26 – Programações sem intervalo
Figura 27 – Programações com intervalos das 19:00h às 21:00h
50
3.3.3.10 Manipulação Interativa
Manipulação interativa são as funções que podem ser aplicadas às programações
diretamente no gráfico das programações. As funções para excluir, validar, alterar, executar,
finalizar e localizar programações, podem ser feitas ao clicar com o botão direito sobre a
programação. Ao clicar com o botão direito é aberto um menu popup com as respectivas
funções, como pode ser verificado na figura 28.
Figura 28 – Menu popup das programações
Outro recurso de manipulação interativa é o arrasto de programações com o mouse,
também conhecido como drag & drop. Este recurso é utilizado para fazer a alteração de
programações. Para alterar uma programação, basta arrastá-la até a seqüência desejada ou
para o recurso de produção desejado. O gráfico somente deixará arrastar uma programação
para recursos pertencentes ao mesmo grupo de recurso da programação a ser alterada.
3.3.3.11 Alinhamento de programações
Alinhar uma programação significa não deixar que uma programação filha seja
representada antes do término de suas programações pai. Este alinhamento ocorre nos
seguintes casos:
a) ao abrir o sistema: todas as programações são carregadas e alinhadas;
b) após executar as operações: acrescentar, excluir, validar, executar e finalizar;
c) pela ThreadAtualiza: a cada minuto as programações em execução devem
mover-se para a esquerda, respeitando assim o seu tempo de início em relação a
escala de tempo. Como essa operação afeta as programações que estão atrás destas
programações que estão em execução, então deve-se alinhar todas estas
programações que foram afetadas.
51
3.3.3.12 Zoom
Uma operação de zoom consiste em visualizar um objeto ou conjunto de objetos mais
de perto (zoom in) ou mais afastado (zoom out). Essas operações de zoom foram
implementadas no gráfico das programações. Utilizando a operação zoom out pode-se
visualizar programações de um período maior sem precisar “rolar” a tela. Utilizando a
operação de zoom in pode-se voltar ao estado inicial, ou então ser ajustado conforme a
necessidade do usuário.
3.3.3.13 Pan
A operação de pan consiste em deslocar a janela de visualização de tal maneira que o
usuário consiga visualizar diferentes partes do universo. Ao deslocar o eixo X para mais ou
para menos, estamos respectivamente visualizando as programações posteriores ou anteriores.
Ao deslocar o eixo Y para mais ou para menos, conseguimos visualizar os primeiros ou
últimos recursos da produção cadastrados, com suas respectivas programações. No gráfico das
programações a operação de pan pode ser feita através das setas do teclado.
3.3.3.14 Técnicas de visualização
A fim de tornar o gráfico de programações uma interface amigável, foram utilizadas
algumas técnicas de visualização:
a) bordas arredondadas: conforme pode ser verificado na figura 29, foram traçados
quadrantes de círculo nas bordas dos recursos de produção e das programações;
Figura 29 – Recursos e programações com bordas arredondadas
b) antialiasing: é um recurso oferecido pela OpenGL, que suaviza linhas e polígonos.
52
Na figura 29 o recurso está habilitado, enquanto na figura 30 foi desabilitado o
recurso de antialiasing. Pode-se notar uma imperfeição no arrendamento das letras
e das bordas dos recursos e programações;
Figura 30 – Recursos e programação com recurso de antialiasing desabilitado
c) transparência: é um recurso oferecido pela OpenGL onde pode-se configurar o
nível de opacidade de linhas e polígonos. A figura 31 exemplifica a utilização de
transparência. Observa-se que as programações da OP 2 e o tooltip estão utilizando
transparência;
Figura 31 – Utilização de transparência
d) degradê: o efeito é utilizado na cor de fundo de vários componentes do gráfico,
como na pintura de fundo dos recursos da produção, no tooltip e nas programações;
e) texturas: o efeito é utilizado para aplicar uma imagem sobre a programação. Este
recurso facilita a identificação de programações. Um exemplo a ser usado em
indústrias de beneficiamento têxtil, poderia ser a identificação do tipo do tecido,
como malha ou jeans, com suas respectivas cores. A figura 32 ilustra um exemplo
de programações utilizando o recurso de textura.
53
Figura 32 – Utilização de texturas
3.3.3.15 Otimizações de renderização
Durante o desenvolvimento do trabalho, notou-se que o gráfico das programações
possuía uma lentidão ao renderizar objetos. O problema ocorria apenas quando haviam muitas
programações. A causa da lentidão era a quantidade de comandos que eram enviados para a
placa gráfica. Estavam sendo enviados os comandos para gerar todas as programações,
inclusive as que não eram visualizadas na tela. Para solucionar o problema, foram
desenvolvidas rotinas que checam se o objeto está dentro de sua window. Caso o objeto esteja
fora da window, ou seja, não é visualizado pelo usuário, então os comandos para gerar esse
objeto não são enviados para a placa gráfica. Com esta alteração, o problema foi resolvido.
Outra causa de lentidão foi o arredondamento dos cantos dos shapes que representam
as programações. Ao utilizar uma operação de zoom out serão feitos mais cálculos e enviados
mais coordenadas à placa gráfica. Ao executar muitas operações seguidas de zoom out, a
quantidade de cálculos para gerar o traçado dos quadrantes de círculo era grande, o que
causava lentidão. A solução encontrada foi otimizar o desenho do arredondamento do shape.
Foi definido um limite de quantidade de operações zoom out para traçar os quadrantes de
círculo nos shapes. A partir deste limite, não será mais traçado o quadrante de círculo, mas
sim apenas uma reta. Nestas situações de zoom out os gráficos estarão em um tamanho
pequeno, então a troca do arredondamento pela reta é praticamente imperceptível. O quadro 4
mostra o código fonte utilizado para geração do arredondamento dos shapes. A função
54
drawRoundBorderShape é utilizada para desenhar todos os shapes utilizados no gráfico das
programações. É utilizado a função drawCircleQuadrant para fazer os cantos arredondados
ou a função drawLine para substituir o arredondamento por uma reta. private void drawRoundBorderShape(GL gl, float left, float right, float top, float bottom, int vlRound,
boolean flRoundOtimized, float vlTransparency, float vlDegrade, float rgbIn[], float rgbBorder[], int
texture) {
gl.glColor4f(1.0f, 1.0f, 1.0f, vlTransparency);
float width = right-left;
float height = top-bottom;
for (int i=0; i<2; i++) { //0=interior / 1=borda
if (i == 0) {
if (texture != 0) {
gl.glBindTexture(GL.GL_TEXTURE_2D, texture);
gl.glEnable(GL.GL_TEXTURE_2D);
} else
gl.glColor4f(rgbIn[0], rgbIn[1], rgbIn[2], vlTransparency);
gl.glBegin(GL.GL_POLYGON); //interior
} else {
gl.glColor4f(rgbBorder[0], rgbBorder[1], rgbBorder[2], vlTransparency);
gl.glBegin(GL.GL_LINE_LOOP); //borda
}
//parte de cima do shape:
if (flRoundOtimized) { //substitui arredondanento por reta:
drawLine(gl, left, top-vlRound, left+vlRound, top, 0, 0);
drawLine(gl, right-vlRound, top, right, top-vlRound, width/widthTexture, 0);
} else { //cantos arredondados:
drawCircleQuadrant(gl, left, top, width, height, vlRound, 2);
drawCircleQuadrant(gl, right, top, width, height, vlRound, 1);
}
if ((i == 0) && (texture == 0)) //faz o degradê:
gl.glColor4f(rgbIn[0]-vlDegrade, rgbIn[1]-vlDegrade, rgbIn[2]-vlDegrade, vlTransparency);
//parte de baixo do shape: (deve ser feito assim por causa do degradê)
if (flRoundOtimized) { //substitui arredondanento por reta:
drawLine(gl, right, bottom+vlRound, right-vlRound, bottom,
width/widthTexture, height/heightTexture);
drawLine(gl, left+vlRound, bottom, left, bottom+vlRound, 0, height/heightTexture);
} else { //cantos arredondados:
drawCircleQuadrant(gl, right, bottom, width, height, vlRound, 4);
drawCircleQuadrant(gl, left, bottom, width, height, vlRound, 3);
}
gl.glEnd();
if ((i == 0) && (texture != 0))
gl.glDisable(GL.GL_TEXTURE_2D);
}
}
private void drawLine(GL gl, float x1, float y1, float x2, float y2, float xTexture, float yTexture) {
gl.glTexCoord2d(xTexture, yTexture); //coordenadas da textura
gl.glVertex2f(x1, y1); //coordenadas da linha
gl.glVertex2f(x2, y2);
}
private void drawCircleQuadrant(GL gl, float x, float y, float widthRect, float heightRect, int widthRaio,
int vlQuadrant) {
float rp, xp, yp; //point coords
float xRaio = x;
float yRaio = y;
int angIni = 90 * vlQuadrant;
int angFim = angIni - 90;
if ((vlQuadrant == 1) || (vlQuadrant == 2)) yRaio -= widthRaio;
if ((vlQuadrant == 1) || (vlQuadrant == 4)) xRaio -= widthRaio;
if ((vlQuadrant == 2) || (vlQuadrant == 3)) xRaio += widthRaio;
if ((vlQuadrant == 3) || (vlQuadrant == 4)) yRaio += widthRaio;
for (int ang = angIni; ang >= angFim; ang -= 30) {
rp = (ang * (float)Math.PI) / 180.0f;
xp = xRaio + (float)(widthRaio * Math.cos(rp));
yp = yRaio + (float)(widthRaio * Math.sin(rp));
gl.glTexCoord2d( //coordenadas da textura
getTextCoordX(x, xp, widthRect, vlQuadrant),
getTextCoordY(y, yp, heightRect, vlQuadrant));
gl.glVertex2d(xp,yp); //coordenadas do quadrante
}
}
Quadro 4 – Rotinas usadas para desenhar os shapes com cantos arredondados
55
3.3.4 Sistema de programação de produção
O sistema foi desenvolvido utilizando o gráfico das programações descrito
anteriormente. Neste sistema é possível criar processos, programá-los na produção, iniciar e
finalizar estas programações, podendo assim ser feito um planejamento e acompanhamento de
tudo o que está sendo produzido e o que ainda deve ser feito pela produção.
Todas as telas de cadastro do sistema são herdadas de uma tela padrão de cadastro.
Esta tela padrão é apresentada na figura 33. Na barra de botões pode ser visto os botões de
novo registro, salvar, excluir e desfazer.
Figura 33 – Tela padrão de cadastro
Nas próximas seções são descritas algumas das funcionalidades do sistema.
3.3.4.1 Cadastro de grupo de recursos
Os grupos de recursos são classificações para os recursos da produção. Esta
classificação é utilizada no cadastramento de etapas e na programação, para saber em quais
recursos as etapas poderão ser programadas. Exemplificando, uma lavanderia poderá ter
várias máquinas de lavar. Cada máquina é um recurso e todas poderão ser classificadas como
o grupo de recurso “Lavadoras”. Sendo assim, uma etapa cadastrada para o grupo
“Lavadoras” obviamente deverá ser programada para máquinas do grupo “Lavadoras”. Esta
mesma etapa jamais poderá ser programada em grupos “Centrífuga” ou “Secador”.
56
3.3.4.2 Cadastro de recursos
É o cadastro de todos os recursos da produção. Estes recursos poderão ser
equipamentos ou mão-de-obra. Exemplificando, em uma tinturaria os equipamentos poderiam
ser as máquinas de tingir, centrífugas, secadores, etc. Um dos recursos de mão-de-obra
poderia ser o controle de qualidade, que são pessoas que inspecionam se o tecido foi tingido
corretamente.
3.3.4.3 Cadastro de etapas
Uma etapa é parte de um processo a ser feito na produção. No sistema desenvolvido,
deve ser informado o grupo de recurso que a etapa pertence, o seu nome e seu tempo estimado
de duração.
3.3.4.4 Cadastro de processos
Um processo é um agrupamento de uma ou mais etapas a fim de produzir um
determinado produto. Um exemplo de processo de uma lavanderia, poderia ser composto
pelas seguintes etapas: lavar, centrifugar e secar. Para cadastrar um novo processo, dever ser
informado o seu nome e quais etapas compõem este processo.
3.3.4.5 Cadastro de intervalos não produtivos
É a interface onde são cadastrados os períodos de tempo em que os recursos ficarão
sem produzir. Para cadastrar um intervalo, deve ser informado o recurso, a hora de início e
hora de fim do intervalo.
57
3.3.4.6 Geração de OP
Uma OP é um processo a ser feito pela produção. No sistema desenvolvido, a OP é
representada por um número seqüencial. Para gerar uma nova OP, deve ser informado o
processo, sua data de entrega e a quantidade de itens a ser produzido. Opcionalmente, pode-se
informar uma cor ou uma imagem de textura. Esta cor ou textura será utilizada na
representação gráfica das OPs programadas.
3.3.4.7 Adicionar programação
É uma interface que lista todas as OPs geradas e ainda não programadas, tendo como
finalidade programar estas OPs. Ao selecionar uma OP, é listado seu processo e a primeira
respectiva etapa que ainda não foi programada. Para programar esta etapa, deve ser
selecionado o recurso da produção, a seqüência desejada na fila de programações e a
quantidade de itens a ser programado. Pode-se acrescentar várias programações dessa etapa,
até que atinja a quantidade de itens da OP. Esta função pode ser usada quando a quantidade de
itens da OP é muito grande para ser executada em um determinado recurso. Pode-se assim,
programar várias partes desta OP em um ou mais recursos.
3.3.4.8 Localizar programação
No sistema desenvolvido, as funções para localizar programações podem ser acessadas
das seguintes formas:
a) localização de programações de uma OP: pode ser acessada pela caixa de diálogo
da tela principal ou ao clicar com o botão direito sobre a programação, item
Localizar e item Programações desta OP;
b) localização de programações em atraso: deve ser clicado com o botão direito sobre
a programação, item Localizar e item Programações em atraso.
58
3.3.4.9 Importação de dados do Sistema de Produção da Empresa Multitherm
Foi implementada uma função que importa os recursos de produção e programações do
sistema de produção da Multitherm. Ao executar a função, são carregados no gráfico todos os
recursos de produção e programações do sistema da Multitherm. Com esta função, torna-se
mais fácil a comparação dos tempos de carregamento e alinhamento de programações dos
dois sistemas. Para fazer esta importação, basta informar o caminho, usuário e senha do banco
de dados do sistema da Multitherm. Esta função é acessada através da tela principal do
sistema, no menu Programação, item Importar e item Recursos e programações do
sistema de produção Multitherm.
Nesta versão do sistema, os dados importados não são persistidos no banco de dados.
São usados apenas para fins de consulta e para testar a manipulação interativa.
3.4 RESULTADOS E DISCUSSÃO
Foram executados testes de desempenho no sistema de produção da Multitherm e no
sistema desenvolvido neste trabalho. A tabela 1 contém o resultado de testes efetuados com
3000 programações. Os valores da tabela 1 são expressos em segundos. Conseguiu-se no
trabalho desenvolvido um melhor desempenho em relação ao sistema da Multitherm. Os
testes foram efetuados em um computador com 1 GB de memória RAM e processador AMD
Athlon XP 2500+ de 1833 MHz.
Tabela 1 – Comparação de desempenho
Desempenho Multitherm X TCC Multitherm TCC Carregamento Alinhamento Carregamento Alinhamento
Teste 1 38,687 s 7,847 s 1,688 s 0,031 s Teste 2 39,250 s 8,125 s 1,484 s 0,015 s Teste 3 38,954 s 7,685 s 1,453 s 0,016 s Média 38,963 s 7,885 s 1,541 s 0,020 s
É apresentado no quadro 5, a comparação de recursos e funções disponíveis no gráfico
das programações do sistema de produção da Multitherm e do sistema desenvolvido. Já no
quadro 6, é feito a comparação de funções gerais dos dois sistemas.
59
Multitherm X TCC Multitherm TCC
Pan Sim Sim Zoom Não Sim Transparência Não Sim Aplicação de cores Sim Sim Aplicação de textura Não Sim Manipulação interativa Sim Sim Localização de programações Sim Sim Setas na localização de programação Não Sim Intervalos não produtivos Sim Sim Barras de rolagem Sim Não
Quadro 5 – Comparação de recursos do gráfico das programações
Multitherm X TCC Multitherm TCC
Portável Não Sim Comunicação com controladores de processo Sim Não Comunicação com coletores de dados Sim Não
Quadro 6 – Comparação de recursos do sistema
O sistema desenvolvido mostrou-se portável, executando com facilidade nos seguintes
sistemas operacionais: Microsoft Windows XP SP2; Apple Mac OS X; Linux openSUSE
10.2. A figura 34 ilustra a execução do sistema no Linux openSUSE 10.2.
Figura 34 – Execução do sistema no Linux openSUSE 10.2
60
4 CONCLUSÕES
O aumento da competitividade das indústrias faz com que a responsabilidade dos
setores de PCP seja cada vez maior. É este o setor responsável por planejar uma boa
produtividade e cumprir as datas de entrega prometidas aos clientes. Produtividade e
comprometimento com a entrega dos produtos são fatores essenciais para o sucesso de
qualquer indústria. Torna-se assim indispensável para os setores de PCP, a utilização de um
sistema de programação de produção que possa auxiliá-los nestas tarefas.
O sistema de programação de produção desenvolvido, oferece os benefícios de
controlar as OPs para que sejam produzidas dentro de seu prazo estimado e a possibilidade de
diminuir tempos ociosos de recursos, aumentando assim a produtividade da empresa.
Benefícios estes, alcançados devido a clara representação das OPs programadas no gráfico das
programações desenvolvido.
Para a especificação do sistema, utilizou-se a ferramenta Enterprise Architect (SPARX
SYSTEMS, 2007), que mostrou-se objetiva e funcional. Para a implementação de todo código
fonte, foi utilizada a ferramenta Netbeans 5.5, que se mostrou estável e muito eficiente
durante o desenvolvimento dos códigos Java. Embora não tenham sido utilizados plugins para
a criação de interfaces, o Swing mostrou-se fácil de ser utilizado, ágil e com geração de bons
gráficos, o que ajuda no resultado de um ambiente amigável.
O foco principal do desenvolvimento do sistema, que foi a utilização da OpenGL,
mostrou-se uma poderosa API para o desenvolvimento de aplicações gráficas. Seus recursos
possibilitaram o desenvolvimento de uma interface com recursos superiores ao dos trabalhos
correlatos, além de permitir um grande ganho de desempenho em relação ao sistema da
Multitherm, conforme apresentado na seção 3.4. A expectativa inicial era de que apresentasse
resultados melhores em comparação ao sistema da Multitherm, implementado em Delphi, o
que foi confirmado ao final do trabalho.
Conseguiu-se com a OpenGL a geração de gráficos de melhor qualidade. Seus recursos
facilitaram a implementação de funções como pan, zoom, transparência, aplicação de texturas,
tudo isso combinado com um desempenho computacional favorável. Porém, cabe ressaltar
que para obtenção de uma melhor qualidade de desenho dos objetos em comparação com os
trabalhos correlatos, houve um grande esforço de desenvolvimento e conseqüentemente um
grande tempo dedicado, devido a OpenGL oferecer apenas um conjunto de primitivas
gráficas, como pontos, linhas e polígonos.
61
Em comparação com os sistemas de programação de produção estudados, pode-se
dizer que a representação gráfica do sistema desenvolvido é superior. O gráfico das
programações dos sistemas conhecidos são simples, possuindo poucos recursos de
visualização e manipulação tais como pan, zoom, drag & drop e outros, o que as tornam
interfaces pouco amigáveis. No sistema desenvolvido, o desempenho da geração do gráfico
das programações é extremamente rápido, já no sistema de produção da Multitherm, esta é
uma das suas grandes deficiências.
Também não são conhecidos sistemas de programação de produção multiplataforma.
Esta é uma das vantagens do sistema desenvolvido, podendo executar em diferentes tipos de
hardware, como da Apple ou em opções alternativas de sistema operacional, como o Linux e
o Mac OS X.
4.1 EXTENSÕES
O autor deste trabalho é o principal desenvolvedor do sistema de produção da empresa
Multitherm. Tendo em vista melhorar as deficiências deste sistema, optou-se neste trabalho
desenvolver um novo sistema visando solucionar estas deficiências, como desempenho,
interface amigável, operação de zoom, portabilidade, etc.
Pretende-se continuar desenvolvendo este sistema, a ponto de poder substituir o atual
sistema de produção da empresa Multitherm. Algumas modificações a serem feitas para que
esta migração se torne possível, são:
a) recuperação e persistência no banco de dados: deverá ser alterado para ler e gravar
dados no banco de dados do sistema da Multitherm;
b) comunicação com controladores de processo da Multitherm: os controladores de
processo são equipamentos que executam programas de lavação ou de tingimento.
São respectivamente utilizados por lavanderias industriais ou tinturarias. Um
exemplo simples de um programa de lavação poderia ser: carregar, encher,
adicionar produto detergente, ligar motor, tempo 10 minutos, soltar banho e
descarregar. Estes programas são criados por outro módulo do sistema da
Multitherm e enviados pelo sistema de produção. O sistema desenvolvido neste
trabalho, também deverá enviar estes programas para os controladores. Ao enviar
um programa para o controlador a programação é iniciada. Ao finalizar o programa
62
no controlador, o sistema é informado e assim finaliza a programação no gráfico
das programações;
c) comunicação com coletores de dados: os coletores de dados são utilizados para
informar o início e fim de programações em recursos da produção que não
possuem controladores de processo. São utilizados por exemplo em centrífugas,
secadores, controle de qualidade, etc. Ao iniciar uma programação no coletor de
dados, deverá comunicar com o sistema de programação de produção para iniciar a
programação no gráfico das programações, assim como é feito no atual sistema da
Multitherm. O mesmo procedimento é utilizado para informar a finalização de uma
programação.
63
REFERÊNCIAS BIBLIOGRÁFICAS
AGUIAR, Maurício. Gerenciando objetivamente os projetos com function points e PSM. [Rio de Janeiro], 2003. Disponível em: <http://www.metricas.com.br/Downloads/Apresentacao_PMI-Rio_2003-06-13.pdf>. Acesso em: 14 set. 2006.
ALUR, Deepak; CRUPI, John; MALKS, Dan. Core J2EE Patterns: as melhores práticas e estratégias de design. Tradução Altair Dias Caldas de Morais. 2. ed. Rio de Janeiro: Elsevier, 2004.
BRITO, Rodrigo G. F. A. Planejamento programação e controle da produção. 2. ed. São Paulo: Instituto IMAM, 2000.
BURBIDGE, John L. Planejamento e controle da produção. Tradução Luiz Henrique da Silva Cruz. 2. ed. São Paulo: Atlas, 1988.
COENEN, Franz. Line drawing applets. Liverpool, 2003. Disponível em: <http://www.csc.liv.ac.uk/~frans/COMP101/AdditionalStuff/Applets/moreApplets.html>. Acesso em: 20 mar. 2007.
COHEN, Marcelo; MANSSOUR, Isabel H. OpenGL: uma abordagem prática e objetiva. São Paulo: Novatec, 2006.
COLLABNET INC. Welcome to the JOGL API Project! [S.l.], 2006a. Disponível em: <https://jogl.dev.java.net>. Acesso em: 10 set. 2006.
______. Jogl: user's guide. [S.l.], [2006b?]. Disponível em: <https://jogl.dev.java.net/nonav/source/browse/*checkout*/jogl/doc/userguide/index.htm>. Acesso em: 26 out. 2006.
DAVIS, Mark M.; AQUILANO, Nicholas J.; CHASE, Richard B. Fundamentos da administração da produção. Tradução Eduardo D’Agord Schaan. 3. ed. Porto Alegre: Bookman, 2001.
EECKHOUDT, Pepijn V.; BEZRATI, Abdul. Pepe & Lizzie’s adventures: nehe Java ports. [S.l.], 2006. Disponível em: <http://pepijn.fab4.be/nehe/nehe-source.zip>. Acesso em: 17 abr. 2007.
FOWLER, Martin. Analysis pattern: value object. Chicago, [2003a?]. Disponível em: <http://www.martinfowler.com/ap2/valueObject.html>. Acesso em: 31 maio 2007.
64
______. P of EAA: data transfer object. Chicago, [2003b?]. Disponível em: <http://www.martinfowler.com/eaaCatalog/dataTransferObject.html>. Acesso em: 31 maio 2007.
GAMMA, Erich et al. Design patterns: Elements of reusable object-oriented software. [S.l.]: Addison-Wesley, 1995.
GROUCHNIKOV, Kirill. Proposal for common "feel" layer in look-and-feel libraries. [S.l.], 2006. Disponível em: <http://weblogs.java.net/blog/kirillcool/archive/2006/05/index.html>. Acesso em: 19 abr. 2007.
LOFFI, Marcelo. Protótipo de sistema de controle da utilização de recursos para produção das indústrias de manufatura. 1999. 70 f. Trabalho de Conclusão de Curso (Bacharelado em Ciências da Computação) - Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau, Blumenau.
MCREYNOLDS, Tom; BLYTHE, David. Advanced graphics programming using OpenGL. San Francisco: Elsevier, 2005.
MOURA JR, Armando N. C. Novas tecnologias e sistemas de administração da produção: análise do grau de integração e informatização nas empresas catarinenses. 1996. Não paginada. Dissertação (Mestrado em Engenharia de Produção e Sistemas) – Programa de Pós-graduação em Engenharia de Produção, Universidade Federal de Santa Catarina, Florianópolis. Disponível em: <http://www.eps.ufsc.br/disserta96/armando/cap3/cap3.htm>. Acesso em: 15 set. 2006.
MULTITHERM SISTEMAS E AUTOMAÇÃO. Soluções de gestão e automação Multitherm. Blumenau, 2006. Disponível em: <http://www.multitherm.com.br>. Acesso em: 10 set. 2006.
NETBEANS COMMUNITY. Welcome to NetBeans. [S.l.], 2006. Disponível em: <http://www.netbeans.org>. Acesso em: 10 set. 2006.
NOGUEIRA, Aliete M. G. S. Custeio por ordem na indústria. Rio de Janeiro, 2002. Disponível em: <http://www.estacio.br/graduacao/cienciascontabeis/resenhas/resenha_custos.doc>. Acesso em: 14 set. 2006.
OPENGL. OpenGL: the industry standard for high performance graphics. [S.l.], 2006. Disponível em: <http://www.opengl.org>. Acesso em: 10 set. 2006.
PREACTOR. Tecmaran: soluções avançadas em programação de produção com software APS. [S.l.], 2003. Disponível em: <http://www.preactor.com.br/p_produto.htm>. Acesso em: 9 set. 2006.
65
RIBEIRO, Roberto P. Estratégias de produção. Santa Maria, 2005. Disponível em: <http://www.robertor.pop.com.br/estrategias_producao.htm>. Acesso em: 15 abr. 2007.
RUSSOMANO, Victor H. PCP: planejamento e controle da produção. 6. ed. São Paulo: Pioneira, 2000.
SHREINER, Dave et al. OpenGL programming guide. 5th ed. [S.l.]: Addison-Wesley, 2005. Disponível em: <http://www.gamedev.net/download/redbook.pdf>. Acesso em: 14 set. 2006.
SPARX SYSTEMS. Enterprise Architect: UML design tools and UML CASE tools for software development. [Creswick], 2007. Disponível em: <http://www.sparxsystems.com/products/ea.html>. Acesso em: 26 maio 2007.
STEIL, Rafael. Introdução a programação gráfica em Java com Swing. [S.l.], 2006. Disponível em: <http://www.guj.com.br/java.tutorial.artigo.38.1.guj>. Acesso em: 19 abr. 2007.
SUN MICROSYSTEMS. Java 2 platform: standard edition (J2SE) 1.4.2. [Palo Alto], 2003a. Disponível em: <http://java.sun.com/j2se/1.4.2>. Acesso em: 10 set. 2006.
______. Introduction. [Palo Alto], 2003b. Disponível em: <http://java.sun.com/j2se/1.5.0/docs/guide/jni/spec/intro.html>. Acesso em: 26 out. 2006.
______. GLCanvas: JOGL API -- JSR-231 1.1.0 specification. [Palo Alto], 2005a. Disponível em: <http://download.java.net/media/jogl/builds/nightly/javadoc_public/javax/media/opengl/GLCanvas.html>. Acesso em: 23 abr. 2007.
______. GLJPanel: JOGL API -- JSR-231 1.1.0 Specification. [Palo Alto], 2005b. Disponível em: <http://download.java.net/media/jogl/builds/nightly/javadoc_public/javax/media/opengl/GLJPanel.html>. Acesso em: 23 abr. 2007.
______. Trail: creating a GUI with JFC/Swing. [Palo Alto], 2006. Disponível em: <http://java.sun.com/docs/books/tutorial/uiswing>. Acesso em: 26 out. 2006.
SYBASE. Business process modeling, application design, J2EE development: Sybase PowerDesigner – Sybase Inc. [S.l.], 2007. Disponível em: <http://www.sybase.com/products/modelingmetadata/powerdesigner>. Acesso em: 29 maio 2007.
TECMARAN. Preactor: the path to scheduling excellence. Vitória, [2004?]. Prospecto de divulgação do software.
66
VOLKMANN, Eduardo A. Um protótipo para auxiliar a programação de produção para indústrias têxteis. 1998. 115 f. Trabalho de Conclusão de Curso (Bacharelado em Ciências da Computação) - Centro de Ciências Exatas e Naturais, Universidade Regional de Blumenau, Blumenau.
ZUKOWSKI, John. Java AWT reference. [S.l.]: O’Reilly, 1997. Disponível em: <http://www.oreilly.com/catalog/javawt/book>. Acesso em: 26 out. 2006.
