BREVE ESTUDO SOBRE ENGENHARIA DE COMPONENTES

BREVE ESTUDO SOBRE ENGENHARIA DE COMPONENTES
1. INTRODU��O .................................................................................................................... 02
2. ESTUDO SOBRE ENGENHARIA DE COMPONENTES................................................... 03
2.1 ENGENHARIA DE SOFTWARE................................................................................................. 03
2.1.1 Conceitos.................................................................................................................... 03
2.1.2 Fases e Atividades Principais e de Apoio .................................................................. 04
2.1.3 Qualidade de Software............................................................................................... 04
2.2 ENGENHARIA DE COMPONENTES........................................................................................... 05
2.2.1 Hist�rico...................................................................................................................... 06
2.2.2 Conceitos.................................................................................................................... 07
2.2.3 Reuso ......................................................................................................................... 07
2.2.4 Design Patterns.......................................................................................................... 08
2.2.5 UML Components ...................................................................................................... 09
2.3 ENGENHARIA WEB............................................................................................................... 12
2.3.1 Modelagem de Aplica��es Web com UML ................................................................ 13
2.4 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE................................................................. 17
2.4.1 Processo Unificado .................................................................................................... 17
2.4.2 Rational Unified Process (RUP) ................................................................................. 18
2.4.2.1 Fases ............................................................................................................................... 18
2.5 PLATAFORMA TECNOL�GICA................................................................................................ 20
2.5.1 Java ............................................................................................................................ 20
2.5.1.1 Hist�rico........................................................................................................................... 20
2.5.1.2 A linguagem de programa��o Java .................................................................................. 21
2.5.1.3 A plataforma tecnol�gica Java.......................................................................................... 23
2.5.2 Sistema Gerenciador de Banco de Dados................................................................. 24
2.5.2.1 Conceito de SGBD............................................................................................................ 24
2.5.2.2 Uma breve hist�ria do PostgreSQL .................................................................................. 25
2.5.2.3 Caracter�sticas t�cnicas do PostgreSQL .......................................................................... 27
2.6 SISTEMA DISTRIBU�DO ......................................................................................................... 28
2.6.1 Conceito de Sistemas Distribu�dos, Seguran�a e Telecomunica��es....................... 28
2.7 ARQUITETURA WEB............................................................................................................. 32
2.7.1 Arquitetura Java EE e Design Patterns...................................................................... 33
2.7.2 Componentiza��o da camada de visualiza��o com JSF .......................................... 36
2.7.3 Componentiza��o da camada de neg�cios com EJB ............................................... 37
REFER�NCIAS BIBLIOGR�FICAS........................................................................................... 41
Jean Wagner Kleemann
Campo Grande - 2010
2
1. INTRODU��O
No processo desenvolvimento de software, uma quest�o muito discutida �
a produtividade. Os sistemas est�o a cada dia mais complexos e muitos
padr�es de desenvolvimento e gerenciamento de processos n�o atendem as
expectativas desejadas.
Na busca de novas metodologias e pr�ticas de desenvolvimento de
software, algumas solu��es como a orienta��o a objetos e padr�es de projeto,
ainda deixam distante da sonhada reutiliza��o e r�pida implementa��o de
sistemas complexos. Contudo a componentiza��o � uma alternativa capaz de
lidar com problemas ligados ao reaproveitamento, n�o somente de c�digo, mas
tamb�m de funcionalidades e interfaces, independentemente de plataforma,
diminuindo custos e tempo de desenvolvimento.
Com o desenvolvimento baseado em componentes, surge a id�ia de "crie
uma vez, use onde quiser". Neste conceito n�o � necess�rio escrever uma nova
aplica��o codificando linha a linha, mas consiste em montar sistemas utilizando
componentes j� implementados. Proporcionando assim o r�pido
desenvolvimento, facilidade de manuten��o e maior qualidade dos sistemas.
Entretanto, encontrar componentes que se encaixam em dom�nios de
neg�cios distintos � algo dif�cil, sendo sugerido ent�o a implementa��o de seus
pr�prios componentes. Para isso � essencial a utiliza��o de padr�es em todo
processo de desenvolvimento de componentes de software.
Este estudo descreve assuntos relacionados � componentiza��o, que
devem ser analisados antes de um estudo mais aprofundado neste universo da
componentiza��o de software. Os conceitos tratados ser�o a Engenharia de
software, engenharia web e engenharia de componentes, bem como a
tecnologia Java, Design Patterns, PostgreSQL, RUP e Sistemas distribu�dos.
3
2. ESTUDO SOBRE A ENGENHARIA DE COMPONENTES
2.1 Engenharia de software
Segundo Friedrich Ludwig Bauer (1969, p. 231), "Engenharia de
Software � a cria��o e a utiliza��o de s�lidos princ�pios de engenharia a fim de
obter software de maneira econ�mica, que seja confi�vel e que trabalhe
eficientemente em m�quinas reais".
2.1.1 Conceitos
A engenharia de software � uma �rea do conhecimento da computa��o
voltada para a especifica��o, desenvolvimento e manuten��o de sistemas de
software aplicando tecnologias e pr�ticas de ger�ncia de projetos e outras
disciplinas, objetivando organiza��o, produtividade e qualidade.
Essas pr�ticas e tecnologias envolvem linguagens de programa��o,
banco de dados, ferramentas, plataformas, bibliotecas, padr�es, processos e
qualidade de software, entre outros.
Os fundamentos cient�ficos para a engenharia de software envolvem o
uso de modelos abstratos e precisos que permitem ao engenheiro especificar,
projetar, implementar e manter sistemas de software, avaliando e garantindo
suas qualidades. Al�m disso, a engenharia de software deve oferecer
mecanismos para se planejar e gerenciar o processo de desenvolvimento de
um sistema de informa��o Sistema Computacional, pois ambos se confundem.
O fundamento da engenharia de software � a camada de processo. O
processo de engenharia de software mant�m unidas as camadas de tecnologia
e permite o desenvolvimento racional e oportuno de software para computador
(PRESMMAN, 2002).
4
2.1.2 Fases e Atividades Principais e de Apoio
Indiferente do escopo a ser aplicada, a engenharia de software divide o
processo de desenvolvimento em tr�s fases distintas: Defini��o (An�lise do
sistema, planejamento do projeto de software e an�lise de requisitos),
Desenvolvimento (projeto de software, codifica��o e realiza��o de testes do
software), Manuten��o (corre��o, adapta��o e melhoramento funcional).
Estas fases ainda s�o complementadas por Atividades de apoio, como
por exemplo: Controle de Configura��o, Controle de Qualidade, Verifica��o e
Valida��o, Auditorias, Gerenciamento de Riscos, Acompanhamento e Controle
do Projeto de Software.
2.1.3 Qualidade de Software
Segundo o Software Engineering Body of Knowledge (SWEBOK, 2004),
a qualidade de software pode ser dividida em tr�s t�picos para melhor
entendimento, sendo eles:
� Fundamentos de qualidade de software: Cultura e �tica de
engenharia de software,Valores e custos de qualidade, Modelos e
caracter�sticas de qualidade, Melhoria da qualidade.
� Ger�ncia do processo de qualidade de software: Garantia de
qualidade de software, Verifica��o e valida��o, Revis�es e
auditorias,
� Considera��es pr�ticas: Requisitos de qualidade para aplica��es,
Caracteriza��o de defeitos, T�cnicas de ger�ncia de qualidade de
software, Medidas de qualidade de software.
Ao contr�rio de alguns autores que se ap�iam em testes de software
para garantir qualidade, o SWEBOK esclarece que essa �rea n�o exige a
execu��o do software para avali�-lo, em contraposi��o � �rea de conhecimento
teste de software.
5
Tendo em vista que a qualidade n�o � incorporada ao produto depois de
conclu�do, essa atividade � aplicada durante todas as etapas de
desenvolvimento, pois os fatores relacionados ao produto dependem
diretamente e indiretamente do processo.
A qualidade de software tamb�m pode ser definida como a integra��o
entre os requisitos funcionais, requisitos de desempenho, padr�es de
desenvolvimento claramente documentados e demais caracter�sticas impl�citas.
Podemos citar algumas pr�ticas caracter�sticas de qualidade de
software:
� Prototipa��o.
� Testes de Aceita��o como Especifica��o.
� Testes Unit�rios.
� Revis�o de C�digo.
� Integra��o Cont�nua.
� An�lise de Risco.
� An�lise Est�tica.
� Automa��o de Processos.
2.2 Engenharia de componentes
A Engenharia de componentes � uma deriva��o da engenharia de
software, focada na decomposi��o dos sistemas, em componentes funcionais e
l�gicos com interfaces bem definidas, usadas para comunica��o entre os
pr�prios componentes, que est�o em um n�vel mais elevado de abstra��o do
que os objetos, com isso a comunica��o se d� por meio de mensagens.
A engenharia de software baseada em componentes (component-based
software engineering, CBSE) � um processo que enfatiza o projeto e a
6
constru��o de sistemas baseados em computador usando "componentes" de
software reutiliz�veis (PRESMMAN, 2002).
A pr�tica da tecnologia de software baseado em componentes, baseia-se
no desenvolvimento atrav�s de componentes reutiliz�veis, levando a redu��o
de tempo de desenvolvimento, e facilitando as mudan�as e a implanta��o de
novas funcionalidades.
Dessa forma, o processo de engenharia de software baseada em
componentes tem mudado o modo pelo qual sistemas s�o desenvolvidos, pois
desloca a �nfase da programa��o do software para a composi��o de sistema
de software com base em componentes (PRESMMAN, 2002).
2.2.1 Hist�rico
Durante a Confer�ncia de Engenharia de Software da OTAN realizada
em 1968, Mcilory sob o titulo "Mass Produced Software Components"
(Produ��o de Componentes de Software em Massa), exp�e a id�ia de que o
desenvolvimento de software deve empenhar-se em desenvolver componentes
reus�veis com o intuito de proporcionar aos desenvolvedores a possibilidade de
escolher quais componentes utilizar, conforme as suas necessidades. Nasce a�
o interesse em desenvolver software atrav�s da integra��o de componentes de
software. Em seguida, como primeira implementa��o da infra-estrutura de sua
id�ia, incluiu pipes (para comunica��o entre processos) e filtros no sistema
operacional Unix.
Em 1976, DeRemer prop�s um paradigma de desenvolvimento, que
consistia na id�ia do sistema ser constru�do como um conjunto de m�dulos
independentes e depois interligados. J� na d�cada de 80, com o surgimento da
orienta��o a objetos e a possibilidade de reutiliza��o, fortaleceu ainda mais a
proposta de desenvolver componentes.
Podemos citar alguns componentes bastante conhecidos atualmente,
7
como: CMM (CORBA Component Model) do OMG (Object Management
Group), DCOM (Distributed Component Obejct), COM/COM+ (Component
Object Model) da Microsoft, e JavaBeans e Entreprise JavaBeans (EJB) da
Sun.
2.2.2 Conceitos
A engenharia baseada em componentes possui as etapas de coleta de
requisitos e passa por um projeto arquitetural, da mesma forma que a
engenharia se software tradicional. Por�m a partir desse ponto come�a se
diferenciar, pois come�a a ser analisado os requisitos com objetivo de buscar
m�dulos que sejam mais adequados � composi��o, ao inv�s de iniciar a
constru��o e partir para tarefas de projeto mais detalhadas.
Ao fazer essa an�lise dos subconjuntos ou m�dulos do sistema, pode se
fazer o uso de componentes j� existentes, sendo componentes pr�prios ou
comerciais.
Segundo Desmond D'Sousa (1998) um componente � um pacote
coerente de artefatos de software que pode ser desenvolvido
independentemente e entregue como unidade e que pode se composto, sem
mudan�a, com outros componentes para construir algo maior.
2.2.3 Reuso
O Reuso � o objetivo principal da engenharia de software baseada em
componentes. N�o se trata somente de reutiliza��o de c�digo, pois abrange
tamb�m os artefatos envolvidos durante o todas as etapas de desenvolvimento.
Dentro da engenharia de componentes, s�o observadas algumas
caracter�sticas positivas e outra nem tanto, mas que valem ser destacadas:
� Os riscos s�o menores ao usar um componente j� existente em
8
rela��o ao desenvolvimento de algo a partir do zero.
� O aumento da produtividade, tendo em vista a redu��o de esfor�os
pela equipe de desenvolvimento. Seguindo a id�ia �Crie uma vez,
use onde quiser�.
� A qualidade e confiabilidade do produto e s�o maiores, pois o
componente reutilizado j� foi testado e aprovado.
� No caso de componentes comercias, pode-se n�o ter acesso ao
c�digo fonte ou depender de direitos autorais e licen�as.
� Resist�ncia da parte das equipes de desenvolvimento, pois exige
forte padroniza��o (investimento de tempo e controle de qualidade)
e documenta��o (investir mais tempo nos artefatos). A ado��o de
novas pr�ticas de desenvolvimento geralmente encontra forte
resist�ncia a mudan�as por parte da equipe.
2.2.4 Design Patterns
Dedign Patterns ou padr�es de projeto significa um grupo de pr�ticas
para definir o problema, a solu��o e em qual situa��o aplicar esta solu��o e
suas conseq��ncias no desenvolvimento de software.
Os padr�es s�o desenvolvidos a partir de experi�ncias pr�ticas em
projetos reais. � resultado da experi�ncia de arquitetos com experi�ncia, que
aplicam usam estes padr�es e experimentam o resultado em seus pr�prios
problemas. A experi�ncia desses arquitetos certamente proporciona a
abordagem correta para um problema espec�fico, da forma mais indicada.
Fazendo uso de tais padr�es, temos como resultado uma qualidade de
c�digo, permitindo a reutiliza��o de forma flex�vel e expans�vel. Por se tratar de
quest�es que nasceram de um problema real, e a solu��o foi testada e
documentada, os padr�es aumentam de forma significativa a produtividade e
qualidade, pois a solu��o j� est� definida.
9
2.2.5 UML Components
A UML pode ser definida como uma linguagem de diagrama��o da
metodologia orientada a objetos, que serve de apoio � an�lise de sistemas,
desde o levantamento dos requisitos at� a implanta��o de um sistema.
� composta por diversos elementos b�sicos que representam as
diferentes partes de um sistema, como por exemplo: Classe, Interface, Nota,
Pacote, Caso de Uso, Atividades, dentre outros. Al�m disso, a UML permite a
cria��o de elementos pr�prios atrav�s dos estere�tipos, valores de etiqueta e
restri��es, de acordo com Melo (2004).
A UML na vers�o 2.0 � composta por treze diagramas, divididos nas
categorias estruturais (caracter�sticas que n�o mudam com o tempo) e
din�micos (mostram como o sistema evolui durante o tempo), conforme
mencionado por Melo (2004) e representado abaixo pela Figura 1.
Figura 1 � Diagramas da UML 2.0.
10
A UML possui uma s�rie de diagramas para representa��o de
componentes e suas especifica��es, intera��es e integra��o com demais
sistemas. Segundo RUBIRA (2008), a UML Components, atende todas as fases
de elabora��o de componentes de software, desde o levantamento de
requisitos at� o sistema em funcionamento, conforme a Figura 2, abaixo
representada.
Figura 2. Processo UML Components.
Na fase de especifica��o dos requisitos, que � independente de
tecnologia a ser utilizada, ocorre a modelagem l�gica do neg�cio. O processo
UML Components mostra os artefatos envolvidos nesta fase, mas n�o descreve
como devem ser produzidos, sendo eles:
� Processo do Neg�cio (Bussines Process): Se trata de uma
11
representa��o gr�fica, atrav�s de um diagrama de atividades,
descrevendo as atividades que representam o funcionamento do
neg�cio em si. Serve para melhor compreens�o do dom�nio,
envolvendo v�rias funcionalidades do sistema e mostrando a
rela��o entre elas, e separando as atividades manuais e
autom�ticas.
� Modelo Conceitual do Neg�cio (Business Concept Model):
Representa as entidades do neg�cio de uma forma geral. Serve
para entender o papel do sistema, contextualizando os
desenvolvedores a partir de entidades e relacionamentos.
� Modelo de Casos de Uso (Use Cases Model): � o detalhamento
das funcionalidades do sistema e seu relacionamento com os
atores. Representa graficamente as principais funcionalidades e o
relacionamento entre elas atrav�s de diagramas de casos de uso.
Na Fase seguinte, de especifica��o dos componentes, tamb�m
independe de tecnologia, e nesta fase s�o levantadas as interfaces de sistema
e de neg�cio, bem como o detalhamento da seq��ncia de atividades para
desenvolver os componentes. Essas atividades S�o descritas em tr�s etapas,
sendo elas: a identifica��o dos componentes, intera��o entre os componentes e
especifica��o final.
O processo de Identifica��o dos componentes � baseado nas interfaces
do sistema, atrav�s de um procedimento intuitivo. Tamb�m � feito o uso de
diagramas de casos de uso espec�ficos e diagramas de fluxo e opera��o. O
modelo de tipos do neg�cio (Business Type Model) � indicado nesta fase, pois
restringe as entidades relevantes para o dom�nio da solu��o, focado nas
responsabilidades do sistema e n�o dos atores.
Na Intera��o entre os componentes � necess�rio descobrir as opera��es
de neg�cio que est�o ligadas ao relacionamento entre os componentes, atrav�s
de diagramas din�micos, como de colabora��o, de seq��ncia ou de atividades.
12
Na especifica��o final dos componentes, cabe o Modelo de Informa��o
das Interfaces (Interface Information Model), que porve a rela��o entre cada
interface e as entidades do modelo de neg�cio. Dessa forma ajuda o
entendimento do contexto de cada interface e auxilia na troca de conhecimento
entre a equipe de desenvolvimento.
J� a fase de provisionamento dos componentes depende diretamente de
tecnologia, pois define como os componentes ser�o adquiridos, localizados,
reutilizados ou implementados. O processo UML Components lista poss�veis
maneiras de criar os componentes de software, mas n�o detalha cada uma
delas.
� Aquisi��o dos componentes: Reutiliza��o de componentes prontos
ou a utiliza��o de novos componentes.
� Localiza��o de componentes prontos: buscar por servi�o fornecido
pelo componente, considerando a semelhan�a de seus conte�dos.
� Reutiliza��o de componentes: Pode ser necess�rio adaptar os
componentes reutilizados ou at� mesmo as funcionalidades do
sistema (renegocia��o dos requisitos).
� Implementa��o dos Componentes: Deve-se utilizar um modelo de
componente j� existente, tais como: EJB, COM+, etc.
Por ultimo, na montagem do sistema, tamb�m dependente da tecnologia,
� feita a implementa��o dos conectores e a liga��o entre os componentes e os
conectores do sistema. Nessa fase � observada a adapta��o e comportamento
dos componentes, requisitos de qualidade, disponibilidade, escalabilidade,
confiabilidade, entre outros.
2.3 Engenharia Web
MURUGESAN (1999) define a engenharia Web como o estabelecimento
e uso de princ�pios de engenharia e abordagens disciplinadas para o
desenvolvimento, implanta��o e manuten��o de aplica��es baseadas na Web.
13
O ambiente Web possui diversas caracter�sticas, valendo destacar a
concorr�ncia, carga imprevis�vel, disponibilidade, sensibilidade ao conte�do,
evolu��o din�mica, imediatismo, seguran�a e est�tica, que impulsionaram uma
nova din�mica aos processos j� existentes, dando origem a uma nova sub�rea
da Engenharia de Software, a Engenharia Web (PRESSMAN, 2005).
Os webistes podem variar de p�ginas est�ticas at� verdadeiros sistemas
baseados na Web(lojas virtuais, ambientes cooperativos, sistemas de ger�ncia
empresarial, etc.). Este tipo de website � definido como Sistemas de Informa��o
Web (Web-based Information Systems - WISs) e ao conjunto amplo de todas as
aplica��es Web como Web Applications (WebApps).
O cap�tulo seguinte apresenta uma vis�o geral das metodologias e
pr�ticas da UML que podem ser aplicadas na modelagem de sistemas WEB.
2.2.3.1 Modelagem de Aplica��es Web com UML
A metodologia Engenharia Web Baseada em UML (UML-based Web
Engineering � UWE) (KOCH, 2002) define um conjunto de modelos a serem
constru�dos no desenvolvimento de uma aplica��o Web, uma linguagem de
modelagem para a elabora��o desses artefatos e um processo para constru��o
dos modelos.
As principais atividades no processo de modelagem s�o: an�lise de
requisitos, projeto conceitual, projeto de navega��o, projeto de apresenta��o,
modelagem de tarefas e modelagem de implanta��o.
A abordagem UWE ap�ia o desenvolvimento de aplica��es Web com foco
especial na sistematiza��o, personaliza��o e gera��o autom�tica de c�digo.
Indica tamb�m a utiliza��o de casos de uso para a especifica��o de requisitos
e, baseado nos casos de uso especificados, o projeto conceitual produz um
modelo conceitual do problema, definido em termos de classes e associa��es
14
entre classes relevantes do dom�nio.
O projeto de navega��o utiliza o modelo conceitual como base e � definido
em duas etapas: defini��o do modelo de espa�o de navega��o e constru��o do
modelo de estrutura de navega��o. O primeiro modelo mostra quais objetos
podem ser vistos atrav�s da navega��o pela aplica��o Web e �, portanto, um
modelo de an�lise. O segundo modelo � baseado no primeiro e define como os
objetos s�o visitados, sendo constru�do na fase de projeto.
O projeto de apresenta��o consiste na modelagem de interfaces com o
usu�rio abstratas, mostrando como a estrutura de navega��o definida
anteriormente � apresentada ao usu�rio.
Ele � dividido em uma parte est�tica e outra din�mica. A parte est�tica �
representada por uma forma particular de diagrama de classes que usa uma
nota��o de composi��o de classes. Elementos de apresenta��o s�o
representados por classes estereotipadas e suas partes internas s�o
representadas graficamente dentro do elemento de modelo �classe�, podendo
ter v�rios n�veis de �aninhamento de elementos gr�ficos�.
Para refinar os casos de uso, diagramas de atividade podem ser
utilizados, modelando de forma mais detalhada a intera��o com o usu�rio. Por
fim, diagramas de implanta��o podem ser usados para documentar a
distribui��o dos componentes da aplica��o Web.
As Extens�es de Aplica��es Web (Web Application Extensions � WAE)
(CONALLEN, 2002) s�o extens�es ao meta-modelo da UML para a
modelagem de caracter�sticas espec�ficas de aplica��es Web. A WAE define
extens�es apropriadas para modelar diversos componentes t�picos do
desenvolvimento de aplica��es Web, usando elementos do meta-modelo da
UML adicionados de estere�tipos pr�-definidos para simbolizar os conceitos
necess�rios.
Al�m dos estere�tipos, a WAE prev� a defini��o de valores etiquetados
15
(tag values), representados entre colchetes, e restri��es (constraints),
representadas entre chaves, para alguns elementos.
A WAE � voltada para apoiar a elabora��o de modelos de projeto, tendo
em vista que essa fase � mais suscet�vel � tecnologia. A fase de projeto �
dividida em duas vis�es: a vis�o l�gica, que est� em um n�vel mais alto de
abstra��o, definindo classes e associa��es, e a vis�o de componentes, que
trata dos arquivos que efetivamente compor�o o sistema implementado
(p�ginas e diret�rios).
Para a vis�o l�gica, s�o definidos tr�s estere�tipos principais aplicados
sobre o elemento classe do meta-modelo da UML e diversos estere�tipos de
associa��o, como mostram as tabelas 1 e 2, respectivamente. Tais estere�tipos
podem ser utilizados para a cria��o de diagramas de classes que representem
os elementos Web que comp�em o sistema, chegando a um n�vel de detalhes
maior do que os diagramas de classe da fase de an�lise (pois j� incluem
informa��es da plataforma de desenvolvimento), mas ainda num n�vel de
abstra��o l�gico.
Estere�tipo O que a classe estereotipada representa
<<server page>> Uma p�gina Web din�mica que efetua processamento no
servidor e gera um resultado possivelmente diferente a
cada requisi��o. Suas opera��es representam fun��es
do script e seus atributos representam vari�veis vis�veis
no escopo da p�gina.
<<client page>> Uma p�gina Web est�tica que � simplesmente retornada
ao cliente quando requisitada, sem gerar processamento.
Pode conter scripts do lado do cliente (client-side),
portanto seus atributos e opera��es referem-se a tais
scripts.
<<HTML form>> Formul�rios HTML para entrada de dados. Seus atributos
representam os campos do formul�rio. Tais formul�rios
n�o possuem opera��es. Qualquer opera��o que interaja
com o formul�rio deve ser propriedade da p�gina que o
cont�m.
Tabela 1: Estere�tipos de classe utilizados na vis�o l�gica do projeto
16
Al�m desses elementos b�sicos, para o que Conallen chama de �Projeto
Avan�ado�, existem estere�tipos para representa��o de outros elementos da
vis�o l�gica da camada Web, a saber: conjunto de quadros (classe com
estere�tipo <<frameset>>), alvo de link (classe com estere�tipo <<target>>),
link de destino (associa��o m�ltipla com estere�tipo <<target link>>), ibliotecas
de script (classe com estere�tipo <<script library>>) e objeto de script (classe
com estere�tipo <<script object>>).
Estere�tipo O que a associa��o estereotipada representa
<<link>> Um link normal entre p�ginas, representado em HTML pela
tag <a>. Par�metros codificados como parte da URL segundo
o protocolo http podem ser representados como atributos da
associa��o.
<<build>> Relacionamento direcional entre uma server page e uma
client page que indica que a sa�da HTML do processamento
da p�gina do servidor � a p�gina do cliente.
<<submit>> Relacionamento direcional entre um html form e uma server
page, representando o envio dos dados dos campos do
formul�rio para a p�gina do servidor para processamento.
<<redirect>> A��o de redirecionamento de uma p�gina para outra.
<<forward>> A��o de delega��o de uma p�gina para outra. Difere do
redirecionamento por manter o contexto da requisi��o feita �
primeira p�gina.
<<object>> Relacionamento de confinamento entre uma p�gina e um
objeto, como uma Applet ou controle ActiveX.
<<include>> Uma associa��o direcional entre uma server page e uma
outra p�gina que indica que o conte�do desta �ltima ser�
processado (somente no caso de uma p�gina do servidor) e
inclu�do na primeira.
Tabela 2: Estere�tipos de associa��o utilizados na vis�o l�gica do projeto
Para a vis�o de componentes, s�o definidos tr�s estere�tipos para o
elemento de modelo componente da UML: <<static page>>, componente que
representa p�ginas est�ticas, ou seja, sem processamento no lado do servidor;
<<dinamic page>>, componente que representa p�ginas din�micas; e
<<physical root>>, pacote de componentes representando uma abstra��o de
uma hierarquia de arquivos que cont�m recursos dispon�veis � solicita��o no
servidor Web.
17
Por meio de diagramas de componentes, a vis�o de componentes busca
modelar o mapeamento entre os arquivos f�sicos (representados pelos
componentes com os tr�s estere�tipos citados) e as representa��es l�gicas
apresentadas na vis�o l�gica (representadas por classes estereotipadas,
conforme discutido anteriormente).
2.4 Processo de desenvolvimento de software
O processo de desenvolvimento de software, basicamente determina
uma estrutura para cada �rea ou etapa no per�odo de desenvolvimento,
relacionando as tecnologias e procedimentos a serem utilizados.
Estas �reas dentro do processo de desenvolvimento ser�o usadas como
alicerce para controlar o desenvolvimento do projeto, determinando em que
fase as t�cnicas devem ser aplicadas. Em s�ntese o processo de
desenvolvimento de software determina uma forma para executar as fases de
cria��o, implanta��o e manuten��o.
2.4.1 Processo Unificado
O processo unificado PU � resultado de tr�s processos de
desenvolvimento e nota��es, reunindo as vantagens de cada um. Este
processo unificado estabeleceu uma nota��o conhecida como UML (Unified
Modeling Language).
O processo unificado � direcionado a casos de uso, centrado na
arquitetura e usa os ciclos iterativo e incremental para a constru��o de
softwares, baseado na constru��o de artefatos de software atrav�s da UML, e
n�o apenas em documenta��o, � tamb�m baseado em componentes.
Como os artefatos s�o produzidos em fases distintas, e refinados ao
longo do tempo, eles ajudam a organizar as itera��es e a direcionar o projeto,
18
uma vez que o PU � baseado em casos de uso durante praticamente todas as
fases. Portanto estes artefatos s�o primordiais para orientar a condu��o do
projeto.
2.4.2 Rational Unified Process (RUP)
O Rational Unified Process (RUP) foi desenvolvido pela IBM, sendo uma
ramifica��o mais detalhada do PU, possuindo um grande conjunto de manuais
e modelos de artefatos a serem produzidos ao longo do processo, al�m de
tutoriais da ferramenta Rational Suite (conjunto de ferramentas constru�das em
torno do RUP).
O processo do RUP disponibiliza uma abordagem baseada em
disciplinas para atribuir tarefas e responsabilidades dentro de uma organiza��o
de desenvolvimento e, assim como o PU. Tamb�m � baseado em casos de
uso, orientado pela arquitetura, iterativo e incremental, apresentando uma gama
de pap�is, disciplinas, tarefas e artefatos.
Integrado ao RUP est�o algumas pr�ticas de desenvolvimento de
software, sendo elas:
� Desenvolvimento de software de forma iterativa.
� Gerenciamento de requisitos.
� Arquitetura baseada em componentes.
� Modelagem de software por meio de diagramas.
� Analise da qualidade de software.
� Gerenciamento de mudan�as de software.
2.4.2.1 Fases
O RUP herda quatro fases do PU, sendo elas:
� Concep��o: � definida a viabilidade do projeto como neg�cio,
19
atrav�s da delimita��o de seu escopo, e de estimativas de
custo, cronograma e retorno sobre o investimento (ROI).
Riscos s�o identificados e gerenciados, s�o definidos os
requisitos funcionais e n�o funcionais, e � tra�ado um esbo�o
da arquitetura do sistema, que servir� como alicerce para sua
constru��o. S�o definidas as primeiras vers�es do modelo de
neg�cio, do modelo de casos de uso, da lista de riscos e suas
prioridades, do plano de projeto, da arquitetura do sistema.
� Elabora��o: Refinamento do sistema, com a identifica��o de
quase todos os casos de uso, com o detalhamento da
arquitetura tra�ada na fase anterior e com o gerenciamento
cont�nuo dos riscos envolvidos. Estimativas realistas feitas
nesta fase permitem preparar um plano para orientar a
constru��o do sistema nas fases posteriores. � poss�vel que
se tenha a uma vers�o completa do modelo de neg�cios.
� Constru��o: Nesta fase o sistema � efetivamente
desenvolvido e, em geral, tem condi��es de ser operado,
mesmo que em ambiente de teste, pelos clientes. Ao final da
fase de constru��o tem-se um software execut�vel, a
atualiza��o de artefatos do sistema refletindo o estado atual
do sistema, e um manual do usu�rio detalhado.
� Transi��o: O sistema � entregue ao cliente para o uso em
produ��o. Nesta fase testes s�o realizados, e um ou mais
incrementos do sistema s�o implantados, e se necess�rio,
defeitos podem ser corrigidos. � tamb�m nessa fase que os
usu�rios recebem treinamento para a opera��o do sistema.
20
2.5 Plataforma tecnol�gica
2.5.1 Java
O Java � uma plataforma de desenvolvimento que chama a aten��o de
analistas, projetistas e programadores, pois � resultante de um grande trabalho
de pesquisa cient�fica e tecnol�gica que ser� descrito nos t�picos seguintes.
2.5.1.1 Hist�rico
Segundo Peter Jandl Junior, 2007, em 1991 um pequeno grupo de
projeto da Sun Microsystems denominado Green, pretendia criar uma nova
gera��o de computadores port�teis inteligentes, capazes de se comunicar de
muitas formas, ampliando suas potencialidades de uso. Para tanto se decidiu
criar tamb�m uma nova plataforma para o desenvolvimento destes
equipamentos de modo que seu software pudesse ser portado para os mais
diferentes tipos de equipamentos. A primeira escolha de uma linguagem de
programa��o para tal desenvolvimento foi C++, aproveitando suas
caracter�sticas e a experi�ncia dos integrantes do grupo no desenvolvimento de
produtos. Mas mesmo o C++ n�o permitia realizar com facilidade tudo aquilo
que o grupo visionava.
James Gosling, um dos l�deres do projeto, decidiu pela cria��o de uma
nova linguagem de programa��o que pudesse conter tudo aquilo considerado
importante e que ainda fosse simples, port�til e f�cil de programar. Surgiu ent�o
a linguagem interpretada Oak (carvalho em ingl�s), batizada assim em raz�o da
exist�ncia de uma destas �rvores em frente ao escrit�rio de Gosling. Para dar
suporte � linguagem tamb�m surgiram o Green OS e uma interface gr�fica
padronizada.
Devido a problemas de direitos autorais, o Oak recebe o novo nome
Java, mas continua sem uso definido at� 1994, quando, estimulados pelo
grande crescimento da internet, Patrick Naughton e Jonathan Payne
21
desenvolveram o programa navegador WebRunner, capaz de efetuar o
download e a execu��o de c�digo Java via internet. Este navegador, sob o
nome HotJava, e a linguagem Java foram apresentados formalmente pela Sun
em maio de 1995 no SunWorld'95, ent�o o interesse pela solu��o se mostrou
explosivo. Logo no in�cio de 1996 a Netscape Corp. lan�a a vers�o 2.0 de seu
navegador, o qual incorpora as capacidades de efetuar o download e realizar a
execu��o de pequenas aplica��es Java denominadas applets.
Numa iniciativa in�dita, a Sun decide disponibilizar um conjunto de
ferramentas de desenvolvimento Java gratuitamente para a comunidade de
software, embora detenha todos os direitos relativos � linguagem e �s
ferramentas de sua autoria. Surge assim, em meados de 1996, o JDK 1.02 (Kit
de Desenvolvimento Java). As plataformas inicialmente atendidas foram: Sun
Solaris e Microsoft Windows 95/NT. Uma vez que a especifica��o da linguagem
e do ambiente de execu��o tamb�m foram disponibilizados publicamente,
progressivamente foram aparecendo kits para outras plataformas, tais como
IBM OS/2, Linux e Apple Mac.
Um ano ap�s seu an�ncio, ocorre o primeiro grande evento da linguagem
Java, o JavaOne Conference, que, desde ent�o, vem sendo usado para
apresentar as novas caracter�sticas, casos de sucesso, produtos e tecnologias
associadas. Foi assim que se iniciou a hist�ria de sucesso do Java.
2.5.1.2 A linguagem de programa��o Java
A linguagem Java possui algumas caracter�sticas que, em conjunto,
diferenciam-na das demais linguagens de programa��o. Dentre os diversos
autores da literatura Java como Horstmann (2000), Newman (1996), entre
outros, destacam caracter�sticas que s�o alguns pontos-chave da Linguagem:
� Orientada a Objetos � Tudo em Java s�o classes ou instancias de
classes, por isso Java � totalmente orientada a objetos, pois,
possui mecanismos para abstra��o de dados (atrav�s das
classes), encapsulamento (ocultar do usu�rio o funcionamento
22
interno de uma classe), heran�a (criar uma nova classe a partir de
outra) e polimorfismo (diferentes classes podem definir m�todos
de mesmo nome).
� Independente de Plataforma � Os programas em Java utilizam
uma forma de compila��o intermedi�ria que resulta em uma
codifica��o denominada bytecode, um tipo de linguagem de
m�quina (baixo n�vel) que � destinado a JVM (Maquina Virtual
Java). Dessa forma a JVM interpreta os bytecodes, independente
da plataforma, permitindo assim, que um programa Java seja
executado da mesma forma em qualquer arquitetura.
� Gerenciamento Autom�tico de Mem�ria - A JVM possui um
mecanismo chamado de Garbage Collector (Coletores) que �
respons�vel por alocar e liberar os dados da mem�ria
automaticamente. Com isso n�o � necess�rio que o
desenvolvedor realize tais procedimentos manualmente,
eliminando algumas falhas comuns como: tentar acessar um
objeto que j� foi liberado da mem�ria ou esquecer de liberar um
objeto.
� Desempenho � Nas primeiras vers�es, o Java apresentava certa
limita��o quanto a performance, mas isto foi superado com
algumas adapta��es na JVM. Um compilador JIT (Just In Time)
foi incorporado na JVM que passou a interpretar os bytecodes
durante a execu��o do programa. Conforme as novas gera��es
de compiladores como, por exemplo, o HotSpot da Sun
combinado com a JVM, a performance vem melhorando de forma
muito significativa, podendo concorrer at� mesmo com o C++
(Carmine Mangione, on-line).
� Tratamento de exce��es: Em alguns casos, a ocorr�ncia de
algum erro durante a execu��o de um programa pode fazer com
que o computador �trave� sendo necess�rio reinicia-lo. Com a
utiliza��o do Java este tipo de evento n�o acontece, pois, a JVM
verifica em tempo de execu��o um conjunto de eventos (acesso a
mem�ria, abertura de arquivos, etc.) e ao encontrar algum
23
impedimento ou inconsist�ncia gera uma exce��o (uma esp�cie
de mensagem com a descri��o do erro).
� Seguran�a: Diferente das demais linguagens, em Java a
aplica��o n�o se comunica com o Sistema Operacional, e sim
com a JVM que por sua vez interage com o Sistema. O bytecode
gerado pela aplica��o deve passar primeiro por alguns requisitos
de seguran�a da JVM, que caso encontre alguma irregularidade
impede a execu��o do c�digo.
� Multithread: Capaz de executar v�rias tarefas (conjunto de
instru��es) ao mesmo tempo dentro da aplica��o. Cada uma
destas tarefas � conhecida como thread.
Vale destacar que para desenvolver programas em Java, primeiramente
� necess�rio um editor que permita salvar o programa fonte com a extens�o
�.java�, como por exemplo o JEdit, JCreator ou at� mesmo o bloco de notas do
Microsoft Windows. Uma alternativa mais interessante � o uso de uma IDE
(Integrated Development Environment) pr�pria para Java, como o NetBeans ou
Eclipse. Posteriormente com base no arquivo �.java�, o compilador Java �
respons�vel por gerar o arquivo de extens�o �.class�, que � o bytecode
propriamente dito. Ent�o a JVM interpreta e executa os arquivos de classe
fazendo o uso do c�digo nativo (usado para comunicar-se com o hardware) do
Sistema Operacional.
Dessa forma o c�digo Java � o mesmo para diferentes arquiteturas, pois
o que muda s�o as distribui��es da JVM, livrando o desenvolvedor de ajustar o
c�digo conforme a plataforma.
2.5.1.3 A plataforma tecnol�gica Java
Os ambientes de desenvolvimento ou plataformas Java (ALECRIM,
2007, on-line):
� JSE (Java Standart Edition): Pode-se dizer que � o ambiente
24
principal, pois o JEE e o JME s�o aprimorados do JSE.
Desenvolvido para aplica��es baseadas em cliente/servidor.
� JEE (Java Enterprise Edition): As aplica��es WEB s�o
fundamentadas nesta plataforma. As implementa��es neste
padr�o s�o muito complexas, cont�m bibliotecas exclusivas para o
acesso a servidores, banco de dados, sistema de e-mails, entre
outros.
� JME (Java Micro Edition): Corresponde ao JSE reduzido, para
dispositivos m�veis (telefones celulares, palmtops,...).
2.5.2 Sistema Gerenciador de Banco de Dados
Segundo Abraham Silberschatz, um sistema gerenciador de banco de
dados (SGBD) � constitu�do por um conjunto de dados associados a um
conjunto de programas para acesso a esses dados.
2.5.2.1 Conceito de SGBD
Um SGBD possui estruturas de dados otimizadas, que permitem a
manipula��o de grandes quantidades de informa��o, e apresentam um modelo
que define o esquema dos dados armazenados no sistema. Os quatro modelos
mais conhecidos s�o:
� Hier�rquico.
� Em Rede.
� Relacional.
� Orientado a Objetos.
Existem tamb�m outros modelos, variando com o autor:
� O modelo relacional estendido � uma adi��o de caracter�sticas
do modelo orientado a objetos ao relacional.
25
� O semi-estruturado � dedicado a documentos em formatos
semi-estruturados, normalmente em XML.
Um SGBD deve apresentar algumas caracter�sticas e responsabilidades,
tais como:
� Integridade sem�ntica (garantia de dados sempre corretos
com rela��o ao dom�nio de aplica��o)
� Seguran�a (evitar viola��o de consist�ncia dos dados,
seguran�a de acesso por usu�rios e aplica��es, seguran�a
contra falhas).
� Gerenciamento de Concorr�ncia (evitar conflitos de acesso
simult�neo a dados por transa��es).
2.5.2.2 Uma breve hist�ria do PostgreSQL
O PostgreSQL � um dos resultados de uma ampla evolu��o que se
iniciou com o projeto Ingres, desenvolvido na Universidade de Berkeley,
Calif�rnia. O l�der do projeto, Michael Stonebraker, um dos pioneiros dos
bancos de dados relacionais, deixou a universidade em 1982 para comercializar
o Ingres, por�m retornou a ela logo em seguida. Ap�s seu retorno a Berkeley,
em 1985, Stonebraker come�ou um projeto p�s-Ingres com o objetivo de
resolver problemas com o modelo de banco de dados relacional. O principal
problema era a incapacidade do modelo relacional compreender �tipos�
(atualmente, chamados de objetos), ou seja, combina��es de dados simples
que formam uma �nica unidade.
O projeto resultante, chamado Postgres, era orientado a introduzir a
menor quantidade poss�vel de funcionalidades para completar o suporte a tipos.
Estas funcionalidades inclu�am a habilidade de definir tipos, mas tamb�m a
habilidade de descrever rela��es - as quais at� este momento eram
amplamente utilizadas, mas completamente mantidas pelo usu�rio. No
Postgres, o banco de dados "compreendia" as rela��es e podia obter
26
informa��es de tabelas relacionadas utilizando regras.
Iniciando em 1986, a equipe divulgou uma s�rie de documentos
descrevendo a base do sistema e em 1988 o projeto possu�a um prot�tipo
funcional. A vers�o 1 foi liberada para um grupo pequeno de usu�rios em junho
de 1989, seguida pela vers�o 2 com um sistema de regras reescrito em junho
de 1990. Para a vers�o 3, liberada em 1991, o sistema de regras foi reescrito
novamente, mas tamb�m foram adicionados suporte para m�ltiplos
gerenciadores de armazenamento e um melhorado motor de consultas. J� em
1993, Postgres havia crescido imensamente em popularidade e possu�a uma
grande demanda por suporte e por novas funcionalidades. Ap�s a libera��o da
vers�o 4, a qual era uma simples vers�o de limpeza, o projeto foi oficialmente
abandonado pela Universidade de Berkeley.
Entretanto, devido ao fato do seu c�digo fonte estar sob uma licen�a
BSD, o seu desenvolvimento foi continuado. Em 1994, dois estudantes de
Berkeley, Andrew Yu e Jolly Chen, adicionaram um interpretador SQL para
substituir a linguagem QUEL (desenvolvida para o Ingres) e o projeto foi
renomeado para Postgres95. Com a divulga��o de seu c�digo pela Internet,
Postgres95 iniciou uma nova vida como software open source.
Em agosto de 1996, Marc Fournier, Bruce Momjian e Vadim B. Mikheev
lan�aram a primeira vers�o externa da Universidade de Berkeley e deram in�cio
� tarefa de estabilizar o c�digo herdado. Tamb�m em 1996, o projeto foi
renomeado para PostgreSQL a fim de refletir a nova linguagem de consulta ao
banco de dados: SQL. A primeira vers�o de PostgreSQL, a 6.0, foi liberada em
janeiro de 1997. Desde ent�o, um grupo de desenvolvedores e de volunt�rios
de todo o mundo, coordenados pela Internet, t�m mantido o software e
desenvolvido novas funcionalidades.
As principais caracter�sticas acrescentadas nas vers�es 6.x s�o o
en:MVCC (Multiversion Concurrency Control � Controle de Concorr�ncia
Multivers�es), melhorias no SQL e novos tipos de dados nativos (novos tipos de
27
datas e hora e tipos geom�tricos).
Em maio de 2000 foi liberada a vers�o 7.0. As vers�es 7.x trouxeram as
seguintes novas funcionalidades: Write-Ahead Log (WAL), esquemas SQL,
outer joins, suporte a IPv6, indexa��o por texto, suporte melhorado a SSL e
informa��es estat�sticas do banco de dados.
A vers�o 8.0 foi lan�ada em janeiro de 2005 e entre outras novidades, foi
a primeira a ter suporte nativo para Microsoft Windows (tradicionalmente, o
PostgreSQL s� rodava de forma nativa em sistemas Unix e, em sistemas
Windows - atrav�s da biblioteca Cygwin). Dentre as muitas novidades da vers�o
8.x, pode-se destacar o suporte a tablespaces, savepoints, point-in-time
recovery, roles e Two-Phase Commit (2PC). Em Julho de 2009 foi lan�ada a
vers�o mais recente: 8.4.
2.5.2.3 Caracter�sticas t�cnicas do PostgreSQL
� Licen�a BSD (Berkeley Software Distribution). Portanto pode
ser utilizado, modificado e distribu�do por qualquer pessoa ou
empresa para qualquer finalidade, sem encargo, em quaisquer
dos sistemas operacionais suportados.
� Grande n�mero de recursos, tais como: Comandos
complexos, Chaves estrangeiras, Gatilhos, Vis�es, Integridade
de Transa��es, Controle de Simultaneidade Multi-vers�o,
(MVCC), Suporta m�ltiplas transa��es online concorrentes
entre usu�rios, Suporte a Rules (sistema de regras que
reescreve diretivas SQL), Suporte ao modelo h�brido objetorelacional,
Linguagem Procedural em v�rias linguagens
(PL/pgSQL, PL/Python, PL/Java, PL/Perl), Indexa��o por
texto, Estrutura para guardar dados Georeferenciados
PostGIS, entre outros.
� Op��es de extens�o atrav�s do usu�rio: Tipos de dados,
Fun��es, Operadores, Fun��es de Agrega��o (Agrupamento),
28
M�todos de �ndice por texto, Linguagens Procedurais (Stored
Procedures).
� Capacidade de lidar com grandes volumes de dados.
2.6 Sistema Distribu�do
Segundo Tanenbaum (1995), um sistema distribu�do � um conjunto de
computadores independentes que aparentam aos usu�rios um sistema �nico.
Outra defini��o tamb�m � apresentada por Coulouris (2005), que defende a
id�ia de um sistema distribu�do ser componentes de hardware e software
conectados em rede que comunicam suas a��es somente atrav�s de trocas de
mensagens.
Um sistema distribu�do pode possuir diversos elementos de hardware e
software de forma distribu�da, mas a distribui��o de apenas um dos elementos
j� o caracteriza como sistema distribu�do.
Neste cap�tulo ser�o descritas algumas caracter�sticas de sistemas
distribu�dos e aspectos importantes sobre seguran�a e telecomunica��es.
2.6.1 Conceito de Sistemas Distribu�dos, Seguran�a e Telecomunica��es.
Apesar de um sistema apresentar conceitos relacionados � distribui��o,
nem todos podem ser considerados como sistemas realmente distribu�dos. � o
caso de terminais inteligentes, por exemplo.
Os terminais inteligentes possuem baixa capacidade de armazenamento
e processamento e executam tarefas limitadas e pouco flex�veis transferindo
dados para um sistema principal. Por n�o possu�rem autonomia operacional
suficiente, estes n�o podem ser caracterizados como sistemas distribu�dos.
Os sistemas realmente distribu�dos devem apresentar a distribui��o de
controle, processamento e dados. Dessa forma um sistema que utiliza das vias
29
de tele processamento, n�o � necessariamente um sistema distribu�do de fato.
A distribui��o do processamento quer dizer que em cada nodo da rede
deve existir capacidade de processamento independente. Em outras palavras,
deve ser capaz de executar um processo em cada nodo e de gerenciar os
recursos locais de forma aut�noma. Este processamento pode ser constitu�do
desde um mainframe at� por uma esta��o de trabalho, e � o componente de
mais f�cil de ser identificado, sendo necess�rio a exist�ncia de m�ltiplos
processadores.
A distribui��o de dados � a possibilidade de localizar os arquivos ou
banco de dados pr�ximos aos locais onde s�o mais acessados. Para isto deve
existir um gerenciador de arquivos ou de banco de dados local e um
mecanismo que permita o acesso remoto a estes recursos. Um sistema
distribu�do permite que os dados armazenados sejam compartilhados pelos
diversos nodos onde existe capacidade de processamento. Este
compartilhamento pode ser obtido pela transfer�ncia de arquivos ou pelo
acesso remoto aos dados.
A distribui��o do controle significa que os processos executados nos
diferentes nodos interagem de forma cooperativa para satisfazerem um
determinado objetivo. Esta coopera��o � definida por um protocolo que
especifica completamente os servi�os a serem executados.
O controle � o de mais dif�cil dom�nio e, ao mesmo tempo, o de maior
import�ncia para o funcionamento de um sistema distribu�do. Os diferentes
computadores do sistema distribu�do podem ser heterog�neos e possuir, cada
um, o seu pr�prio sistema operacional. Por�m o conjunto deve operar como um
todo integrado e apresentando um comportamento homog�neo. A integra��o
destes sistemas locais heterog�neos em um �nico sistema homog�neo n�o �
uma tarefa trivial.
O controle distribu�do de uma aplica��o �, por natureza, diferente e mais
30
complexo do que o controle de um sistema centralizado. Em um local �nico
todos os dados necess�rios ao controle est�o imediatamente dispon�veis e o
sistema operacional local tem completa autonomia para gerenciar os recursos.
A sincroniza��o dos processos que operam simultaneamente em um sistema
centralizado � realizada por meio do compartilhamento de �reas de mem�ria.
A caracter�stica essencial do controle de um sistema distribu�do � a
coordena��o entre os diferentes processos por meio de mensagens. Esta
caracter�stica implica na impossibilidade da manuten��o de informa��o
completa e atualizada sobre cada processo de um sistema distribu�do. Os
algoritmos utilizados para a sincroniza��o das atividades distribu�das possuem,
por este motivo, uma complexidade maior que a apresentada por algoritmos
centralizados (LAMPORT, 1978).
O processamento distribu�do, assim como foi caracterizado, � mais do
que uma tecnologia �, tamb�m, uma metodologia para a concep��o e
implanta��o de sistemas de informa��o. Sua principal caracter�stica �
possibilitar o particionamento das atividades (e dos dados associados) de
acordo com a localiza��o geogr�fica das aplica��es mantendo, ao mesmo
tempo, a integra��o dos diversos componentes.
As caracter�sticas mais importantes dos sistemas distribu�dos podem ser
resumidas em: Diminuir o tr�fego de mensagens, processar localmente; Manter
a integra��o do sistema e atender �s necessidades locais.
Dessa forma, � poss�vel otimizar o desempenho e o custo global e
aumentar a confiabilidade das aplica��es. Um sistema distribu�do possui,
entretanto, uma maior complexidade que um sistema centralizado e apresenta
caracter�sticas funcionais que podem influir nos procedimentos operacionais e
de decis�o das empresas.
Podem ser citadas tr�s alternativas b�sicas para a escolha de crit�rios
de distribui��o: a distribui��o por �reas geogr�ficas por grupos funcionais e por
31
fun��es de processamento de dados.
A distribui��o geogr�fica dos dados � um dos crit�rios fundamentais para
o projeto de sistemas distribu�dos. Deve haver uma grande parcela de atividade
local (dados locais) e pequena atividade entre regi�es. Em grande parte dos
sistemas reais os dados apresentam a propriedade dos acessos serem
geograficamente agrupados. A id�ia b�sica para o particionamento dos dados
consiste em agrup�-los de acordo com as taxas de acesso para a identifica��o
dos poss�veis computadores regionais. Desta forma � minimizado o tr�fego
internodos.
A caracter�stica determinante desta forma de distribui��o � a rela��o
entre atividade local e a remota. Caso a taxa de atividade remota seja alta a
distribui��o n�o � a solu��o mais adequada. Este crit�rio leva � minimiza��o do
fluxo de dados internodos e � empregado em m�todos de aloca��o �tima de
arquivos em sistemas distribu�dos. Com exce��o de sistemas muito
especializados (defesa, alta seguran�a de opera��o) a maioria dos sistemas
distribu�dos reflete a agrega��o geogr�fica natural das organiza��es.
O desenvolvimento de computadores levou aos sistemas
departamentais. O conceito administrativo utilizado, neste caso, consiste em
alocar capacidade de processamento em cada departamento, isto �:
distribui��o por grupo de fun��es. Esta � uma alternativa � utiliza��o
compartilhada de um grande sistema central. Apenas os dados corporativos (e
os muito volumosos) s�o mantidos no sistema central. A integra��o do sistema
de informa��es automatizado � assegurada pela interliga��o dos diversos
computadores departamentais e do computador central.
Outra forma de distribui��o consiste na distribui��o por fun��es. Neste
caso est�o classificados os servidores especializados, tais como: servidores de
impress�o, servidores de arquivos, processadores vetoriais ou processadores
de uso geral especializados por software. Este tipo de distribui��o atribui � cada
tarefa um nodo adequado a fun��o espec�fica. Tais categorias de distribui��o
32
n�o s�o exclusivas sendo que um sistema pode conter partes dessas por se
encaixarem em categorias distintas.
2.7 Arquitetura Utilizada no Sistema Web.
Inicialmente a web era composta apenas por p�ginas est�ticas, ou seja,
n�o variava a cada solicita��o conforme alguma mudan�a de par�metros. Com
o tempo, houve a necessidade de tornar o conte�do das p�ginas din�mico, que
possibilitasse construir uma p�gina conforme uma nova requisi��o, o que n�o
era poss�vel utilizando somente HTML (Hyper Text Markup Language). Para
tanto o servidor web deveria processar os dados destas solicita��es e retornar
uma resposta personalizada. Surgiu ent�o o CGI (Common Gateway Interface)
(BRAZ, on-line).
O CGI possui limita��es quanto a sua utiliza��o em sistemas web de
grande escala, pois a cada execu��o do programa um novo processo � criado,
causando sobrecarga no servidor web. Ocorre tamb�m que os programas em
CGI s�o capazes de tratar apenas uma solicita��o, na qual um novo processo �
criado, os dados s�o enviados, processados e a resposta � retornada para o
navegador e o processo � finalizado. Com isso, n�o � poss�vel o
compartilhamento de recursos entre os CGIs. Este modelo apresenta
problemas de performance se submetido a grande volume de acesso.Para
amenizar estes problemas, foi adotado o uso de algumas linguagens de
programa��o como o Perl, ASP, PHP, Java e etc.
Em Java, no ambiente JEE (Java Enterprise Edition), que � voltado para
as aplica��es web, encontra-se alternativas como Applets, Servlets, JSP (Java
Server Pages), JSTL (Java Server Pages Standard Tag Library), EJB
(Enterprise Java Beans), entre outros. Para facilitar o desenvolvimento das
aplica��es Java geralmente se faz o uso de design patterns tamb�m conhecido
como padr�es de projeto e algum framework, tais como o STRUS, JSF,
Hibernate, entre outros.
33
2.7.1 Arquitetura Java EE e Design Patterns.
Um padr�o de projeto � definido como uma solu��o desenvolvida
utilizando boas pr�ticas para um problema comum que ocorre v�rias vezes. Um
padr�o de projeto documenta e explana um problema importante que pode
ocorrer no projeto ou implementa��o de uma aplica��o e ent�o discute a
melhor solu��o pr�tica para o problema (Marinescu, 2002).
Segundo a SUN, a plataforma J2EE (Java 2 Enterprise Edition) define um
padr�o para o desenvolvimento de aplica��es multicamadas. Nesta arquitetura,
a camada que cont�m as regras de neg�cio, normalmente implementada
utilizando Enterprise JavaBeans, pode ficar concentrada no servidor de
aplica��es, sendo compartilhada com diversas aplica��es clientes. As
aplica��es clientes n�o cont�m a l�gica do neg�cio, atendo-se somente �
camada de apresenta��o. Na camada de apresenta��o normalmente s�o
utilizadas as tecnologias de Servlets e JavaServer Pages.
Os Design Patterns buscam facilitar a reutiliza��o de projetos e
arquiteturas bem sucedidos. Eles auxiliam a escolher alternativas de projeto
que tornam um sistema reutiliz�vel e evitar alternativas que comprometam a
reutiliza��o.
Segundo Alur (2002) se destacam algumas vantagens de se usar cada um
destes padr�es, considerando que:
� Foram testados: refletem a experi�ncia e conhecimento dos
desenvolvedores que utilizaram estes padr�es com sucesso em
seu trabalho;
� S�o reutiliz�veis: fornecem uma solu��o pronta que pode ser
adaptada para diferentes problemas quando necess�rio;
� S�o expressivos: formam um vocabul�rio comum para expressar
grandes solu��es sucintamente;
� Facilitam o aprendizado: reduzem o tempo de aprendizado de uma
determinada biblioteca de classes. Isto � fundamental para o
34
aprendizado dos desenvolvedores novatos;
� Diminuem retrabalho: quanto mais cedo s�o usados, menor ser� o
retrabalho em etapas mais avan�adas do projeto.
A SUN disponibiliza um cat�logo de 15 padr�es J2EE, que fornece
solu��es para problemas tipicamente encontrados por arquitetos e designers de
aplica��es de software para a plataforma J2EE, conforme ilustra a Figura 3.
Figura 3: Core J2EE Patterns. Fonte: SUN.
35
Em poucas palavras � poss�vel descrever cada um destes padr�es em
suas respectivas camadas (Alur, 2002):
� Camada de apresenta��o: intercepting filter (Intercepta
solicita��es e respostas e aplica algum filtro); front controller
(Fornece um controlador centralizado para manter a l�gica de
processamento que ocorre na camada de apresenta��o e que,
erroneamente � colocado nas vis�es); view helper (Encapsula a
l�gica que n�o esteja relacionada � formata��o da apresenta��o
em componentes auxiliares);composite view (Cria uma vis�o
atrav�s da composi��o de outras vis�es); service to worker
(Combina um componente distribuidor com os padr�es Front
Controller e View Helper. Neste padr�o a responsabilidade de
recuperar o conte�do para apresentar � do controlador); dispatcher
view (Semelhante ao padr�o Service to Worker, mas, neste padr�o
a recupera��o do conte�do � responsabilidade das vis�es).
� Camada de neg�cios: business delegate (Reduz o acoplamento
entre o cliente e a camada de neg�cios); data transfer object
(Facilita o interc�mbio de dados entre as camadas); data transfer
object factory (Facilita e centraliza a cria��o de data transfer
objects); session facade (Fornece uma interface unificada para um
sistema distribu�do); composite entity (Representa uma pr�tica
mais recomendada para criar entity beans de granula��o grossa,
agrupando os objetos dependentes em um �nico entity bean); value
list handler (Gerencia o processamento e armazenamento em
cache de consultas que retornam uma grande quantidade de
informa��es); service locator (Encapsula a complexidade de
localiza��o e cria��o de servi�os de neg�cio e localiza os objetos
Home dos EJB).
� Camada de integra��o: data access object (Abstrai e encapsula o
acesso aos dados); service activator ( Facilita o processamento
ass�ncrono para Message-driven beans).
36
2.7.2 Componentiza��o na camada de visualiza��o com JSF
Segundo Gon�alvez (2007, p. 429) O JSF (Java Server Faces) � uma
tecnologia do mundo JEE e � desenhado para simplificar o desenvolvimento de
aplica��es Web. JSF torna f�cil o desenvolvimento atrav�s de componentes de
interface de usu�rio (GUI) e conecta esses componentes a objetos de neg�cios.
Tamb�m automatiza o processo de uso de Java Beans e navega��o de
p�ginas.
Java Server Faces disponibiliza o r�pido desenvolvimento de interfaces
para aplica��es que rodam no servidor web. Permite aos desenvolvedores
escrever aplica��es com facilidade, sem se preocupar com as complexidades
de lidar com navegadores e servidores Web. Tamb�m automatiza alguns
procedimentos como o controle e o transporte do c�digo entre formul�rios, a
l�gica de neg�cios, entre outros.
Java Server Faces realiza muito do trabalho pesado que geralmente
precisam ser implementados em Servlets e JSP. Possui um conjunto de
componentes que s�o essenciais para o desenvolvimento de aplica��es em
JSF.
Estes componentes funcionam em conjunto, ou seja, caso necessite de um
determinado componente que n�o existe no projeto, ele pode ser inserido sem
problemas. Hoje, existem diversos conjuntos de componentes, como por
exemplo: JBoss RichFaces, MyFaces Tomahawk, Oracle ADF, ICEfaces, entre
outros. H� tamb�m alguns fabricantes que desenvolveram suas pr�prias
implementa��es de JSF, tais como: MyFaces (Apache), JSF RI ou Mojarra (Sun
Microsystem) (Rafael Ponte,on-line).
De certa forma o JSF pode ser comparado ao framework Microsoft .net,
pois possui um conjunto de componentes visuais, que permite o conhecido
�arrastar e soltar�. Tamb�m por ser flex�vel na quest�o de cria��o de
componentes pr�prios a partir de classes de componentes, e permitir que o
desenvolvedor crie interfaces atrav�s de componentes fornecidos e manipule
37
eventos do lado cliente com grande facilidade.
Vale destacar que no ano de 2009 foi lan�ada a vers�o 2 do framework
JSF, que teve sua primeira vers�o lan�ada em 2003. Esta segunda vers�o veio
para corrigir e facilitar o uso de diversos novos recursos tais como:
� Suporte nativo a Ajax, n�o dispon�vel na primeira vers�o.
� Resolver problemas de incompatibilidade entre bibliotecas de
componentes.
� Permitir configura��es atrav�s de anota��es, o que antes era feito
somente via xml.
� Diminuir a complexidade da cria��o de componentes visuais.
� Comunica��o entre os componentes atrav�s de outros protocolos,
pois na primeira vers�o era poss�vel somente via GET, sendo esta
uma de suas falhas mais criticadas.
2.7.3 Componentiza��o na camada de neg�cios com EJB
Segundo Gon�alvez (2007, p. 544) O EJB ou Enterprise JavaBeans � um
componente servidor que roda em um container para EJB do servidor de
aplica��o. Considerado como um dos principais componentes da plataforma
JEE (Java Enterprise Edition), o EJB tem como principais objetivos da
tecnologia fornecer r�pido e simplificado desenvolvimento de aplica��es Java
baseadas em componentes, distribu�das, transacionais, seguras e port�veis.
Infelizmente essa n�o foi bem a realidade das vers�es anteriores as 3.0 da
tecnologia EJB, especialmente os Entity Beans, que sempre foram acusados de
baixa efici�ncia, alta complexidade e dificuldade de uso.
DEBU PANDA (2008, p.4) define Enterprise JavaBeans (EJB) como uma
plataforma para constru��o de aplica��es corporativas port�til, reutiliz�vel e
38
escal�vel, que utiliza a linguagem Java. Desde seu in�cio, o EJB tem sido
considerado um modelo de componente ou framework que permite que voc�
construa aplica��es corporativas Java sem ter que reinventar servi�os
necess�rios para a constru��o de uma aplica��o, como as transa��es,
seguran�as, persist�ncia automatizada e assim por diante.
DEBU PANDA (2008, p.5) descreve EJBs como componentes server-side
que s�o utilizados para construir partes de uma aplica��o, como a regra de
neg�cios ou a camada de persist�ncia. O desenvolvimento de componente
geralmente � visto como algo extremamente complexo como o CORBA ou
Microsoft COM+. O EJB3 mostra que um componente � o que deve ser:
Encapsular com efici�ncia o comportamento de uma aplica��o, dessa forma o
usu�rio de um componente n�o precisa conhecer suas opera��es internas, tudo
o que precisa saber � como ir e o que esperar de volta.
As principais vantagens do uso da tecnologia EJB, podem ser entendidas
atrav�s dos seguintes pontos:
� F�cil de usar: Focado na facilidade de uso, os recursos que mais
s�o real�ados s�o a programa��o POJO, as anota��es XML, o uso
intenso dos padr�es sens�veis e o JPA.
� Ac�mulo de solu��es integradas: O EJB oferece um conjunto de
solu��es para servidor, incluindo persist�ncia, messaging,
programas leves, remoting, servi�os de web, inje��o de
depend�ncia (DI) e interceptores. Isso significa que voc� n�o ter�
que perder tempo procurando ferramentas terceirizadas para
integrar � sua aplica��o.
� Padr�o aberto Java EE: O EJB possui uma especifica��o API
p�blica aberta, que as empresas utilizam para criar um container ou
a implementa��o do fornecedor de persist�ncia. O padr�o EJB �
desenvolvido pelo Java Community Process (JCP) proporcionando
um suporte maior, sem precisar de uma solu��o propriet�ria.
� Suporte maior ao fornecedor: O EJB � suportado por uma grande
variedade de empresas independentes. Incluindo as maiores
39
empresas do ramo de tecnologia do mundo, muito respeitadas e
financeiramente estabilizadas, como a Oracle e a IBM, assim como
os grupos JBoss e Geronimo. O suporte amplo ao fornecedor se
traduz em tr�s vantagens importantes para voc�. Primeira, voc� n�o
est� a merc� dos altos e baixos de uma empresa particular ou
grupo de pessoas. Segunda, muitas pessoas possuem interesses a
longo prazo para manter a tecnologia o mais competitiva poss�vel.
Voc� pode ser capaz de levar vantagem das melhores tecnologias
dentro ou fora do ambiente Java em um cronograma competitivo.
Terceira, os fornecedores concorrem entre si para fornecer recursos
n�o padronizados adicionados ao valor. Esses fatores ajudam a
manter o EJB continuamente na linha de evolu��o.
� Agrupamento, balanceamento de carga e failover: Os recursos
historicamente adicionados por muitos fornecedores de servidores
de aplica��es s�o suportes robustos para o agrupamento, balan�o
de carga e failover. Os servidores de aplica��o EJB possuem um
registro de trilha provado para suportar alguns dos ambientes de
servidores ativados por computa��o (HPC) de alto desempenho.
Mais importante que isso, voc� pode alavancar tal suporte sem
alterar o c�digo, sem intera��o de ferramenta terceirizada e com
configura��o relativamente simples (al�m do trabalho inerente em
configurar um agrupamento de hardware). Isto significa que voc�
pode confiar no agrupamento de hardware para medir sua aplica��o
com o EJB 3, caso precise.
Os beans s�o os componentes EJB e s�o classificados conforme sua
utilidade, sendo eles: Session Beans, Message Driven Beans, Entity Beans.
Cada tipo de bean tem um prop�sito e pode utilizar um subconjunto espec�fico
de servi�os EJB. O prop�sito real dos tipos de beans � proteger as poss�veis
sobrecargas contra os servi�os que surgem.
Os sesseion beans e os Message Driven Beand s�o usados para construir
l�gica de neg�cios e residem em um container, que gerencia esses beans e
40
fornece servi�o a eles. J� os Entity Beans s�o usadas para modelar a
persist�ncia de uma aplica��o.
Segundo DEBU PANDA (2008, p.14), um dos recursos mais atraentes do
EJB 3 � o modo com que ele controla a persist�ncia. Persist�ncia � a habilidade
de ter os dados contidos nos objetos Java automaticamente armazenados em
um banco de dados relacional como o Postgres SQL. A persist�ncia em EJB 3
� gerenciada pelo JPA. Ela persiste automaticamente aos objetos Java usando
uma t�cnica chamada mapeamento objeto-relacional (ORM). O ORM �
essencialmente o processo de mapeamento de dados contidos nos objetos
Java das tabelas de banco de dados usando configura��o. Ele desobriga o
desenvolvedor da tarefa de escrever o c�digo JDBC de baixo n�vel para manter
os objetos em um banco de dados.
Os frameworks que fornecem capacidade ORM para realizar persist�ncia
automatizada s�o conhecidos como frameworks ORM. Como o nome j� diz, um
framework ORM executa persist�ncia transparente usando metadados do
mapeamento objeto-relacional que define como os objetos s�o mapeados nas
tabelas de banco de dados. ORM n�o � um novo conceito e j� est� presente
por algum tempo. Oracle TopLink � provavelmente o framework ORM mais
antigo no mercado; o framework de fonte aberta JBoss Hibernate popularizou
os conceitos ORM entre a comunidade do desenvolvedor atual.
41
REFER�NCIAS BIBLIOGR�FICAS
ALECRIM, Emerson. JSE, JEE e JME: uma breve explica��o. Info Wester. S�o
Paulo - SP. 02 out. 2007. Dispon�vel em:
<http://www.infowester.com/versoesjava.php>. Acesso em 02 abr. 2009.
ALUR, Deepak; CRUPI, John; MALKS, Dan. Core j2ee patterns: as melhores
pr�ticas e estrat�gias de design. Rio de Janeiro: Campus, 2002.
BRAZ, Christian Cleber Masdeval. Introdu��o ao Java Server Pages. Dispon�vel
em: <http://www.tudodownloads.com.br/download/2552/Apostila_-
_Introducao_ao_JSP_Java_Server_Pages.html>. Acesso 23 mar. 2008
CONALLEN, Jim. Building Web Application With UML. 2. ed. 2002.
COULOURIS, George F.; DOLLIMORE, Jean; KINDBERG, Tim. Distributed
systems:concepts and design. 4th ed. 2005.
DESMOND D'Sousa. Objects, Components, and Frameworks with UML: The
Catalysis Approach.1998.
Friedrich Ludwig Bauer. NATO Science Committee, Garmisch, Germany, 7-11
Oct. 1968, Brussels, Scientific Affairs Division, NATO (1969) 231p.
GON�ALVES, Edson. Desenvolvendo aplica��es web com jsp, servlets, javaserver
faces, hibernate, ejb3 persistence e AJAX. Editora Ci�ncia Moderna: Rio de Janeiro,
2007.
IEEE, Institute. IEEE Std 830-1998. Recommended Practice for Software
Requirements Specifications. Institute of Electrical and Eletronic Engineers.
JANDL JUNIOR, Peter. Java Guia do Programador. Novatec Editora. 2007.
Dispon�vel em:
<http://www.novatec.com.br/livros/javaguia/capitulo9788575221099.pdf>
Acesso em 02 abr. 2008.
KOCH, Nora. A UML-based Methodology for Hypermedia Design. England. Out
2000.
LAMPORT, Time. Clocks and the Ordering of Events. CACM. Jul 1978, p 558-
565.
HORSTMANN, Cay S. Core Java 2 � Vol.1:Fundamentos.Editora Makron
Books: S�o Paulo SP, 2000.
MANGIONE, Carmine. Performance tests show Java as fast as C++. Java
World. 02 jan. 1998. Dispon�vel em: <http://www.javaworld.com/jw-02-1998/jw-
02-jperf.html>. Acesso em 01 jun. 2008.
MARINESCU, Floyd. EJB design patterns: advanced patterns, processes, and
42
idioms. New York: John Wiley & Sons, 2002.
MELO, Ana Cristina. Desenvolvendo aplica��es com UML 2.0: do conceitual �
implementa��o � 2.ed. Brasport. Rio de Janeiro, 2004.
MURUGESAN, S. Leverage global software development and distribution using
the internet and web. Cutter IT Journal. Mar 1999
NEWMAN, Alexander. Usando Java. Editora Campus: Rio de Janeiro, 1996.
OLIVEIRA, Jos� Palazzo Moreira de. Conceitos sobre Sistemas Distribu�dos.
UFRGS. Dispon�vel em: <http://palazzo.pro.br/sd/distr-dados.htm>. Acesso em
16 set 2010.
DEBU PANDA, REZA RAHMAN, DEREK LANE. EJB3 em a��o. Alta Books,
2008.
PRESSMAN, ROGER S. Engenharia de Software. 5� Ed. Rio de Janeiro:
McGraw- Hill, 2002.
Rafael Ponte. Anatomia do JSF - JavaServer Faces. Rafael Pontes. Cear�. 27
out. 2007. Dispon�vel em: <http://www.rponte.com.br/wpcontent/
uploads/2007/10/anatomia-jsf-javaserver-faces-cct.pdf>. Acesso em 20
mar.2010.
RUBIRA, Cec�lia Mary Fischer. Desenvolvimento Baseado em Componentes e
o Processo UML Components. Unicamp. 2008. Dispon�vel em:
<http://tolstenko.net/dados/Unicamp/2009.2/mc436/2009.2/Material de
Apoio/Slides/11_dbcUMLComp.pdf>. Acesso em 07 set. 2010.
SILBERSCHATZ, Abraham; Korth, Henry F e Sudarshan, S. Sistema de Banco
de Dados. Makron Books, 1999. p. 1.
SWEBOK. Dispon�vel em: <http://www.computer.org/portal/web/swebok>.
Acesso em 01 jun. 2008.
SUN, Sun Microsystems. Designing enterprise applications with the j2ee
platform enterprise edition. Dispon�vel em:
<http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e
/index.html>. Acesso em: 28 out. 2010.
TANENBAUM, Andrew S. Distributed Operating Systems. New Jersey: Prentice
Hall, 1995.
WIKIPEDIA. Sistema de Gerenciamento de Banco de Dados. Dispon�vel em:
<http://pt.wikipedia.org/wiki/Sistema_de_gerenciamento_de_banco_de_dados>.
Acesso em: 10 dez. 2009.
WIKIPEDIA. PostgreSQL. Dispon�vel em:
<http://pt.wikipedia.org/wiki/PostgreSQL>. Acesso em: 10 dez. 2009.
WIKIPEDIA. Engenharia de software. Dispon�vel em:
<http://pt.wikipedia.org/wiki/Engenharia_de_software >. Acesso em: 10 dez.
43
2009.
WIKIPEDIA. Engenharia de software baseada em componentes. Dispon�vel
em:<http://pt.wikipedia.org/wiki/Engenharia_de_software_baseada_em_compon
entes>. Acesso em: 10 dez. 2009.
WIKIPEDIA. Processo Unificado. Dispon�vel em:
<http://pt.wikipedia.org/wiki/Processo_Unificado>. Acesso em 10 dez. 2009.
WIKIPEDIA. IBM Rational Unified Process Dispon�vel em:
<http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process>. Acesso em: 10
dez. 2009

Tecnologias:

Confira outros conte�dos:

Introdu��o ao JDBC

Novidades do Java

Teste unit�rio com JUnit

Assista grátis a nossa aula inaugural

Perguntas frequentes

Quem somos?

Por que a programação se tornou a profissão mais promissora da atualidade?

Como faço para começar a estudar?

Em quanto tempo de estudo vou me tornar um programador?

Sim, você pode se tornar um programador e não precisa ter diploma de curso superior!

O que eu irei aprender estudando pela DevMedia?

Principais diferenciais da DevMedia

Qual o investimento financeiro que preciso fazer para me tornar um programador?

Como funciona a forma de pagamento da DevMedia?

Por Jean Em 2011

Nossos casos de sucesso

Leonardo Carlos

Eu sabia pouqu�ssimas coisas de programa��o antes de come�ar a estudar com voc�s, fui me especializando em v�rias �reas e ferramentas que tinham na plataforma, e com essa bagagem consegui um est�gio logo no in�cio do meu primeiro per�odo na faculdade.

Lucas Rodrigues

Estudo aqui na Dev desde o meio do ano passado! Nesse per�odo a Dev me ajudou a crescer muito aqui no trampo.
Fui o primeiro desenvolvedor contratado pela minha empresa. Hoje eu lidero um time de desenvolvimento!
Minha meta � continuar estudando e praticando para ser um Full-Stack Dev!

Her�clito J�nior

Economizei 3 meses para assinar a plataforma e sendo sincero valeu muito a pena, pois a plataforma � bem intuitiva e muuuuito did�tica a metodologia de ensino. Sinto que estou EVOLUINDO a cada dia. Muito obrigado!

Julio Cablen

Nossa! Plataforma maravilhosa. To amando o curso de desenvolvimento front-end, tinha coisas que eu ainda n�o tinha visto. A did�tica � do jeito que qualquer pessoa consegue aprender. S�rio, to apaixonado, adorando demais.

Joelberth Sena

Adquiri o curso de voc�s e logo percebi que s�o os melhores do Brasil. � um passo a passo incr�vel. S� n�o aprende quem n�o quer. Foi o melhor investimento da minha vida!

Felipe Nunes

Foi um dos melhores investimentos que j� fiz na vida e tenho aprendido bastante com a plataforma. Voc�s est�o fazendo parte da minha jornada nesse mundo da programa��o, irei assinar meu contrato como programador gra�as a plataforma.

Wanderson Oliveira

Comprei a assinatura tem uma semana, aprendi mais do que 4 meses estudando outros cursos. Exerc�cios pr�ticos que n�o tem como n�o aprender, est�o de parab�ns!

Jos� Lucas

Obrigado DevMedia, nunca presenciei uma plataforma de ensino t�o presente na vida acad�mica de seus alunos, parab�ns!

Eduardo Dorneles

Aprendi React na plataforma da DevMedia h� cerca de 1 ano e meio... Hoje estou h� 1 ano empregado trabalhando 100% com React!

Adauto Junior

J� fiz alguns cursos na �rea e nenhum � t�o bom quanto o de voc�s. Estou aprendendo muito, muito obrigado por existirem. Est�o de parab�ns... Espero um dia conseguir um emprego na �rea.

Ver todos os casos de sucesso