BREVE ESTUDO

SOBRE
ENGENHARIA DE
COMPONENTES
Este artigo descreve assuntos relacionados
componentizao, que devem ser analisados antes de
um estudo mais aprofundado neste universo da
componentizao de software. Os conceitos tratados
sero a Engenharia de software, engenharia web e enge
3



Gostei

(1)


(0)


1. INTRODUO
...............................................................................................................
..... 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
Histrico...................................................................................................
................... 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 Aplicaes 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
TECNOLGICA..........................................................................................
...... 20
2.5.1 Java
...............................................................................................................
............. 20
2.5.1.1
Histrico...................................................................................................
........................ 20
2.5.1.2 A linguagem de programao Java
.................................................................................. 21
2.5.1.3 A plataforma tecnolgica
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 histria do PostgreSQL
.................................................................................. 25
2.5.2.3 Caractersticas tcnicas do PostgreSQL
.......................................................................... 27
2.6 SISTEMA DISTRIBUDO
......................................................................................................... 28
2.6.1 Conceito de Sistemas Distribudos, Segurana e
Telecomunicaes....................... 28
2.7 ARQUITETURA
WEB........................................................................................................
..... 32
2.7.1 Arquitetura Java EE e Design
Patterns...................................................................... 33
2.7.2 Componentizao da camada de visualizao com JSF
.......................................... 36
2.7.3 Componentizao da camada de negcios com EJB
............................................... 37
REFERNCIAS
BIBLIOGRFICAS.......................................................................................
.... 41
Jean Wagner Kleemann
Campo Grande - 2010
2
1. INTRODUO
No processo desenvolvimento de software, uma questo muito discutida
a produtividade. Os sistemas esto a cada dia mais complexos e muitos
padres de desenvolvimento e gerenciamento de processos no atendem as
expectativas desejadas.
Na busca de novas metodologias e prticas de desenvolvimento de
software, algumas solues como a orientao a objetos e padres de projeto,
ainda deixam distante da sonhada reutilizao e rpida implementao de
sistemas complexos. Contudo a componentizao uma alternativa capaz de
lidar com problemas ligados ao reaproveitamento, no somente de cdigo, mas
tambm de funcionalidades e interfaces, independentemente de plataforma,
diminuindo custos e tempo de desenvolvimento.
Com o desenvolvimento baseado em componentes, surge a idia de "crie
uma vez, use onde quiser". Neste conceito no necessrio escrever uma nova
aplicao codificando linha a linha, mas consiste em montar sistemas utilizando
componentes j implementados. Proporcionando assim o rpido
desenvolvimento, facilidade de manuteno e maior qualidade dos sistemas.
Entretanto, encontrar componentes que se encaixam em domnios de
negcios distintos algo difcil, sendo sugerido ento a implementao de seus
prprios componentes. Para isso essencial a utilizao de padres em todo
processo de desenvolvimento de componentes de software.
Este estudo descreve assuntos relacionados componentizao, que
devem ser analisados antes de um estudo mais aprofundado neste universo da
componentizao de software. Os conceitos tratados sero a Engenharia de
software, engenharia web e engenharia de componentes, bem como a
tecnologia Java, Design Patterns, PostgreSQL, RUP e Sistemas distribudos.
3
2. ESTUDO SOBRE A ENGENHARIA DE COMPONENTES
2.1 Engenharia de software
Segundo Friedrich Ludwig Bauer (1969, p. 231), "Engenharia de
Software a criao e a utilizao de slidos princpios de engenharia a fim de
obter software de maneira econmica, que seja confivel e que trabalhe
eficientemente em mquinas reais".
2.1.1 Conceitos
A engenharia de software uma rea do conhecimento da computao
voltada para a especificao, desenvolvimento e manuteno de sistemas de
software aplicando tecnologias e prticas de gerncia de projetos e outras
disciplinas, objetivando organizao, produtividade e qualidade.
Essas prticas e tecnologias envolvem linguagens de programao,
banco de dados, ferramentas, plataformas, bibliotecas, padres, processos e
qualidade de software, entre outros.
Os fundamentos cientficos 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. Alm disso, a engenharia de software deve oferecer
mecanismos para se planejar e gerenciar o processo de desenvolvimento de
um sistema de informao Sistema Computacional, pois ambos se confundem.
O fundamento da engenharia de software a camada de processo. O
processo de engenharia de software mantm 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 trs fases distintas: Definio (Anlise do
sistema, planejamento do projeto de software e anlise de requisitos),
Desenvolvimento (projeto de software, codificao e realizao de testes do
software), Manuteno (correo, adaptao e melhoramento funcional).
Estas fases ainda so complementadas por Atividades de apoio, como
por exemplo: Controle de Configurao, Controle de Qualidade, Verificao e
Validao, 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 trs tpicos para melhor
entendimento, sendo eles:
Fundamentos de qualidade de software: Cultura e tica de
engenharia de software,Valores e custos de qualidade, Modelos e
caractersticas de qualidade, Melhoria da qualidade.
Gerncia do processo de qualidade de software: Garantia de
qualidade de software, Verificao e validao, Revises e
auditorias,
Consideraes prticas: Requisitos de qualidade para aplicaes,
Caracterizao de defeitos, Tcnicas de gerncia de qualidade de
software, Medidas de qualidade de software.
Ao contrrio de alguns autores que se apiam em testes de software
para garantir qualidade, o SWEBOK esclarece que essa rea no exige a
execuo do software para avali-lo, em contraposio rea de conhecimento
teste de software.
5
Tendo em vista que a qualidade no incorporada ao produto depois de
concludo, 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 tambm pode ser definida como a integrao
entre os requisitos funcionais, requisitos de desempenho, padres de
desenvolvimento claramente documentados e demais caractersticas implcitas.
Podemos citar algumas prticas caractersticas de qualidade de
software:
Prototipao.
Testes de Aceitao como Especificao.
Testes Unitrios.
Reviso de Cdigo.
Integrao Contnua.
Anlise de Risco.
Anlise Esttica.
Automao de Processos.
2.2 Engenharia de componentes
A Engenharia de componentes uma derivao da engenharia de
software, focada na decomposio dos sistemas, em componentes funcionais e
lgicos com interfaces bem definidas, usadas para comunicao entre os
prprios componentes, que esto em um nvel mais elevado de abstrao do
que os objetos, com isso a comunicao 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
construo de sistemas baseados em computador usando "componentes" de
software reutilizveis (PRESMMAN, 2002).
A prtica da tecnologia de software baseado em componentes, baseia-se
no desenvolvimento atravs de componentes reutilizveis, levando a reduo
de tempo de desenvolvimento, e facilitando as mudanas e a implantao de
novas funcionalidades.
Dessa forma, o processo de engenharia de software baseada em
componentes tem mudado o modo pelo qual sistemas so desenvolvidos, pois
desloca a nfase da programao do software para a composio de sistema
de software com base em componentes (PRESMMAN, 2002).
2.2.1 Histrico
Durante a Conferncia de Engenharia de Software da OTAN realizada
em 1968, Mcilory sob o titulo "Mass Produced Software Components"
(Produo de Componentes de Software em Massa), expe a idia de que o
desenvolvimento de software deve empenhar-se em desenvolver componentes
reusveis 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 atravs da integrao de componentes de
software. Em seguida, como primeira implementao da infra-estrutura de sua
idia, incluiu pipes (para comunicao entre processos) e filtros no sistema
operacional Unix.
Em 1976, DeRemer props um paradigma de desenvolvimento, que
consistia na idia do sistema ser construdo como um conjunto de mdulos
independentes e depois interligados. J na dcada de 80, com o surgimento da
orientao a objetos e a possibilidade de reutilizao, 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. Porm a partir desse ponto comea se
diferenciar, pois comea a ser analisado os requisitos com objetivo de buscar
mdulos que sejam mais adequados composio, ao invs de iniciar a
construo e partir para tarefas de projeto mais detalhadas.
Ao fazer essa anlise dos subconjuntos ou mdulos do sistema, pode se
fazer o uso de componentes j existentes, sendo componentes prprios 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
mudana, com outros componentes para construir algo maior.
2.2.3 Reuso
O Reuso o objetivo principal da engenharia de software baseada em
componentes. No se trata somente de reutilizao de cdigo, pois abrange
tambm os artefatos envolvidos durante o todas as etapas de desenvolvimento.
Dentro da engenharia de componentes, so observadas algumas
caractersticas positivas e outra nem tanto, mas que valem ser destacadas:
Os riscos so menores ao usar um componente j existente em
8
relao ao desenvolvimento de algo a partir do zero.
O aumento da produtividade, tendo em vista a reduo de esforos
pela equipe de desenvolvimento. Seguindo a idia Crie uma vez,
use onde quiser.
A qualidade e confiabilidade do produto e so maiores, pois o
componente reutilizado j foi testado e aprovado.
No caso de componentes comercias, pode-se no ter acesso ao
cdigo fonte ou depender de direitos autorais e licenas.
Resistncia da parte das equipes de desenvolvimento, pois exige
forte padronizao (investimento de tempo e controle de qualidade)
e documentao (investir mais tempo nos artefatos). A adoo de
novas prticas de desenvolvimento geralmente encontra forte
resistncia a mudanas por parte da equipe.
2.2.4 Design Patterns
Dedign Patterns ou padres de projeto significa um grupo de prticas
para definir o problema, a soluo e em qual situao aplicar esta soluo e
suas conseqncias no desenvolvimento de software.
Os padres so desenvolvidos a partir de experincias prticas em
projetos reais. resultado da experincia de arquitetos com experincia, que
aplicam usam estes padres e experimentam o resultado em seus prprios
problemas. A experincia desses arquitetos certamente proporciona a
abordagem correta para um problema especfico, da forma mais indicada.
Fazendo uso de tais padres, temos como resultado uma qualidade de
cdigo, permitindo a reutilizao de forma flexvel e expansvel. Por se tratar de
questes que nasceram de um problema real, e a soluo foi testada e
documentada, os padres aumentam de forma significativa a produtividade e
qualidade, pois a soluo j est definida.
9
2.2.5 UML Components
A UML pode ser definida como uma linguagem de diagramao da
metodologia orientada a objetos, que serve de apoio anlise de sistemas,
desde o levantamento dos requisitos at a implantao de um sistema.
composta por diversos elementos bsicos que representam as
diferentes partes de um sistema, como por exemplo: Classe, Interface, Nota,
Pacote, Caso de Uso, Atividades, dentre outros. Alm disso, a UML permite a
criao de elementos prprios atravs dos esteretipos, valores de etiqueta e
restries, de acordo com Melo (2004).
A UML na verso 2.0 composta por treze diagramas, divididos nas
categorias estruturais (caractersticas que no mudam com o tempo) e
dinmicos (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 srie de diagramas para representao de
componentes e suas especificaes, interaes e integrao com demais
sistemas. Segundo RUBIRA (2008), a UML Components, atende todas as fases
de elaborao 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 especificao dos requisitos, que independente de
tecnologia a ser utilizada, ocorre a modelagem lgica do negcio. O processo
UML Components mostra os artefatos envolvidos nesta fase, mas no descreve
como devem ser produzidos, sendo eles:
Processo do Negcio (Bussines Process): Se trata de uma
11
representao grfica, atravs de um diagrama de atividades,
descrevendo as atividades que representam o funcionamento do
negcio em si. Serve para melhor compreenso do domnio,
envolvendo vrias funcionalidades do sistema e mostrando a
relao entre elas, e separando as atividades manuais e
automticas.
Modelo Conceitual do Negcio (Business Concept Model):
Representa as entidades do negcio 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 atravs de diagramas de casos de uso.
Na Fase seguinte, de especificao dos componentes, tambm
independe de tecnologia, e nesta fase so levantadas as interfaces de sistema
e de negcio, bem como o detalhamento da seqncia de atividades para
desenvolver os componentes. Essas atividades So descritas em trs etapas,
sendo elas: a identificao dos componentes, interao entre os componentes e
especificao final.
O processo de Identificao dos componentes baseado nas interfaces
do sistema, atravs de um procedimento intuitivo. Tambm feito o uso de
diagramas de casos de uso especficos e diagramas de fluxo e operao. O
modelo de tipos do negcio (Business Type Model) indicado nesta fase, pois
restringe as entidades relevantes para o domnio da soluo, focado nas
responsabilidades do sistema e no dos atores.
Na Interao entre os componentes necessrio descobrir as operaes
de negcio que esto ligadas ao relacionamento entre os componentes, atravs
de diagramas dinmicos, como de colaborao, de seqncia ou de atividades.
12
Na especificao final dos componentes, cabe o Modelo de Informao
das Interfaces (Interface Information Model), que porve a relao entre cada
interface e as entidades do modelo de negcio. 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 sero adquiridos, localizados,
reutilizados ou implementados. O processo UML Components lista possveis
maneiras de criar os componentes de software, mas no detalha cada uma
delas.
Aquisio dos componentes: Reutilizao de componentes prontos
ou a utilizao de novos componentes.
Localizao de componentes prontos: buscar por servio fornecido
pelo componente, considerando a semelhana de seus contedos.
Reutilizao de componentes: Pode ser necessrio adaptar os
componentes reutilizados ou at mesmo as funcionalidades do
sistema (renegociao dos requisitos).
Implementao dos Componentes: Deve-se utilizar um modelo de
componente j existente, tais como: EJB, COM+, etc.
Por ultimo, na montagem do sistema, tambm dependente da tecnologia,
feita a implementao dos conectores e a ligao entre os componentes e os
conectores do sistema. Nessa fase observada a adaptao 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 princpios de engenharia e abordagens disciplinadas para o
desenvolvimento, implantao e manuteno de aplicaes baseadas na Web.
13
O ambiente Web possui diversas caractersticas, valendo destacar a
concorrncia, carga imprevisvel, disponibilidade, sensibilidade ao contedo,
evoluo dinmica, imediatismo, segurana e esttica, que impulsionaram uma
nova dinmica aos processos j existentes, dando origem a uma nova subrea
da Engenharia de Software, a Engenharia Web (PRESSMAN, 2005).
Os webistes podem variar de pginas estticas at verdadeiros sistemas
baseados na Web(lojas virtuais, ambientes cooperativos, sistemas de gerncia
empresarial, etc.). Este tipo de website definido como Sistemas de
Informao
Web (Web-based Information Systems - WISs) e ao conjunto amplo de todas
as
aplicaes Web como Web Applications (WebApps).
O captulo seguinte apresenta uma viso geral das metodologias e
prticas da UML que podem ser aplicadas na modelagem de sistemas WEB.
2.2.3.1 Modelagem de Aplicaes Web com UML
A metodologia Engenharia Web Baseada em UML (UML-based Web
Engineering UWE) (KOCH, 2002) define um conjunto de modelos a serem
construdos no desenvolvimento de uma aplicao Web, uma linguagem de
modelagem para a elaborao desses artefatos e um processo para construo
dos modelos.
As principais atividades no processo de modelagem so: anlise de
requisitos, projeto conceitual, projeto de navegao, projeto de apresentao,
modelagem de tarefas e modelagem de implantao.
A abordagem UWE apia o desenvolvimento de aplicaes Web com foco
especial na sistematizao, personalizao e gerao automtica de cdigo.
Indica tambm a utilizao de casos de uso para a especificao de requisitos
e, baseado nos casos de uso especificados, o projeto conceitual produz um
modelo conceitual do problema, definido em termos de classes e associaes
14
entre classes relevantes do domnio.
O projeto de navegao utiliza o modelo conceitual como base e definido
em duas etapas: definio do modelo de espao de navegao e construo do
modelo de estrutura de navegao. O primeiro modelo mostra quais objetos
podem ser vistos atravs da navegao pela aplicao Web e , portanto, um
modelo de anlise. O segundo modelo baseado no primeiro e define como os
objetos so visitados, sendo construdo na fase de projeto.
O projeto de apresentao consiste na modelagem de interfaces com o
usurio abstratas, mostrando como a estrutura de navegao definida
anteriormente apresentada ao usurio.
Ele dividido em uma parte esttica e outra dinmica. A parte esttica
representada por uma forma particular de diagrama de classes que usa uma
notao de composio de classes. Elementos de apresentao so
representados por classes estereotipadas e suas partes internas so
representadas graficamente dentro do elemento de modelo classe, podendo
ter vrios nveis de aninhamento de elementos grficos.
Para refinar os casos de uso, diagramas de atividade podem ser
utilizados, modelando de forma mais detalhada a interao com o usurio. Por
fim, diagramas de implantao podem ser usados para documentar a
distribuio dos componentes da aplicao Web.
As Extenses de Aplicaes Web (Web Application Extensions WAE)
(CONALLEN, 2002) so extenses ao meta-modelo da UML para a
modelagem de caractersticas especficas de aplicaes Web. A WAE define
extenses apropriadas para modelar diversos componentes tpicos do
desenvolvimento de aplicaes Web, usando elementos do meta-modelo da
UML adicionados de esteretipos pr-definidos para simbolizar os conceitos
necessrios.
Alm dos esteretipos, a WAE prev a definio de valores etiquetados
15
(tag values), representados entre colchetes, e restries (constraints),
representadas entre chaves, para alguns elementos.
A WAE voltada para apoiar a elaborao de modelos de projeto, tendo
em vista que essa fase mais suscetvel tecnologia. A fase de projeto
dividida em duas vises: a viso lgica, que est em um nvel mais alto de
abstrao, definindo classes e associaes, e a viso de componentes, que
trata dos arquivos que efetivamente comporo o sistema implementado
(pginas e diretrios).
Para a viso lgica, so definidos trs esteretipos principais aplicados
sobre o elemento classe do meta-modelo da UML e diversos esteretipos de
associao, como mostram as tabelas 1 e 2, respectivamente. Tais esteretipos
podem ser utilizados para a criao de diagramas de classes que representem
os elementos Web que compem o sistema, chegando a um nvel de detalhes
maior do que os diagramas de classe da fase de anlise (pois j incluem
informaes da plataforma de desenvolvimento), mas ainda num nvel de
abstrao lgico.
Esteretipo O que a classe estereotipada representa
<<server page>> Uma pgina Web dinmica que efetua processamento no
servidor e gera um resultado possivelmente diferente a
cada requisio. Suas operaes representam funes
do script e seus atributos representam variveis visveis
no escopo da pgina.
<<client page>> Uma pgina Web esttica que simplesmente retornada
ao cliente quando requisitada, sem gerar processamento.
Pode conter scripts do lado do cliente (client-side),
portanto seus atributos e operaes referem-se a tais
scripts.
<<HTML form>> Formulrios HTML para entrada de dados. Seus atributos
representam os campos do formulrio. Tais formulrios
no possuem operaes. Qualquer operao que interaja
com o formulrio deve ser propriedade da pgina que o
contm.
Tabela 1: Esteretipos de classe utilizados na viso lgica do projeto
16
Alm desses elementos bsicos, para o que Conallen chama de Projeto
Avanado, existem esteretipos para representao de outros elementos da
viso lgica da camada Web, a saber: conjunto de quadros (classe com
esteretipo <<frameset>>), alvo de link (classe com esteretipo <<target>>),
link de destino (associao mltipla com esteretipo <<target link>>),
ibliotecas
de script (classe com esteretipo <<script library>>) e objeto de script (classe
com esteretipo <<script object>>).
Esteretipo O que a associao estereotipada representa
<<link>> Um link normal entre pginas, representado em HTML pela
tag <a>. Parmetros codificados como parte da URL segundo
o protocolo http podem ser representados como atributos da
associao.
<<build>> Relacionamento direcional entre uma server page e uma
client page que indica que a sada HTML do processamento
da pgina do servidor a pgina do cliente.
<<submit>> Relacionamento direcional entre um html form e uma server
page, representando o envio dos dados dos campos do
formulrio para a pgina do servidor para processamento.
<<redirect>> Ao de redirecionamento de uma pgina para outra.
<<forward>> Ao de delegao de uma pgina para outra. Difere do
redirecionamento por manter o contexto da requisio feita
primeira pgina.
<<object>> Relacionamento de confinamento entre uma pgina e um
objeto, como uma Applet ou controle ActiveX.
<<include>> Uma associao direcional entre uma server page e uma
outra pgina que indica que o contedo desta ltima ser
processado (somente no caso de uma pgina do servidor) e
includo na primeira.
Tabela 2: Esteretipos de associao utilizados na viso lgica do projeto
Para a viso de componentes, so definidos trs esteretipos para o
elemento de modelo componente da UML: <<static page>>, componente que
representa pginas estticas, ou seja, sem processamento no lado do servidor;
<<dinamic page>>, componente que representa pginas dinmicas; e
<<physical root>>, pacote de componentes representando uma abstrao de
uma hierarquia de arquivos que contm recursos disponveis solicitao no
servidor Web.
17
Por meio de diagramas de componentes, a viso de componentes busca
modelar o mapeamento entre os arquivos fsicos (representados pelos
componentes com os trs esteretipos citados) e as representaes lgicas
apresentadas na viso lgica (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 perodo de desenvolvimento,
relacionando as tecnologias e procedimentos a serem utilizados.
Estas reas dentro do processo de desenvolvimento sero usadas como
alicerce para controlar o desenvolvimento do projeto, determinando em que
fase as tcnicas devem ser aplicadas. Em sntese o processo de
desenvolvimento de software determina uma forma para executar as fases de
criao, implantao e manuteno.
2.4.1 Processo Unificado
O processo unificado PU resultado de trs processos de
desenvolvimento e notaes, reunindo as vantagens de cada um. Este
processo unificado estabeleceu uma notao 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 construo de
softwares, baseado na construo de artefatos de software atravs da UML, e
no apenas em documentao, tambm baseado em componentes.
Como os artefatos so produzidos em fases distintas, e refinados ao
longo do tempo, eles ajudam a organizar as iteraes e a direcionar o projeto,
18
uma vez que o PU baseado em casos de uso durante praticamente todas as
fases. Portanto estes artefatos so primordiais para orientar a conduo do
projeto.
2.4.2 Rational Unified Process (RUP)
O Rational Unified Process (RUP) foi desenvolvido pela IBM, sendo uma
ramificao mais detalhada do PU, possuindo um grande conjunto de manuais
e modelos de artefatos a serem produzidos ao longo do processo, alm de
tutoriais da ferramenta Rational Suite (conjunto de ferramentas construdas em
torno do RUP).
O processo do RUP disponibiliza uma abordagem baseada em
disciplinas para atribuir tarefas e responsabilidades dentro de uma organizao
de desenvolvimento e, assim como o PU. Tambm baseado em casos de
uso, orientado pela arquitetura, iterativo e incremental, apresentando uma
gama
de papis, disciplinas, tarefas e artefatos.
Integrado ao RUP esto algumas prticas 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 mudanas de software.
2.4.2.1 Fases
O RUP herda quatro fases do PU, sendo elas:
Concepo: definida a viabilidade do projeto como negcio,
19
atravs da delimitao de seu escopo, e de estimativas de
custo, cronograma e retorno sobre o investimento (ROI).
Riscos so identificados e gerenciados, so definidos os
requisitos funcionais e no funcionais, e traado um esboo
da arquitetura do sistema, que servir como alicerce para sua
construo. So definidas as primeiras verses do modelo de
negcio, do modelo de casos de uso, da lista de riscos e suas
prioridades, do plano de projeto, da arquitetura do sistema.
Elaborao: Refinamento do sistema, com a identificao de
quase todos os casos de uso, com o detalhamento da
arquitetura traada na fase anterior e com o gerenciamento
contnuo dos riscos envolvidos. Estimativas realistas feitas
nesta fase permitem preparar um plano para orientar a
construo do sistema nas fases posteriores. possvel que
se tenha a uma verso completa do modelo de negcios.
Construo: Nesta fase o sistema efetivamente
desenvolvido e, em geral, tem condies de ser operado,
mesmo que em ambiente de teste, pelos clientes. Ao final da
fase de construo tem-se um software executvel, a
atualizao de artefatos do sistema refletindo o estado atual
do sistema, e um manual do usurio detalhado.
Transio: O sistema entregue ao cliente para o uso em
produo. Nesta fase testes so realizados, e um ou mais
incrementos do sistema so implantados, e se necessrio,
defeitos podem ser corrigidos. tambm nessa fase que os
usurios recebem treinamento para a operao do sistema.
20
2.5 Plataforma tecnolgica
2.5.1 Java
O Java uma plataforma de desenvolvimento que chama a ateno de
analistas, projetistas e programadores, pois resultante de um grande trabalho
de pesquisa cientfica e tecnolgica que ser descrito nos tpicos seguintes.
2.5.1.1 Histrico
Segundo Peter Jandl Junior, 2007, em 1991 um pequeno grupo de
projeto da Sun Microsystems denominado Green, pretendia criar uma nova
gerao de computadores portteis inteligentes, capazes de se comunicar de
muitas formas, ampliando suas potencialidades de uso. Para tanto se decidiu
criar tambm 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
programao para tal desenvolvimento foi C++, aproveitando suas
caractersticas e a experincia dos integrantes do grupo no desenvolvimento de
produtos. Mas mesmo o C++ no permitia realizar com facilidade tudo aquilo
que o grupo visionava.
James Gosling, um dos lderes do projeto, decidiu pela criao de uma
nova linguagem de programao que pudesse conter tudo aquilo considerado
importante e que ainda fosse simples, porttil e fcil de programar. Surgiu
ento
a linguagem interpretada Oak (carvalho em ingls), batizada assim em razo
da
existncia de uma destas rvores em frente ao escritrio de Gosling. Para dar
suporte linguagem tambm surgiram o Green OS e uma interface grfica
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 execuo de cdigo 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, ento o interesse pela soluo se mostrou
explosivo. Logo no incio de 1996 a Netscape Corp. lana a verso 2.0 de seu
navegador, o qual incorpora as capacidades de efetuar o download e realizar a
execuo de pequenas aplicaes Java denominadas applets.
Numa iniciativa indita, 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 especificao da linguagem
e do ambiente de execuo tambm foram disponibilizados publicamente,
progressivamente foram aparecendo kits para outras plataformas, tais como
IBM OS/2, Linux e Apple Mac.
Um ano aps seu anncio, ocorre o primeiro grande evento da linguagem
Java, o JavaOne Conference, que, desde ento, vem sendo usado para
apresentar as novas caractersticas, casos de sucesso, produtos e tecnologias
associadas. Foi assim que se iniciou a histria de sucesso do Java.
2.5.1.2 A linguagem de programao Java
A linguagem Java possui algumas caractersticas que, em conjunto,
diferenciam-na das demais linguagens de programao. Dentre os diversos
autores da literatura Java como Horstmann (2000), Newman (1996), entre
outros, destacam caractersticas que so alguns pontos-chave da Linguagem:
Orientada a Objetos Tudo em Java so classes ou instancias de
classes, por isso Java totalmente orientada a objetos, pois,
possui mecanismos para abstrao de dados (atravs das
classes), encapsulamento (ocultar do usurio o funcionamento
22
interno de uma classe), herana (criar uma nova classe a partir de
outra) e polimorfismo (diferentes classes podem definir mtodos
de mesmo nome).
Independente de Plataforma Os programas em Java utilizam
uma forma de compilao intermediria que resulta em uma
codificao denominada bytecode, um tipo de linguagem de
mquina (baixo nvel) 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 Automtico de Memria - A JVM possui um
mecanismo chamado de Garbage Collector (Coletores) que
responsvel por alocar e liberar os dados da memria
automaticamente. Com isso no necessrio que o
desenvolvedor realize tais procedimentos manualmente,
eliminando algumas falhas comuns como: tentar acessar um
objeto que j foi liberado da memria ou esquecer de liberar um
objeto.
Desempenho Nas primeiras verses, o Java apresentava certa
limitao quanto a performance, mas isto foi superado com
algumas adaptaes na JVM. Um compilador JIT (Just In Time)
foi incorporado na JVM que passou a interpretar os bytecodes
durante a execuo do programa. Conforme as novas geraes
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 excees: Em alguns casos, a ocorrncia de
algum erro durante a execuo de um programa pode fazer com
que o computador trave sendo necessrio reinicia-lo. Com a
utilizao do Java este tipo de evento no acontece, pois, a JVM
verifica em tempo de execuo um conjunto de eventos (acesso a
memria, abertura de arquivos, etc.) e ao encontrar algum
23
impedimento ou inconsistncia gera uma exceo (uma espcie
de mensagem com a descrio do erro).
Segurana: Diferente das demais linguagens, em Java a
aplicao no se comunica com o Sistema Operacional, e sim
com a JVM que por sua vez interage com o Sistema. O bytecode
gerado pela aplicao deve passar primeiro por alguns requisitos
de segurana da JVM, que caso encontre alguma irregularidade
impede a execuo do cdigo.
Multithread: Capaz de executar vrias tarefas (conjunto de
instrues) ao mesmo tempo dentro da aplicao. Cada uma
destas tarefas conhecida como thread.
Vale destacar que para desenvolver programas em Java, primeiramente
necessrio um editor que permita salvar o programa fonte com a extenso
.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) prpria para Java, como o NetBeans ou
Eclipse. Posteriormente com base no arquivo .java, o compilador Java
responsvel por gerar o arquivo de extenso .class, que o bytecode
propriamente dito. Ento a JVM interpreta e executa os arquivos de classe
fazendo o uso do cdigo nativo (usado para comunicar-se com o hardware) do
Sistema Operacional.
Dessa forma o cdigo Java o mesmo para diferentes arquiteturas, pois
o que muda so as distribuies da JVM, livrando o desenvolvedor de ajustar o
cdigo conforme a plataforma.
2.5.1.3 A plataforma tecnolgica 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 so aprimorados do JSE.
Desenvolvido para aplicaes baseadas em cliente/servidor.
JEE (Java Enterprise Edition): As aplicaes WEB so
fundamentadas nesta plataforma. As implementaes neste
padro so muito complexas, contm 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 mveis (telefones celulares, palmtops,...).
2.5.2 Sistema Gerenciador de Banco de Dados
Segundo Abraham Silberschatz, um sistema gerenciador de banco de
dados (SGBD) constitudo 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
manipulao de grandes quantidades de informao, e apresentam um modelo
que define o esquema dos dados armazenados no sistema. Os quatro modelos
mais conhecidos so:
Hierrquico.
Em Rede.
Relacional.
Orientado a Objetos.
Existem tambm outros modelos, variando com o autor:
O modelo relacional estendido uma adio de caractersticas
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 caractersticas e responsabilidades,
tais como:
Integridade semntica (garantia de dados sempre corretos
com relao ao domnio de aplicao)
Segurana (evitar violao de consistncia dos dados,
segurana de acesso por usurios e aplicaes, segurana
contra falhas).
Gerenciamento de Concorrncia (evitar conflitos de acesso
simultneo a dados por transaes).
2.5.2.2 Uma breve histria do PostgreSQL
O PostgreSQL um dos resultados de uma ampla evoluo que se
iniciou com o projeto Ingres, desenvolvido na Universidade de Berkeley,
Califrnia. O lder do projeto, Michael Stonebraker, um dos pioneiros dos
bancos de dados relacionais, deixou a universidade em 1982 para comercializar
o Ingres, porm retornou a ela logo em seguida. Aps seu retorno a Berkeley,
em 1985, Stonebraker comeou um projeto ps-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, combinaes de dados simples
que formam uma nica unidade.
O projeto resultante, chamado Postgres, era orientado a introduzir a
menor quantidade possvel de funcionalidades para completar o suporte a tipos.
Estas funcionalidades incluam a habilidade de definir tipos, mas tambm a
habilidade de descrever relaes - as quais at este momento eram
amplamente utilizadas, mas completamente mantidas pelo usurio. No
Postgres, o banco de dados "compreendia" as relaes e podia obter
26
informaes de tabelas relacionadas utilizando regras.
Iniciando em 1986, a equipe divulgou uma srie de documentos
descrevendo a base do sistema e em 1988 o projeto possua um prottipo
funcional. A verso 1 foi liberada para um grupo pequeno de usurios em junho
de 1989, seguida pela verso 2 com um sistema de regras reescrito em junho
de 1990. Para a verso 3, liberada em 1991, o sistema de regras foi reescrito
novamente, mas tambm foram adicionados suporte para mltiplos
gerenciadores de armazenamento e um melhorado motor de consultas. J em
1993, Postgres havia crescido imensamente em popularidade e possua uma
grande demanda por suporte e por novas funcionalidades. Aps a liberao da
verso 4, a qual era uma simples verso de limpeza, o projeto foi oficialmente
abandonado pela Universidade de Berkeley.
Entretanto, devido ao fato do seu cdigo fonte estar sob uma licena
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 divulgao de seu cdigo pela Internet,
Postgres95 iniciou uma nova vida como software open source.
Em agosto de 1996, Marc Fournier, Bruce Momjian e Vadim B. Mikheev
lanaram a primeira verso externa da Universidade de Berkeley e deram incio
tarefa de estabilizar o cdigo herdado. Tambm em 1996, o projeto foi
renomeado para PostgreSQL a fim de refletir a nova linguagem de consulta ao
banco de dados: SQL. A primeira verso de PostgreSQL, a 6.0, foi liberada em
janeiro de 1997. Desde ento, um grupo de desenvolvedores e de voluntrios
de todo o mundo, coordenados pela Internet, tm mantido o software e
desenvolvido novas funcionalidades.
As principais caractersticas acrescentadas nas verses 6.x so o
en:MVCC (Multiversion Concurrency Control Controle de Concorrncia
Multiverses), melhorias no SQL e novos tipos de dados nativos (novos tipos de
27
datas e hora e tipos geomtricos).
Em maio de 2000 foi liberada a verso 7.0. As verses 7.x trouxeram as
seguintes novas funcionalidades: Write-Ahead Log (WAL), esquemas SQL,
outer joins, suporte a IPv6, indexao por texto, suporte melhorado a SSL e
informaes estatsticas do banco de dados.
A verso 8.0 foi lanada 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 - atravs da biblioteca Cygwin). Dentre as muitas novidades da
verso
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 lanada a
verso mais recente: 8.4.
2.5.2.3 Caractersticas tcnicas do PostgreSQL
Licena BSD (Berkeley Software Distribution). Portanto pode
ser utilizado, modificado e distribudo por qualquer pessoa ou
empresa para qualquer finalidade, sem encargo, em quaisquer
dos sistemas operacionais suportados.
Grande nmero de recursos, tais como: Comandos
complexos, Chaves estrangeiras, Gatilhos, Vises, Integridade
de Transaes, Controle de Simultaneidade Multi-verso,
(MVCC), Suporta mltiplas transaes online concorrentes
entre usurios, Suporte a Rules (sistema de regras que
reescreve diretivas SQL), Suporte ao modelo hbrido objetorelacional,
Linguagem Procedural em vrias linguagens
(PL/pgSQL, PL/Python, PL/Java, PL/Perl), Indexao por
texto, Estrutura para guardar dados Georeferenciados
PostGIS, entre outros.
Opes de extenso atravs do usurio: Tipos de dados,
Funes, Operadores, Funes de Agregao (Agrupamento),
28
Mtodos de ndice por texto, Linguagens Procedurais (Stored
Procedures).
Capacidade de lidar com grandes volumes de dados.
2.6 Sistema Distribudo
Segundo Tanenbaum (1995), um sistema distribudo um conjunto de
computadores independentes que aparentam aos usurios um sistema nico.
Outra definio tambm apresentada por Coulouris (2005), que defende a
idia de um sistema distribudo ser componentes de hardware e software
conectados em rede que comunicam suas aes somente atravs de trocas de
mensagens.
Um sistema distribudo pode possuir diversos elementos de hardware e
software de forma distribuda, mas a distribuio de apenas um dos elementos
j o caracteriza como sistema distribudo.
Neste captulo sero descritas algumas caractersticas de sistemas
distribudos e aspectos importantes sobre segurana e telecomunicaes.
2.6.1 Conceito de Sistemas Distribudos, Segurana e Telecomunicaes.
Apesar de um sistema apresentar conceitos relacionados distribuio,
nem todos podem ser considerados como sistemas realmente distribudos. o
caso de terminais inteligentes, por exemplo.
Os terminais inteligentes possuem baixa capacidade de armazenamento
e processamento e executam tarefas limitadas e pouco flexveis transferindo
dados para um sistema principal. Por no possurem autonomia operacional
suficiente, estes no podem ser caracterizados como sistemas distribudos.
Os sistemas realmente distribudos devem apresentar a distribuio de
controle, processamento e dados. Dessa forma um sistema que utiliza das vias
29
de tele processamento, no necessariamente um sistema distribudo de fato.
A distribuio 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 autnoma. Este processamento pode ser constitudo
desde um mainframe at por uma estao de trabalho, e o componente de
mais fcil de ser identificado, sendo necessrio a existncia de mltiplos
processadores.
A distribuio de dados a possibilidade de localizar os arquivos ou
banco de dados prximos aos locais onde so 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
distribudo permite que os dados armazenados sejam compartilhados pelos
diversos nodos onde existe capacidade de processamento. Este
compartilhamento pode ser obtido pela transferncia de arquivos ou pelo
acesso remoto aos dados.
A distribuio do controle significa que os processos executados nos
diferentes nodos interagem de forma cooperativa para satisfazerem um
determinado objetivo. Esta cooperao definida por um protocolo que
especifica completamente os servios a serem executados.
O controle o de mais difcil domnio e, ao mesmo tempo, o de maior
importncia para o funcionamento de um sistema distribudo. Os diferentes
computadores do sistema distribudo podem ser heterogneos e possuir, cada
um, o seu prprio sistema operacional. Porm o conjunto deve operar como um
todo integrado e apresentando um comportamento homogneo. A integrao
destes sistemas locais heterogneos em um nico sistema homogneo no
uma tarefa trivial.
O controle distribudo de uma aplicao , por natureza, diferente e mais
30
complexo do que o controle de um sistema centralizado. Em um local nico
todos os dados necessrios ao controle esto imediatamente disponveis e o
sistema operacional local tem completa autonomia para gerenciar os recursos.
A sincronizao dos processos que operam simultaneamente em um sistema
centralizado realizada por meio do compartilhamento de reas de memria.
A caracterstica essencial do controle de um sistema distribudo a
coordenao entre os diferentes processos por meio de mensagens. Esta
caracterstica implica na impossibilidade da manuteno de informao
completa e atualizada sobre cada processo de um sistema distribudo. Os
algoritmos utilizados para a sincronizao das atividades distribudas possuem,
por este motivo, uma complexidade maior que a apresentada por algoritmos
centralizados (LAMPORT, 1978).
O processamento distribudo, assim como foi caracterizado, mais do
que uma tecnologia , tambm, uma metodologia para a concepo e
implantao de sistemas de informao. Sua principal caracterstica
possibilitar o particionamento das atividades (e dos dados associados) de
acordo com a localizao geogrfica das aplicaes mantendo, ao mesmo
tempo, a integrao dos diversos componentes.
As caractersticas mais importantes dos sistemas distribudos podem ser
resumidas em: Diminuir o trfego de mensagens, processar localmente; Manter
a integrao do sistema e atender s necessidades locais.
Dessa forma, possvel otimizar o desempenho e o custo global e
aumentar a confiabilidade das aplicaes. Um sistema distribudo possui,
entretanto, uma maior complexidade que um sistema centralizado e apresenta
caractersticas funcionais que podem influir nos procedimentos operacionais e
de deciso das empresas.
Podem ser citadas trs alternativas bsicas para a escolha de critrios
de distribuio: a distribuio por reas geogrficas por grupos funcionais e por
31
funes de processamento de dados.
A distribuio geogrfica dos dados um dos critrios fundamentais para
o projeto de sistemas distribudos. Deve haver uma grande parcela de atividade
local (dados locais) e pequena atividade entre regies. Em grande parte dos
sistemas reais os dados apresentam a propriedade dos acessos serem
geograficamente agrupados. A idia bsica para o particionamento dos dados
consiste em agrup-los de acordo com as taxas de acesso para a identificao
dos possveis computadores regionais. Desta forma minimizado o trfego
internodos.
A caracterstica determinante desta forma de distribuio a relao
entre atividade local e a remota. Caso a taxa de atividade remota seja alta a
distribuio no a soluo mais adequada. Este critrio leva minimizao do
fluxo de dados internodos e empregado em mtodos de alocao tima de
arquivos em sistemas distribudos. Com exceo de sistemas muito
especializados (defesa, alta segurana de operao) a maioria dos sistemas
distribudos reflete a agregao geogrfica natural das organizaes.
O desenvolvimento de computadores levou aos sistemas
departamentais. O conceito administrativo utilizado, neste caso, consiste em
alocar capacidade de processamento em cada departamento, isto :
distribuio por grupo de funes. Esta uma alternativa utilizao
compartilhada de um grande sistema central. Apenas os dados corporativos (e
os muito volumosos) so mantidos no sistema central. A integrao do sistema
de informaes automatizado assegurada pela interligao dos diversos
computadores departamentais e do computador central.
Outra forma de distribuio consiste na distribuio por funes. Neste
caso esto classificados os servidores especializados, tais como: servidores de
impresso, servidores de arquivos, processadores vetoriais ou processadores
de uso geral especializados por software. Este tipo de distribuio atribui cada
tarefa um nodo adequado a funo especfica. Tais categorias de distribuio
32
no so 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 pginas estticas, ou seja,
no variava a cada solicitao conforme alguma mudana de parmetros. Com
o tempo, houve a necessidade de tornar o contedo das pginas dinmico, que
possibilitasse construir uma pgina conforme uma nova requisio, o que no
era possvel utilizando somente HTML (Hyper Text Markup Language). Para
tanto o servidor web deveria processar os dados destas solicitaes e retornar
uma resposta personalizada. Surgiu ento o CGI (Common Gateway Interface)
(BRAZ, on-line).
O CGI possui limitaes quanto a sua utilizao em sistemas web de
grande escala, pois a cada execuo do programa um novo processo criado,
causando sobrecarga no servidor web. Ocorre tambm que os programas em
CGI so capazes de tratar apenas uma solicitao, na qual um novo processo
criado, os dados so enviados, processados e a resposta retornada para o
navegador e o processo finalizado. Com isso, no possvel 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
programao como o Perl, ASP, PHP, Java e etc.
Em Java, no ambiente JEE (Java Enterprise Edition), que voltado para
as aplicaes 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
aplicaes Java geralmente se faz o uso de design patterns tambm conhecido
como padres de projeto e algum framework, tais como o STRUS, JSF,
Hibernate, entre outros.
33
2.7.1 Arquitetura Java EE e Design Patterns.
Um padro de projeto definido como uma soluo desenvolvida
utilizando boas prticas para um problema comum que ocorre vrias vezes. Um
padro de projeto documenta e explana um problema importante que pode
ocorrer no projeto ou implementao de uma aplicao e ento discute a
melhor soluo prtica para o problema (Marinescu, 2002).
Segundo a SUN, a plataforma J2EE (Java 2 Enterprise Edition) define um
padro para o desenvolvimento de aplicaes multicamadas. Nesta arquitetura,
a camada que contm as regras de negcio, normalmente implementada
utilizando Enterprise JavaBeans, pode ficar concentrada no servidor de
aplicaes, sendo compartilhada com diversas aplicaes clientes. As
aplicaes clientes no contm a lgica do negcio, atendo-se somente
camada de apresentao. Na camada de apresentao normalmente so
utilizadas as tecnologias de Servlets e JavaServer Pages.
Os Design Patterns buscam facilitar a reutilizao de projetos e
arquiteturas bem sucedidos. Eles auxiliam a escolher alternativas de projeto
que tornam um sistema reutilizvel e evitar alternativas que comprometam a
reutilizao.
Segundo Alur (2002) se destacam algumas vantagens de se usar cada um
destes padres, considerando que:
Foram testados: refletem a experincia e conhecimento dos
desenvolvedores que utilizaram estes padres com sucesso em
seu trabalho;
So reutilizveis: fornecem uma soluo pronta que pode ser
adaptada para diferentes problemas quando necessrio;
So expressivos: formam um vocabulrio comum para expressar
grandes solues 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 so usados, menor ser o
retrabalho em etapas mais avanadas do projeto.
A SUN disponibiliza um catlogo de 15 padres J2EE, que fornece
solues para problemas tipicamente encontrados por arquitetos e designers de
aplicaes de software para a plataforma J2EE, conforme ilustra a Figura 3.
Figura 3: Core J2EE Patterns. Fonte: SUN.
35
Em poucas palavras possvel descrever cada um destes padres em
suas respectivas camadas (Alur, 2002):
Camada de apresentao: intercepting filter (Intercepta
solicitaes e respostas e aplica algum filtro); front controller
(Fornece um controlador centralizado para manter a lgica de
processamento que ocorre na camada de apresentao e que,
erroneamente colocado nas vises); view helper (Encapsula a
lgica que no esteja relacionada formatao da apresentao
em componentes auxiliares);composite view (Cria uma viso
atravs da composio de outras vises); service to worker
(Combina um componente distribuidor com os padres Front
Controller e View Helper. Neste padro a responsabilidade de
recuperar o contedo para apresentar do controlador); dispatcher
view (Semelhante ao padro Service to Worker, mas, neste padro
a recuperao do contedo responsabilidade das vises).
Camada de negcios: business delegate (Reduz o acoplamento
entre o cliente e a camada de negcios); data transfer object
(Facilita o intercmbio de dados entre as camadas); data transfer
object factory (Facilita e centraliza a criao de data transfer
objects); session facade (Fornece uma interface unificada para um
sistema distribudo); composite entity (Representa uma prtica
mais recomendada para criar entity beans de granulao 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
informaes); service locator (Encapsula a complexidade de
localizao e criao de servios de negcio e localiza os objetos
Home dos EJB).
Camada de integrao: data access object (Abstrai e encapsula o
acesso aos dados); service activator ( Facilita o processamento
assncrono para Message-driven beans).
36
2.7.2 Componentizao na camada de visualizao com JSF
Segundo Gonalvez (2007, p. 429) O JSF (Java Server Faces) uma
tecnologia do mundo JEE e desenhado para simplificar o desenvolvimento de
aplicaes Web. JSF torna fcil o desenvolvimento atravs de componentes de
interface de usurio (GUI) e conecta esses componentes a objetos de negcios.
Tambm automatiza o processo de uso de Java Beans e navegao de
pginas.
Java Server Faces disponibiliza o rpido desenvolvimento de interfaces
para aplicaes que rodam no servidor web. Permite aos desenvolvedores
escrever aplicaes com facilidade, sem se preocupar com as complexidades
de lidar com navegadores e servidores Web. Tambm automatiza alguns
procedimentos como o controle e o transporte do cdigo entre formulrios, a
lgica de negcios, 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 so essenciais para o desenvolvimento de aplicaes em
JSF.
Estes componentes funcionam em conjunto, ou seja, caso necessite de um
determinado componente que no 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 tambm alguns fabricantes que desenvolveram suas prprias
implementaes 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. Tambm por ser flexvel na questo de criao de
componentes prprios a partir de classes de componentes, e permitir que o
desenvolvedor crie interfaces atravs de componentes fornecidos e manipule
37
eventos do lado cliente com grande facilidade.
Vale destacar que no ano de 2009 foi lanada a verso 2 do framework
JSF, que teve sua primeira verso lanada em 2003. Esta segunda verso veio
para corrigir e facilitar o uso de diversos novos recursos tais como:
Suporte nativo a Ajax, no disponvel na primeira verso.
Resolver problemas de incompatibilidade entre bibliotecas de
componentes.
Permitir configuraes atravs de anotaes, o que antes era feito
somente via xml.
Diminuir a complexidade da criao de componentes visuais.
Comunicao entre os componentes atravs de outros protocolos,
pois na primeira verso era possvel somente via GET, sendo esta
uma de suas falhas mais criticadas.
2.7.3 Componentizao na camada de negcios com EJB
Segundo Gonalvez (2007, p. 544) O EJB ou Enterprise JavaBeans um
componente servidor que roda em um container para EJB do servidor de
aplicao. Considerado como um dos principais componentes da plataforma
JEE (Java Enterprise Edition), o EJB tem como principais objetivos da
tecnologia fornecer rpido e simplificado desenvolvimento de aplicaes Java
baseadas em componentes, distribudas, transacionais, seguras e portveis.
Infelizmente essa no foi bem a realidade das verses anteriores as 3.0 da
tecnologia EJB, especialmente os Entity Beans, que sempre foram acusados de
baixa eficincia, alta complexidade e dificuldade de uso.
DEBU PANDA (2008, p.4) define Enterprise JavaBeans (EJB) como uma
plataforma para construo de aplicaes corporativas porttil, reutilizvel e
38
escalvel, que utiliza a linguagem Java. Desde seu incio, o EJB tem sido
considerado um modelo de componente ou framework que permite que voc
construa aplicaes corporativas Java sem ter que reinventar servios
necessrios para a construo de uma aplicao, como as transaes,
seguranas, persistncia automatizada e assim por diante.
DEBU PANDA (2008, p.5) descreve EJBs como componentes server-side
que so utilizados para construir partes de uma aplicao, como a regra de
negcios ou a camada de persistncia. 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 eficincia o comportamento de uma aplicao, dessa forma o
usurio de um componente no precisa conhecer suas operaes 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
atravs dos seguintes pontos:
Fcil de usar: Focado na facilidade de uso, os recursos que mais
so realados so a programao POJO, as anotaes XML, o uso
intenso dos padres sensveis e o JPA.
Acmulo de solues integradas: O EJB oferece um conjunto de
solues para servidor, incluindo persistncia, messaging,
programas leves, remoting, servios de web, injeo de
dependncia (DI) e interceptores. Isso significa que voc no ter
que perder tempo procurando ferramentas terceirizadas para
integrar sua aplicao.
Padro aberto Java EE: O EJB possui uma especificao API
pblica aberta, que as empresas utilizam para criar um container ou
a implementao do fornecedor de persistncia. O padro EJB
desenvolvido pelo Java Community Process (JCP) proporcionando
um suporte maior, sem precisar de uma soluo proprietria.
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 trs vantagens importantes para voc. Primeira, voc no
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 possvel.
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
no padronizados adicionados ao valor. Esses fatores ajudam a
manter o EJB continuamente na linha de evoluo.
Agrupamento, balanceamento de carga e failover: Os recursos
historicamente adicionados por muitos fornecedores de servidores
de aplicaes so suportes robustos para o agrupamento, balano
de carga e failover. Os servidores de aplicao EJB possuem um
registro de trilha provado para suportar alguns dos ambientes de
servidores ativados por computao (HPC) de alto desempenho.
Mais importante que isso, voc pode alavancar tal suporte sem
alterar o cdigo, sem interao de ferramenta terceirizada e com
configurao relativamente simples (alm do trabalho inerente em
configurar um agrupamento de hardware). Isto significa que voc
pode confiar no agrupamento de hardware para medir sua aplicao
com o EJB 3, caso precise.
Os beans so os componentes EJB e so classificados conforme sua
utilidade, sendo eles: Session Beans, Message Driven Beans, Entity Beans.
Cada tipo de bean tem um propsito e pode utilizar um subconjunto especfico
de servios EJB. O propsito real dos tipos de beans proteger as possveis
sobrecargas contra os servios que surgem.
Os sesseion beans e os Message Driven Beand so usados para construir
lgica de negcios e residem em um container, que gerencia esses beans e
40
fornece servio a eles. J os Entity Beans so usadas para modelar a
persistncia de uma aplicao.
Segundo DEBU PANDA (2008, p.14), um dos recursos mais atraentes do
EJB 3 o modo com que ele controla a persistncia. Persistncia a habilidade
de ter os dados contidos nos objetos Java automaticamente armazenados em
um banco de dados relacional como o Postgres SQL. A persistncia em EJB 3
gerenciada pelo JPA. Ela persiste automaticamente aos objetos Java usando
uma tcnica 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 configurao. Ele desobriga o
desenvolvedor da tarefa de escrever o cdigo JDBC de baixo nvel para manter
os objetos em um banco de dados.
Os frameworks que fornecem capacidade ORM para realizar persistncia
automatizada so conhecidos como frameworks ORM. Como o nome j diz, um
framework ORM executa persistncia transparente usando metadados do
mapeamento objeto-relacional que define como os objetos so mapeados nas
tabelas de banco de dados. ORM no 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
REFERNCIAS BIBLIOGRFICAS
ALECRIM, Emerson. JSE, JEE e JME: uma breve explicao. Info Wester. So
Paulo - SP. 02 out. 2007. Disponvel em:
<http://www.infowester.com/versoesjava.php>. Acesso em 02 abr. 2009.
ALUR, Deepak; CRUPI, John; MALKS, Dan. Core j2ee patterns: as melhores
prticas e estratgias de design. Rio de Janeiro: Campus, 2002.
BRAZ, Christian Cleber Masdeval. Introduo ao Java Server Pages. Disponvel
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.
GONALVES, Edson. Desenvolvendo aplicaes web com jsp, servlets,
javaserver
faces, hibernate, ejb3 persistence e AJAX. Editora Cincia 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.
Disponvel 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: So Paulo SP, 2000.
MANGIONE, Carmine. Performance tests show Java as fast as C++. Java
World. 02 jan. 1998. Disponvel 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 aplicaes com UML 2.0: do conceitual
implementao 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 Distribudos.
UFRGS. Disponvel em: <http://palazzo.pro.br/sd/distr-dados.htm>. Acesso em
16 set 2010.
DEBU PANDA, REZA RAHMAN, DEREK LANE. EJB3 em ao. 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. Disponvel em: <http://www.rponte.com.br/wpcontent/
uploads/2007/10/anatomia-jsf-javaserver-faces-cct.pdf>. Acesso em 20
mar.2010.
RUBIRA, Ceclia Mary Fischer. Desenvolvimento Baseado em Componentes e
o Processo UML Components. Unicamp. 2008. Disponvel 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. Disponvel 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. Disponvel 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. Disponvel em:
<http://pt.wikipedia.org/wiki/Sistema_de_gerenciamento_de_banco_de_dados
>.
Acesso em: 10 dez. 2009.
WIKIPEDIA. PostgreSQL. Disponvel em:
<http://pt.wikipedia.org/wiki/PostgreSQL>. Acesso em: 10 dez. 2009.
WIKIPEDIA. Engenharia de software. Disponvel em:
<http://pt.wikipedia.org/wiki/Engenharia_de_software >. Acesso em: 10 dez.
43
2009.
WIKIPEDIA. Engenharia de software baseada em componentes. Disponvel
em:<http://pt.wikipedia.org/wiki/Engenharia_de_software_baseada_em_comp
on
entes>. Acesso em: 10 dez. 2009.
WIKIPEDIA. Processo Unificado. Disponvel em:
<http://pt.wikipedia.org/wiki/Processo_Unificado>. Acesso em 10 dez. 2009.
WIKIPEDIA. IBM Rational Unified Process Disponvel em:
<http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process>. Acesso em: 10
dez. 2009


Jean Wagner Kleemann
Atuo no desenvolvimento Web desde 2008 com nas plataformas java ,
.net e php. Participao no desenvolvimento de sistemas web nas reas
de EAD, ISSQN, Factoring, e-commerces, sites internacionais, entre
outros. Bacharel em Cinci [...]

Leia mais em: BREVE ESTUDO SOBRE ENGENHARIA DE COMPONENTES http://www.devmedia.com.br/breve-
estudo-sobre-engenharia-de-componentes/19139#ixzz2hMg2iGeU