UNIVERSIDADE DO CONTESTADO CURSO DE SISTEMAS DE INFORMAO

ALISSON MLLER MEDEIROS

JAVA VOLTADO A SISTEMAS INTEGRADOS DE GESTO

CANOINHAS 2010

ALISSON MLLER MEDEIROS

JAVA VOLTADO A SISTEMAS INTEGRADOS DE GESTO

Projeto apresentado para a disciplina de TCC 02, do curso de Sistemas de Informao, da Universidade do Contestado, no 8 semestre de 2010, sob orientao do professor Jeferson Knop

CANOINHAS 2010

SUMRIO1 INTRODUO..........................................................................................................5 1.1 TEMA..................................................................................................................5 1.2 APRESENTAO .............................................................................................5 1.3 PROBLEMA.......................................................................................................6 1.4 JUSTIFICATIVA..................................................................................................7 1.5 OBJETIVOS.......................................................................................................8 1.5.1 Objetivo Geral.............................................................................................8 1.5.2 Objetivos especficos..................................................................................8 2 PROCEDIMENTO METODOLOGICO......................................................................9 3 PLANO DE METAS.................................................................................................10 4 SISTEMAS INTEGRADOS DE GESTO (ERP)....................................................11 4.1 O QUE ERP..................................................................................................11 4.2 HISTRIA DO ERP..........................................................................................11 4.3 O MERCADO DE ERP.....................................................................................11 4.4 CARACTERSTICAS.......................................................................................12 4.4.1 Contabilidade ...........................................................................................12 4.4.2 Plano de Contas.......................................................................................12 4.4.2.1 Ativo..................................................................................................12 4.4.2.2 Passivo..............................................................................................13 4.4.2.3 Despesas...........................................................................................14 4.4.2.4 Receitas.............................................................................................14 4.4.3 Custos......................................................................................................14 4.4.3.1 RKW..................................................................................................15 4.4.3.2 Custos Standart.................................................................................15 4.4.3.3 Custos...............................................................................................15 4.4.4 Compras...................................................................................................15 4.4.5 PCP (Planejamento e Controle de Produo)..........................................15 4.4.6 Faturamento..............................................................................................15 4.4.7 Livros Fiscais...........................................................................................15 4.4.8 Financeiro.................................................................................................15 4.4.9 Folha de Pagamento...............................................................................16 4.4.10 ERP Vertical............................................................................................16 4.5 BI BUSINESS INTELLIGENCE.......................................................................16 4.5.1 Data Warehouse......................................................................................16 4.6 SUPPLY CHAIN MANAGEMENT...................................................................16 4.7 METODOLOGIAS DE IMPLEMENTAO.....................................................16 5 ORIGEM DO JAVA E O CONCEITO MULTIPLATAFORMA.................................17 5.1 FUNDAMENTOS DO JAVA.............................................................................17 5.1.1 Ideia Multiplataforma................................................................................19 5.2 CARACTERISTICAS DO JAVA.......................................................................19 5.3 MAQUINA VIRTUAL........................................................................................21 5.3.1 JVM (Java Virtual Machine)......................................................................22 5.4 GARBAGE COLLECTOR (GERENCIADOR DE RECURSOS DA MEMRIA) .................................................................................................................................22 5.4.1 Funcionamento do gerenciador de memria............................................23 6 Arquitetura em Camadas......................................................................................25 6.1 Histrico...........................................................................................................25 6.2 Arquitetura 2 Camadas....................................................................................25

6.3 Arquitetura 3 Camadas (MCV).........................................................................25 6.4 Arquitetura 4 Camadas....................................................................................25 7 CRONOGRAMA......................................................................................................26

5 1 INTRODUO 1.1 TEMA

JAVA VOLTADO A SISTEMAS INTEGRADOS DE GETO 1.2 APRESENTAO

Os Sistemas Integrados de Gesto que j possuem amplo espao no mercado, apresentam uma expanso. O que era s para as grandes empresas est sendo disseminado para as pequenas e mdias. O mercado exige cada vez mais inovao, devido ao grande nmero de desenvolvedores e a popularizao de novas tecnologias. Com clientes dos mais variados tipos e metodologias que buscam solues, a qual oferecida em conjunto com uma consultoria tanto de gesto como tecnolgica.

6 1.3 PROBLEMA

Com o agrupamento de todos os processos de uma empresa em um nico Sistema, surgi o conceito de pacotes de gesto, o qual engloba as melhores prticas do mercado, independente de plataformas e dispositivos. O Sistemas Integrados de Gesto necessita de diversas ferramentas para seu desenvolvimento. Web Services, Desktop e dispositivos mveis utilizam ferramentas distintas, tornando o procedimento da manuteno de cdigo e integrao da equipe instvel. Devido a cada membro da equipe focar uma ferramenta, o deslocamento, ruptura, remoo... de um destes pode gerar dificuldades, sendo que a especialidade de cada pode comprometer o trabalho do todo, devido ao desmembramento do grupo. Com a distribuio de dispositivos mveis e acesso a internet, as bases de dados so abastecidas por vrios meios. Cada meio uma forma de acesso ao dado, o qual passa por alguns caminhos at ser globalizado. A partir disso pensamos em mensurar at que ponto possvel a criao de um software de sistema de Gesto Integrada que utilize a mesma ferramenta para cada plataforma em uma nica base de dados?

7 1.4 JUSTIFICATIVA

Os Sistemas Integrados de Gesto ganham cada vez mais espao, a multinacional SAP em 2005 contava com 700 clientes, sua meta para 2010 de 7 mil clientes. Isso atesta a expanso e o aumento de setores da economia agrupados pelo mercado. As equipes de desenvolvimento crescem e os problemas tambm. Por usar mais que uma ferramenta gera a necessidade de profissionais abranjam conhecimento nas quais so utilizadas. Com as mais diversas ferramentas a manuteno de cdigo gera procedimentos gigantescos. Utilizando de uma mesma ferramenta e a Orientao a Objetos isso pode ser diludo. Java oferece a soluo para o problema, o mesmo cdigo pode ser usado em diversas plataformas o que torna o processo de manuteno de cdigo melhorada. As informaes podem ser acessadas de vrias formas, para que possa sempre estar atualizada. Utilizar de uma nica base de dados, as informaes sempre estaro disponveis e seguras para serem utilizadas. Atravs de ferramentas que integrem as formas de acesso com o Banco de Dados, cada forma sendo adequada a plataforma pela qual ser utilizada.

8 1.5 OBJETIVOS 1.5.1 Objetivo Geral

Estudar a estrutura da plataforma Java com seus recursos voltados ao conceito de Sistemas de Gesto Integrada, tanto para aplicaes web, desktop e mvel, integradas a uma nica base de dados.

1.5.2 Objetivos especficos

Analisar o conceito de Sistemas Integrados de Gesto, seu histrico e metodologias de implementao. Realizar estudo sobre Java, para aplicaes desktop, web e moveis, e analisar meios de integrao entre as plataformas. Estudar as metodologias de desenvolvimento em camadas para Sistemas Integrados de Gesto. Estudar formas de gerencia de Banco de Dados com aplicaes distribudas e as respectivas trocas de arquivos. Demonstrar atravs da Anlise, Projeto e Desenvolvimento de um prottipo das tecnologias estudadas.

9 2 PROCEDIMENTO METODOLOGICO

Pretende-se realizar o trabalho utilizando-se os mtodos descritos a seguir: Fazer um levantamento bibliogrfico, na internet, em livros, em revistas, artigos cientficos clssicos e atuais relacionados ao tema. Este levantamento continuar ao longo de todo o desenvolvimento do trabalho; Construir o histrico da plataforma Java, descrever as principais

caractersticas de tecnologia, linguagens de programao e conectividade com o banco de dados. Elaborar analise do Mercado, histria, conceito dos Sistemas Integrados de Gesto e um pouco sobre sua implantao. Verificar a viabilidade do desenvolvimento em camadas, seus benefcios e os resultados. Aps a elaborao terica do trabalho, ser desenvolvido como estudo de caso um aplicativo sob cada plataforma, visando a concluso dos objetivos prticos, e analisando se possvel integrar as ferramentas dentro de uma mesma ferramenta.

A caracterstica do projeto, um estudo do desenvolvimento de um Sistema Integrado de Gesto atravs de Java e utilizando camadas.

10 3 PLANO DE METAS

Captulo 01: Conceito de Sistemas Integrados de Gesto Servidores; Evoluo ao longo dos anos; Mercado, Conceito e Implantao;

Captulo 02: Origem do Java; A ideia de um ambiente multiplataforma; Maquinas Virtuais; Gerenciamento de memria (Garbage Colletor);

Captulo 03: Desenvolvimento em Camadas; As vrios metodologias de desenvolvimento; O que apresenta melhores Resultados;

Captulo 04: Banco de Dados Distribudos: Integrao de base de dados; Estruturas XML;

Captulo 05: Demonstrativo Prtico: Grficos analisando o desempenho de carregamento de dados de cada aplicativo implementado; Tabela comparando os principais pontos importantes de cada plataforma; Conexo a banco de dados;

Captulo 06: Concluso;

11

CAPITULO I4 SISTEMAS INTEGRADOS DE GESTO (ERP) 4.1 O QUE ERP Para Haberkorn(2003) ERP Enterprise Resouces Planning ou Planejamento dos Recursos da Empresa o nome dado a soluo que integra todos os recessos de uma empresa, sejam eles contbeis, financeiros, de estoque, custos, compras, produo, entre outros de forma informatizada.

F S F ig a E D I o r n e c e d o r F o l- lU o P w

o r n e c e d o r

M

o v im e n t a o T t u lo s

d e B a n c o

R P e d id o d e C o m p r a s M

e c e b im e n t o e r c a d o r ia s

d e

C

o n t a s

a

P

a g a r

A

t iv o

F

ix o

L a n a m e n t o s A u t o m a t iz a d o s

L iv r o s C o t a o

F

is c a is C Q

o n t r o le d e u a li d a d e

L a n a m S F F D C lu x o e a ix a im u la o in a n c e ir a

e n t o s

E I m p o r t a o S I S C O M E X S C o li c it a o o m p r a s d e

s t o q / uM e C M

P

O R C F o n t r a t o o r n e c im d e e n t o M R P I O P r d e n s d e r o d u o e q u is i e s

r a m

e n t o

P M P V r e v is o e n d a s d e C h o M R d e F P I I a b r ic a a n u t e n o I n d u s t r ia l S im u la o P d e V e n d a r e o

o n t o

E

le t r o n ic o

F P C u s t o s

o lh a a g a m

d e e n t o

E

s t a t is t ic a C E o le t o r le t r n ic o P P C P r o d u o C u s t o s I n d ir e t o s C o n t a b il id a d e

C

lie n t e

C o n s u lt a d e I n f o r m

B a n c o a e s

P

E s t o q u e r o d u t o A

F d e c a b a M

a t u r a m C M+ V d o a r g e m

e n t o D B

S I G A E a t a W a W o r k F r u t a R e s u lt a

I S r e H o u s e lo w d o s

R B D

a z o a la n c e t e i r io

C F

o n t r a t o o r n e c im

d e L ib e r a o e n t o C r d it o

d e

L ib e r a o E s t o q u e

F

a t u r a m

e n t o

D R

u p lic a t a s e c e b e r

M

o v im e n t o T it u lo s

d e

B

a n c o

T

E

F

12 4.2 HISTRIA DO ERP Segundo Haberkorn(2003) a sigla ERP chegou ou Brasil entre a dcada de 80 e 90 devido a instalao de empresas estrangeiras do setor. A origem da sigla bastante curiosa. As primeiras grandes aplicaes comerciais, ainda na poca dos mainframes, em 1960, fui um sistema nomeado MRP I Material Requirement Planning, o qual calculava basicamente a necessidade de compra de matriasprimas e a produo de componentes a partir de previso de vendas e uma situao de estoque. Mesmo com o elevado custo para sua implantao j mostrava resultar em diminuio dos custo em relao ao processo manual. Isto, em grandes fbricas, com grandes quantidades de produtos acabados, inmeros nveis de componentes, cada um formado por um conjunto de matrias primas e utilizando quantidades diferentes. Mas, se por um lado o MRP informa o que deve ser produzido e comprado, por outro ele no diz como. E como quem d a misso deve fornecer os meios, surgiram a seguir, j na dcada de 70, os sistemas MRP II. A sigla igual mera coincidncia, da a diferenciao pelo ordinal I e II. MRP II significa Manufactoring Resiurces Planning, traduzindo Planejamento dos Recursos da Manufatura. Com o MRP II possvel saber quem vai produzir, quando e com quais recursos, ou seja, a fbrica alocada minuto a minuto, operao a operao de acordo com um calendrio pr-definido e um conjunto de recursos disponveis. Mas uma empresa no constituda somente por maquinas e materiais. Tanto o dinheiro como o pessoal fazem parte. O dinheiro controlado pelos mdulos financeiros e contbil e gente pelos sistemas de RH. A integrao entre todos eles consiste nos Sistemas Integrados de Gesto.

4.3 O MERCADO DE ERP

4.4 CARACTERSTICAS

4.4.1 Contabilidade Para Haberkorn(2003) importante destacar que a contabilidade exerce um papel fundamental em um sistema ERP, pois para l que convergem todos os dados que de alguma forma alteram o patrimnio de uma empresa. Atravs dos lanamentos so alimentadas as contas e o estoque. Alterando quantidades e acrescendo duplicatas, abastecendo todo o sistema e em consequncia valores de custo. Com isso preos de produtos so revistos e

13 duplicatas aparecem no financeiro.

4.4.2 Plano de Contas As contas necessitam ser descritas para possibilitar um bom levantamento, e no estticas para que no possa levantar a origem de seus valores. Segundo Haberkorn(1999) Dividissem em quatro grandes grupos: Ativo, Passivo, Despesas e Receitas.

4.4.2.1 Ativo

Dentro do Ativo, vem em primeiro plano o Circulante a Curto Prazo, Caixa e Bancos devem ser atribudos por conta bancria, devido a cada uma ter um extrato diferente. Dentro da conta Bancos temos ainda vrios tipos: Conta Movimento, vinculada a saques e depsitos. Inclusse tambm contas de aplicaes financeiras e 13 salrio. A Seguir temos a conta Duplicatas a Receber, que descriminada por clientes controlada individualmente pelo financeiro. Neste grupo temos as Contas Redutoras que reduzem o valor da conta-pai. Temos Tambm a conta Proviso para Devedores Duvidosos consistindo em fazer uma reserva mensal para amenizar possveis calotes. Continuando no Circulante, temos Outros Crditos de alta liquidez tais como promissrias a Receber, Cheques Pr-datados, Juros a Receber, Crditos de Funcionrios. Outra conta normalmente atribuda no Circulante o Impostos a Recuperar(ICMS e IPI). Nela, debita-se o imposto recuperado nas compras de matria-prima, j que os itens entram no estoque pelo valor liquido, ou seja, subtraindo-se os impostos recuperados. No passivo colocada a conta de impostos a pagar, contrapartida das despesas. Posteriormente se paga diferena. Encerrando o Circulante temos as contas de Estoque. Estas devem estar absolutamente coerentes com a classificao dos itens cadastrados. Entrando no Realizvel, o qual classificam-se valores depositados em investimentos mobilirios de difcil liquidez. No Ativo, temos o grupo Ativo Permanente, que na sua parte mobiliria se confunde com o Realizvel e nele podemos colocar investimentos feitos em empresas do prprio grupo, patentes e marcas. J os Ativos Imobilizados representam terrenos, edificaes, instalaes, veculos, mveis e utenslios. Como conta redutora temos Depreciao Acumulada dos itens que sofrem desgastes com o tempo, um detalhe dessa conta que ela no gera sada do caixa. E por isso aparece como entrada, somando ao lucro, no mapa de Origens de Recursos e Aplicaes.

144.4.2.2 Passivo

O passivo reflete o Ativo, porm voltado a fornecedores e compras. O ativo voltado a Clientes e vendas. O passivo dividido em Passivo Circulante, extinguvel a longo prazo e patrimnio Lquido. Vale aqui o mesmo argumento, mencionado em clientes, para a conta fornecedores. Pode ser sumarizado em uma conta, j que no Financeiro o controle individualizado. O Patrimnio Lquido, ou seja o Ativo menos o Exigvel, constitudo pelo Capital, Reservar e os Lucros Suspensos e do Exerccio. As Reservas so oriundas de valores lanados em despesas ou ativos pendentes com o propsito de reduzir-se o lucro e a conseqente distribuio, retendo-se o recurso para uma determinada finalidade. Reserva para aumento de capital, reserva legal, reserva para compra de um imvel, so exemplos que aparecem em balanos publicados. //Citao Pgina 12 passivoO Lucro dos Exerccio parte distribudo aos acionistas atravs de dividendos e parte transferido para lucros Suspensos. O Lucro Suspenso representa a resultado da empresa no distribudo aos acionistas. Tanto as Reservas como o Lucro Suspenso so depois, por deciso de assemblia, transferidos para uma conta Capital, sacramentando assim o aumento do valor da empresa. Uma parcela proporcional desse valor representa cotao de uma ao no mercado da Bolsa de Valores. Este um modelo do plano de contas sugerido pelo SIGA Advanced. Adequa-se perfeitamente ao esquema de Lanamentos Contbeis Automticos. Nada Impede, porm, que a empresa adote outros princpios. (Haberkrn, et al., 1999 p. 13)

O passivo reflete o Ativo, porm voltado a fornecedores e compras. O ativo voltado a Clientes e vendas.

4.4.2.3 Despesas

Para Haberkorn(1999) as Contas Despesa so divididas em 4 grandes grupos Custos da Mercadoria Vendida, Despesas Gerais de Fabricao, Administrativas e Vendas.

15 O Custo da Mercadoria Vendida absorve os custos de Matria prima e todas as Despesas Gerais de Fabricao. J as Despesas Administrativas e de Vendas so subtradas diretamente do resumo. No caso Despesas Gerais de Fabricao, se divide me Gastos com Pessoal, Gastos com Fabricao e Gatos Gerais. Em Gastos com pessoal consideram-se todas as despesas com salrio, horas extras e demais despesas e encargos. Nos Gastos Gerais considera-se o resto, energia eltrica, gua, esgoto, materiais de consumo... etc. Os Gastos Gerais de Produo contabilizam gastos fixos e variveis ou diretos. Enquanto a matria prima um custo tipicamente varivel as despesas administrativas so tipicamente fixas. A Contribuio Marginal basicamente o valor que a empresa ganha se produzir uma pea a mais. O fato gerador das despesas a emisso do documento que torna obrigatrio seu pagamento. Os documentos lanados no sistemas s podem ser quitados mediante seu pagamento. Existe dois regimes para fazer sua contabilizao: Regime de Competncia e Regime de Caixa. Regime de Competncia o resultado das contas que sero pagas e contabilizadas no seu respectivo ms. Regime de Caixa contabiliza as despesas mediante seu pagamento.4.4.2.4 Receitas

// pesquisar

4.4.3 Custos O Modulo de Custo totalmente integrado contabilidade. Este sem duvida um grande problema para as empresas no s pela inflao, mas pelas margens de que cada vez ficam menores em funo acirrada concorrncia global. O custo pode ser visto sob diferentes ticas. Uma delas, o custo de reposio ou standart, com base em valores atualizados e quantidade padro de cada componente. O custo real pode ainda ser calculado em moeda forte, para inibir os efeitos da inflao. Para o calculo do custo de reposio ou standart, este baseado na estrutura do produto e sua implantao permite no somente o calculo como tambm o uso do MRP I e II, as variaes de consumo de matria-prima e eficincia da mo-de-obra, a determinao dos preos de vendas e a tomada de deciso sobre o processo da fabricao de determinado item. 4.4.4 Compras Segundo Harberkorn(2003) o objetivo da informatizao do processo de Compras suprir automaticamente o estoque com base em critrios prestabelecidos e flexveis o suficiente para atender as bruscas mudanas que ocorrem na previso de vendas. Existem vrios mtodos para definir o que, quando e quanto deve ser comprado de cada item dentro de um determinado perodo. Uma metodologia recomendada o MRP I ( Material Requirement Planning

16 ou Planejamento das Necessidades de Materiais). Essa Tcnica parte de um plano de produo enquadrando as vendas e pedidos j encomendados. O futuro dividido em perodos que podem ser dias, semanas, meses e anos. O MRP I consiste em projees de saldos de estoque baseados em rotinas o sistema calcula as necessidades.

4.4.5 PCP (Planejamento e Controle de Produo) O PCP (Planejamento e Controle de Produo), por sua vez, parte do clculo das necessidades de cada item a ser produzido (MRP I) e emite as respectivas ordens de produo, em conjunto com roteiro de operaes de cargamquina (MRP II Planejamento dos Recursos de Manufatura). Uma rotina simples porm cheia de dispositivos que atendem toda a dinmica existente em uma fabrica. Mquinas e mais mquinas executando as mais variadas operaes com um calendrio repleto de horas extras, fins de semana, feriados, greves, ausncias, entre ouras possveis variaes. O roteiro de operaes definido para cada componente. Informa-se para cada operao o recurso que ela utiliza, inclusive os alternativos, a ferramenta, a durao, a descrio, o tamanho do lote padro e o tempo de setup. O sistema efetua a alocao dos recurso de forma otimizada programando a fabrica minuto a minuto, operao a operao sejam tomadas no sentido de evitar os to usuais transtornos ocorridos no dia-a-dia de uma manufatura. 4.4.6 Faturamento O faturamento uma rea onde normalmente h necessidade de fortes adaptaes e sem dvida o setor onde sempre existem diferena entre as empresas. a condio de pagamento, a poltica de reajuste de preos e descontos, o pagamento de comisses, a legislao especifica de ICMS e IPI. De qualquer forma, todas as excees apresentadas devem ser incorporadas ao sistema de modo que apenas a notal fiscal precise ser programada de forma especfica. O mdulo de faturamento controla a carteira de pedidos, administra a liberao pelo crdito e pelo estoque de forma automtica e emite todos os relatrios necessrios para o setor de vendas, alm de gerar os ttulos a receber, com base na condio de pagamento estipulada no Pedido de Venda. 4.4.7 Livros Fiscais Segundo Harberkorn (2003) o modulo fiscal existe para que se cumpra nossa complexa legislao e ele que se encarrega de emisso dos registros

17 4.4.8 Financeiro O Modulo financeiro recebe muitas informaes de outros mdulos, como ttulo a pagar gerados em compras, os ttulos a receber gerados no faturamento, dados da folha de pagamento, imposto, aluguis, emprstimo alm de outros ttulos informados com o objetivo de manter o fluxo de caixa. Outros procedimentos como transferncia eletrnicas dos ttulos para bancos, e emisso automtica de cheques, a gerao de borders, a baixa automtica de ttulos no vencimento, a tesouraria apenas se preocupa com a estratgia adotada para os recursos financeiros.

4.4.9 Folha de Pagamento

4.4.10 ERP Vertical Para Haberkorn(2003) os ERPs verticais apresentam todos os mdulos de convencionais e acresce-se especficos de determinados ramos de atividades. Alguns Exemplos de verticalizao: Automao Comercias, Sistemas de Apoio Logstico, Gesto Educacional entre outros. Cada um apresenta caractersticas especificas, os processos precisam ser mapeados e informatizados.

4.5 BI BUSINESS INTELLIGENCE

4.5.1 Data Warehouse

4.6 SUPPLY CHAIN MANAGEMENT

4.7 CRM Customer Relationship Managemente O CRM propem o atendimento one-to-one onde as necessidades , desejos e capacidade financeira passam a fazer parte das bases de dados, agora se propem ter mais informaes que apenas o valor faturado e a data da ultima compra. Com base nas informaes pode se direcionar estratgias de marketing muito mais dirigido e oficiente pois ser feito com embasamento.

18 4.8 METODOLOGIAS DE IMPLEMENTAO

19

CAPITULO II5 ORIGEM DO JAVA E O CONCEITO MULTIPLATAFORMA

Este primeiro captulo ser apresentado a origem do Java, seus conceitos e caractersticas, a ideia de um ambiente multiplataforma, caractersticas da maquina virtual, gerenciamento de memria.

5.1 FUNDAMENTOS DO JAVA

De acordo com DEITEL (2003), o Java iniciou a partir de 1991, foi projetado por um grupo de engenheiros da Sun Microsystems, a qual criou uma filial denominada First Person Inc., afim de gerenciar este projeto. Seu intuito era o desenvolvimento de tecnologias de software para dispositivos eletrnicos como aparelhos domsticos e depois tambm a televiso interativa. Conforme PARGA (2005), a Sun necessitava de uma linguagem de programao que fosse flexvel e robusta, se tratando no que seria implantado, ou seja, para estes tipos de equipamento era necessrio gerar um cdigo pequeno e deveria possui interfaces mais intuitivas do que as existentes naquela poca. Como tambm viu se que no poderia ficar amarrado em uma s arquitetura especfica, seja nos diferentes tipos hardwares e sistemas operacionais. Considerando facilidade de desenvolvimento e confiabilidade do cdigo, James Gosling, membro da equipe com mais experincia em linguagens de programao, concluiu que as vantagens que contribuam para a eficincia do C++ no compensavam o alto custo dos testes de depuraes. Segundo Gosling(1996) as linguagens em uso, C ou C++, devem ser compiladas para um chip, e se h mudanas no chip, todo o software deve ser compilado novamente. Isso encarece muito o desenvolvimento e o problema essencialmente apontado no campo da eletrnica de consumo.

20 Os engenheiros da Sun se basearam na linguagem C++ a qual era orientada a objetos, analisando o que ela oferecia de melhor e corrigindo suas falhas. Implementou se melhorias no gerenciamento oferecendo robustez e interoperabilidade, assim construram a linguagem Oak.A Sun Microsystems financiou uma pesquisa corporativa interna com o codinome Green em 1991. 0 projeto resultou no desenvolvimento de uma linguagem baseada em C e C++ que seu criador, James Gosling, chamou de Oak (carvalho) em homenagem a uma rvore que dava para a janela do seu escritrio na Sun. Descobriu-se mais tarde que j havia uma linguagem de computador chamada Oak. Quando uma equipe da Sun visitou uma cafeteria local, o nome Java (cidade de origem de um tipo de caf importado) foi sugerido e pegou. (Deitel, et al., 2003 p. 59)

O primeiro projeto que aplicou a linguagem Oak recebeu o nome de projeto Green, este consistia em um sistema de controle completo de aparelhos eletrnicos de uma casa. Para ele se construiu um ordenador experimental denominado *7 (Star Seven). O sistema apresentava uma interface baseada na representao da casa de forma animada e o controle era apresentado por meio de uma tela sensvel ao tato. Posteriormente, se aplicou a outro projeto denominado VOD(Video ON Demand) no qual foi empregado como uma interface para televiso interativa. Nenhum destes projetos transformou o em um sistema comercial, porm foram desenvolvidos inteiramente em um Java primitivo. De acordo com PARGA (2005), a First Person foi fechada em 1994 e j quando tudo parecia ter sido definitivamente esquecido, Bill Joy, cofundador da Sun, julgou que a Internet poderia chegar a ser um campo adequado para disputar mercado e viu na Oak o instrumento ideal para enfim realizar seus planos. Aps trocar o nome e modificaes de projeto, a linguagem Java foi apresentada sociedade em agosto de 1995. De acordo com GOSLING (2005) a linguagem de programao Java foi originalmente chamado Oak, sua utilizao era em aplicaes incorporadas ao consumidor final, por James Gosling. Aps vrios anos de experincia com a linguagem, e contribuies significativas por Ed Frank, Patrick Naughton, Jonathan Payne, e Chris Warth foi reformulada Internet. Com o avano da World Wide Web desde 1993, visando grande interesse para a Sun, e trazendo a partir de 1995 o suporte java em um dos primeiros navegadores de internet atravs de interface

21 chamado Mosaic. A forma final da linguagem foi definida por James Gosling, Bill Joy, Guy Steele, Richard Tuck, Frank Yellin, e Arthur van Hoff, com a ajuda de Graham Hamilton, Tim Lindholm, e muitos outros envolvidos no projeto. A enorme popularidade da World Wide Web ocorrida a partir de 1993, com o surgimento dos browsers levou reformulao do Java como uma linguagem para incorporao em programas baseados em aplicaes Web. Conforme Vernners (1997), a Internet uma rede mundial, e na WWW a parte da rede que fornece acesso multimdia a uma vasta gama de informaes. Java tornou se uma das mais importantes linguagens da web.

5.1.1 Ideia Multiplataforma

Desde quando a Sun iniciou o projeto green, que visava o desenvolvimento de tecnologias de software para equipamentos domsticos, pensava em no ficar dependente de um s ambiente operacional ainda mais produtos desta linha aos quais possua "n", tipos e modelos. Necessitou um projeto detalhado para que, se desenvolvesse este modelo de software. Mesmo o fracasso ocorrido no mercado escolhido, no desistiu se da ideia, pois esta foi uma soluo de grande importncia para os aplicativos Web, das suas primeiras aplicaes por seu nome Applets, que poderia ser executado em qualquer plataforma sem haver uma compilao especifica a cada hardware. Um passo tecnolgico no mercado de software, a qual a Sun Microsystems elencou sob o Java.

5.2 CARACTERISTICAS DO JAVA

A tecnologia Java uma ferramenta adequada para ajud lo a enfrentar os desafios e aproveitar as oportunidades apresentadas no mercado de desenvolvimento emergente. Conforme Venners (1997), o seu papel original destina

22 como uma linguagem de programao para microprocessadores incorporados em aparelhos consumidores, porm o Java foi projetado com uma srie de outras caractersticas interessantes. Java robusto, o que significa que os erros dos programas em Java no causam falhas no sistema to frequentemente como erros nas outras linguagens de programao. Alguns aspectos da linguagem permitir que muitos erros potenciais possam ser detectados antes que um programa executado. Java plataforma independente. Uma plataforma, neste contexto, apenas um determinado tipo de sistema de computador, tais como um sistema Windows, MacOS, LINUX, etc. Java tem como sua marca registrada: "Escreva uma vez, execute em qualquer lugar.". Isto significa que um programa Java pode ser executado sem modificaes em diferentes tipos de computadores. Isto no verdadeiro para outras linguagens de programao de alto nvel. Uma razo para o Java ser bem adequado para aplicaes WWW. Java foi projetado para redes. A sua aptido para ambientes em rede inerente a sua arquitetura, o que permite ser seguro, robusto e independente de plataforma assim programas distribudos atravs da internet pode ser executado em uma grande variedade de computadores. Java uma linguagem distribuda o que significa que seus programas podem funcionar em redes de computador. Alm da prpria linguagem, o Java vem com uma extensa coleo de bibliotecas de cdigo que tenha sido concebido para ser utilizado diretamente para tipos especficos de aplicaes para torn-lo muito fcil de construir sistemas de software para desktop e Internet. Esta uma das razes pelas quais o Java to bem adaptado para apoiar aplicaes em redes corporativas. Java uma linguagem segura. Destinado para uso em redes, Java contm funcionalidades que protegem contra cdigos no confiveis que possa introduzir um vrus ou corromper o sistema de alguma forma. Por exemplo, quando executado algo no navegador web, programas Java so impedidos de leitura e escrita a partir de informaes e para o seu computador desktop. Java orientado a objetos. Linguagens orientadas a objetos permitem dividir programas em mdulos separados, chamados objetos, que sintetizam o programa

23 de dados e operaes. Assim Programao Orientada para Objetos (OOP) e Projeto Orientado a Objetos (OOD) referem-se a uma forma particular de organizar programas, um que est rapidamente emergindo como a melhor abordagem para a construo de complexos sistemas de software. Ao contrrio da linguagem C++, em que possui caractersticas orientadas a objetos enxertado sob a linguagem C, Java foi concebido a partir do zero como uma linguagem orientada para objeto.

5.3 MAQUINA VIRTUAL

Marketing pessoal na Sun Microsystems para o Java: Write Once, Run Anywhere; escreva uma vez e rode em qualquer lugar, este foi o resultado que a equipe de desenvolvimento atingiu, e desta trouxe grandes facilidades para o ambiente de desenvolvimento. Mquina virtual uma abstrao de uma mquina real onde o software simula um computador executando vrios aplicativos. um ambiente operacional independente da mquina ou dispositivo em que est hospedada e sendo executada. Dessa forma, ela constitui uma plataforma, onde o sistema operacional, a memria, o processador e seus demais recursos so virtual. Conforme Engel (1999), mquina virtual o nome definido a um ambiente, como um sistema operacional que no existe fisicamente, porm executado sob outro ambiente. Segundo Wesley (2004), uma maquina virtual realiza a interpretao do cdigo intermedirio, este gerado como resultado da traduo de uma linguagem de alto nvel. Assim garantida a portabilidade do cdigo do programa. Isso porque, como o cdigo est numa linguagem intermediria, ou seja, independente da arquitetura de um computador real, s necessrio que a mquina virtual esteja instalada no computador onde o aplicativo ser executado. A mquina virtual ser a responsvel pela interpretao do cdigo para a linguagem de mquina do computador em execuo. Dentre as vantagens principais proporcionadas pela mquina virtual pode citar se o fato dos programas intermedirios serem compactos e poderem ser executados em qualquer plataforma na qual a mquina virtual esteja presente.

24

5.3.1 JVM (Java Virtual Machine)

Segundo BURD (2005) quando se iniciou a tecnologia Java em 1995, se tornou quase que imediatamente popular. Isto aconteceu por causa da mquina virtual Java. A JVM um interpretador de linguagem, que transforma Java byte code em cdigo nativo para que um determinado computador compreenda. Com a JVM, um byte code opera em mquinas Windows, Unix, Macs, entre outros. Isso chamado de portabilidade, que hoje em dia uma inovao no mercado computacional. Pense em todas as pessoas que utilizam computadores para navegar na Internet. Destas pessoas, nem todas rodam o Microsoft Windows, ou outro sistema operacional especfico, mas cada pessoa do computador pode ter o seu prprio interpretador de byte codes, ou seja, a sua mquina virtual Java. De acordo com Venners(1997), cada aplicao Java executado dentro de sua prpria mquina virtual. Sendo responsvel pela interpretao do cdigo intermedirio, chamados tambm bytecodes, a JVM faz uma validao se estes se adquam as especificaes no violando a integridade do sistema. A JVM tambm responsvel por carregar o programa de forma segura. 5.4 GARBAGE COLLECTOR (GERENCIADOR DE RECURSOS DA MEMRIA)

Conforme Rodrigues (2005), gerenciar recursos alocados por aplicativos algo vital para o funcionamento eficiente e prolongado de qualquer sistema. O mecanismo automatizado do GC garante o gerenciamento de recursos alocados, todavia, em algumas circunstancias a serem abordadas, tarefa de o desenvolvedor envolver-se diretamente nesta prtica, elaborando o cdigo necessrio explicitamente. Cada objeto consome parte da memria, de que existe uma quantidade limitada. Eventualmente, a memria alocada para estes objetos devem ser liberadas quando no so mais utilizadas. A mquina virtual Java recupera esses objetos automaticamente atravs de um processo chamado garbage collector. Segundo Engel (1999), o Garbage Collector o processo de coleta automtica de lixo da

25 memria, liberando objetos que no so mais referenciados pelo programa. O mecanismo automatizado do GC garante o gerenciamento de recursos alocados, todavia, em algumas circunstancias a serem abordadas, tarefa de o desenvolvedor envolver-se diretamente nesta prtica, elaborando o cdigo necessrio explicitamente.

5.4.1 Funcionamento do gerenciador de memria

De maneira simplificada, GC implementa um mecanismo de liberao de recursos de memria no heap de objetos. A ilustrao 02 demonstra a ao do garbage collector sobre os objetos alocados por uma aplicao. Estes objetos so referenciados em tabelas internas criadas pelo compilador JIT quando da inicializao do GC. Estas referencias so denominadas raiz pois correspondem primeira fase de ao do GC no monitoramento de objetos alocados pela aplicao, ainda referenciados pela mesma, que o GC no pode liberar. Diante deste fato, o GC constri suas prprias estruturas correspondentes aos objetos no heap. Este diagrama mostra todos os passos que so tomadas quando uma referncia a um objeto removido da mquina virtual. Isso acontece sempre que o usurio define explicitamente uma varivel para null, sobrescreve uma varivel do ponto de referncia para outro objeto, ou provoca a classe que detm a varivel de referncia para sair do campo de aplicao. Para cada referncia que tenha a mquina virtual, esta executa este processo de recolha de lixo durante o seu ciclo. Primeiro, a mquina virtual tenta traar um caminho a partir da raiz definido para o objeto. Se encontrar um caminho, no ocorre coleta. Se no encontrar um caminho, a mquina virtual elimina a referncia do objeto da memria. Em seguida, a mquina virtual determina se ira apontar para os objetos de referencia retirados de referencia. Se houver objetos de referencia, a mquina virtual determina se a memria sob a pilha baixa. Se assim for, ele faz uma verificao de memria. Se a

26 verificao indicar que no h memria livre ou a referncia a um objeto j no for referida com quaisquer referncias ou as referncias aos dados j foram lixo coletado, a referencia na referencia definido como nulo. Finalmente, a referencia dos objetos so adicionado fila.

27

CAPITULO III6 Arquitetura em Camadas 6.1 Histrico A arquitetura multicamadas se baseia na plataforma J2EE e tem como objetivo principal diminuir a complexidade e tempo de desenvolvimento de sistemas de misso crtica, atravs da definio de um framework composto por um conjunto de objetos que interagem entre si para prover um ou mais servios. Tais servios ficam disponibilizados em um ou mais servidores de aplicao. A diviso dos papis e responsabilidades de cada um desses objetos se faz por meio de camadas, possibilitando uma maior flexibilidade em funo do fraco acoplamento entre elas.

6.2 Arquitetura 2 Camadas

6.3 Arquitetura 3 Camadas (MCV)

6.4 Arquitetura 4 Camadas

28 7 CRONOGRAMAAtividades Escolha do tema Pesquisa bibliogrfica Analise bibliogrfica Montagem do projeto Defesa do projeto Entrega do projeto Desenvolvimento conceitual e Histrico Analise terica Elaborao primeira etapa TCC (1, 2 captulo) Apresentao (Pr-TCC) Entrega da primeira parte do TCC (1 e 2 captulo) Desenvolvimento prtico Analise dos elaborados Elaborao final Reviso final Apresentao Entrega final Reunies com o orientador X X X X X X X X do estudos Relatorio X Mar. X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X Abril Maio Jun. Jul. Ago. Set. Out. Nov.