SUMRIO

Contedo
1

INTRODUO 3

objetivos4

desenvolvimento

3.1 ENGENHARIA E PROJETO DE SOFTWARE

3.1.1
rea de Conhecimento Riscos.............................................................5
3.1.2
rea de Conhecimento Escopo............................................................6
3.1.3
rea de Conhecimento Aquisies......................................................7
3.1.4
rea de Conhecimento Comunicaes................................................7
3.1.5
Resenha do livro Engenharia de Software..............................................8
3.2
frameworks para desenvolvimento web.......................................................32
3.2.1
Comparao de frameworks para desenvolvimento web (Java)..........32
3.2.2
Custo Benefcio de frameworks no desenvolvimento Web...................33
3.2.3
Programao Java Web (plataforma de desenvolvimento)..................34
3.3
Projeto Orientado a Objetos.........................................................................35
4 concluso
41
5

referncias

42

1 INTRODUO
A empresa China Telecom - A maior empresa de telefonia fixa do
mundo emprega 350 mil funcionrios divididos em reas como operaes de rede,
servios de informao ao cliente, voz e dados por telefone fixo, atendimento ao
usurio e servios de faturamento/cobrana de clientes. Apesar da forte
concorrncia da telefonia mvel, a empresa vem mantendo um crescimento
vertiginoso.
No entanto, ainda em transio de uma empresa estatal para uma
nova e moderna empresa e com objetivo de se firmar como uma concorrente de
peso no mercado mundial, a China Telecom teve que resolver vrios problemas
demanda recursos de vrias pessoas e especialistas, alm de inmeros recursos,
entre hardware, software, fornecedores, viagens, entre outros. Neste contexto
veremos que a sobre como ajudar a empresa a resolver estes problemas.

2 OBJETIVOS

Aplicar todos os conhecimentos necessrios com o objetivo de

possibilitar a empresa China Telecom numa integrao mais profunda com outros
sistemas, de maneira que a empresa tenha uma viso completa de todos os seus
processos com clientes, fornecedores e funcionrios.

3 DESENVOLVIMENTO
Como a empresa China Telecom demanda recursos de vrias
pessoas e especialistas, alm de inmeros recursos, entre hardware, software,
fornecedores, viagens, entre outros, farei uma resenha sobre o Guia PMBOK, dentro
da Engenharia e Projeto de Software.
3.1 ENGENHARIA E PROJETO DE SOFTWARE
O PMBOK Guide no uma metodologia, pois no distingue os
diferentes tipos de projeto (certamente gerenciar projetos administrativos
totalmente

diferente

de

gerenciar

projetos

de

construo

pesada).

No utiliza peculiaridades de linguagem que respeitem a cultura de diferentes tipos

de empresas e no apresenta modelos especficos de documentos a serem
preenchidos.
Resumidamente podemos chamar de manual que descreve o
universo de conhecimentos para o Gerenciamento de Projetos. Transformou-se em
um padro fonte de inspirao para quase todas as metodologias existentes.
O PMBOK torna um projeto melhor estruturado e atendendo as suas
demandas de forma mais eficiente, tendo tambm em vista um melhor planejamento
para assim bater as suas metas como o custo, benefcio, e prazo estabelecido.
Ele um conjunto de boas prticas para ajudar na construo de um projeto,
promove um melhor vocabulrio para se discutir entre profissionais na rea.
O guia PMBOK possui em sua 5edio 10 reas de conhecimento dentre elas...

3.1.1 rea de Conhecimento Riscos

Esta rea descreve os processos relativos realizao do

gerenciamento de riscos em um projeto. Temos cinco processos de planejamento e
um de controle. Os processos desta rea de conhecimento tm como objetivo
determinar como os riscos sero identificados, analisados e como as respostas ser

planejado e como risco ser planejado, criam uma lista de riscos identificados no
projeto com diversas tcnicas que ajudam a gerar essa lista de riscos, buscam
priorizar os riscos com base no grau de criticidade, permitem atribuir probabilidade
numrica aos riscos, definem estratgias e aes para lidar com os riscos negativos
e positivos, monitoram os riscos com novo risco sendo identificada, reviso das
anlises de riscos, definio de outras prioridades de riscos, etc.
Os processos dessa rea so:

Planejar o Gerenciamento dos Riscos.

Identificar os Riscos.

Realizar a Anlise Qualitativa de Riscos.

Realizar a Anlise Quantitativa dos Riscos.

Planejar as Respostas aos Riscos.

Monitorar e Controlar os Riscos.

3.1.2 rea de Conhecimento Escopo

Esta rea descreve os processos envolvidos na verificao de que o
projeto inclui todo o trabalho necessrio e apenas o trabalho necessrio, para que
seja concludo com sucesso.
Existem trs processos de planejamento (trs primeiros) e dois
processos de controle e monitoramento (dois ltimos). Os processos de
planejamento criam um plano para o gerenciamento de escopo. Os processos de
controle e monitoramento controlam se que o escopo est sendo cumprido conforme
foi definido nos processos de planejamento e a verificao confirmam com o cliente
que est tudo correto.
Os processos dessa rea so:

Coletar Requisitos.

Definir o Escopo.

Cria a EAP.

Verificar o Escopo.

Controlar o Escopo.

3.1.3 rea de Conhecimento Aquisies

Esta rea descreve os processos que compram ou adquirem
produtos, servios ou resultados, alm dos processos de gerenciamento de
contratos. Os processos desta rea de conhecimento tm como objetivo determinar
o que se quer adquirir, de quem se quer adquirir, receber as resposta dos
fornecedores e selecionar o fornecedor, como se dar o gerenciamento dos
contratos, pagamentos, se as entregas esto de acordo com o que foi estabelecido,
pagar o fornecedor, e por ltimo formalizar a finalizao do contrato.
Os processos dessa rea so:

Planejar as Aquisies.

Realizar as Aquisies.

Administrar as Aquisies.

Encerrar as Aquisies.

3.1.4 rea de Conhecimento Comunicaes

Esta rea descreve os processos relativos gerao, coleta,
disseminao, armazenamento e destinao final das informaes do projeto de
forma oportuna e adequada.
Os processos desta rea de conhecimento determinam quem est
envolvido no projeto, definem como as comunicaes vo ocorrer quando o projeto
iniciar e determina o tipo de informaes gerada, quem o responsvel, qual o
meio, quem receber as informaes geradas, qual a periodicidade determina como
sero distribudas as informaes, como podemos gerenciar as expectativas dos
interessados medindo o grau de satisfao ou insatisfao das pessoas
interessadas, e geram relatrios que permitam o acompanhamento e controle do
que est acontecendo com o tempo, custo, escopo, etc.
Os processos dessa rea so:

Identificar as Partes Interessadas.

Planejar as Comunicaes.

Distribuio das Informaes.

Gerenciar as Expectativas das Partes Interessadas.

Reportar Desempenho

3.1.5 Resenha do livro Engenharia de Software

A empresa China Telecom decidiu investir em um software de ERP
fornecido por uma empresa de renome do que investir no desenvolvimento interno
de um que levaria muito tempo e sairia muito caro. Neste caso, levaria muito tempo
e sairia muito caro. Vamos supor que a empresa optasse pelo desenvolvimento
prprio, para isso farei uma resenha dos seguintes captulos do livro Engenharia de
Software, de Ian Sommerville:
3.5.1

CAPITULO 11 Projeto de Arquitetura

O projeto de arquitetura primeiro estagio no processo de projetos.

Diz o livro que ele idntica subsistemas e estabelece um framework para controlar a
comunicao dos subsistemas, subsistemas so sistemas grandes decompostos em
subsistemas e que fornece algum conjunto de servios relacionados. Ele tambm
representa uma ligao critica entre processos de engenharia de projeto e
requisitos. Trs vantagens de projetar e documentar explicitamente uma arquitetura
de software:

Comunicao de stakeholders: uma apresentao em alto

nvel do sistema que enfoca a discusso entre diferentes
stakeholders.

Analise de sistemas: Tem profundo efeito sobre o sistema,

mostra se o sistema pode atender aos requisitos crticos
como,

confiabilidade,

desempenho

facilidade

de

manuteno.

Reuso em larga escala: Apia o reuso em larga escala de

sistemas que possuem arquiteturas de sistemas familiares.

A arquitetura de software serve para negociar requisitos de sistema
e estruturar discusses com os clientes, desenvolvedores e gerentes. uma
ferramenta essencial parra gerenciamento de complexidade, ocultando detalhes e
focando as abstraes principais do sistema. O estilo e estrutura da aplicao
dependem dos requisitos no funcionais do sistema, por exemplo:
Se o desempenho for um requisito crtico a aplicao deve localizar
operaes criticas dentro de subsistemas e usar componentes de alta granularidade
em detrimento dos de baixa granularidade para reduzir a comunicao entre eles.
Se a facilidade de manuteno for um requisito crtico, a arquitetura de sistemas
deve ser projetada usando componentes de baixa granularidade e autocontidos que
possam ser prontamente mudados.
H conflitos potenciais entre algumas dessas arquiteturas, por
exemplo, se o desempenho que necessita de alta granularidade e a facilidade de
manuteno que necessita de baixa granularidade forem ambos o requisito crtico
ter que ser encontrada alguma soluo eficaz.
Um projeto de subsistemas decomposio abstrata de um sistema
de componentes em alta granularidade. Os diagramas de blocos so usados para
representar um projeto de subsistemas.
Esses diagramas de blocos so bons para comunicao entre
stakeholders e para o planejamento do projeto, pois, no esto abarrotados de
detalhes, j para a arquitetura no so to bons, pois no mostram relacionamento
entre os componentes do sistema.
O projeto de arquitetura tenta estabelecer uma organizao de
sistemas que satisfao os requisitos funcionais e os no funcionais do sistema.
Durante o processo de projeto de arquitetura os arquitetos de sistemas devem
responder a algumas perguntas:

Existe uma arquitetura genrica de aplicao que possa

funcionar como um modelo para o sistema que est sendo
projetado?

Como o sistema ser distribudo ao longo de vrios

10

processadores?

Qual ou quais estilos de arquitetura so apropriados para o

sistema?

Qual ser a abordagem fundamental usada para estruturar o

sistema?

Como as unidades estruturais de um sistema sero

decompostas em mdulos?

Qual estratgia ser utilizada para controlar a operao das

unidades do sistema?

Como o projeto de arquitetura ser avaliado?

Como a arquitetura do sistema deve ser documentada?

Ao Projetar uma arquitetura de sistemas, voc precisa decidir o que

seu sistema e classes mais amplas de aplicao tm em comum, e decidir quanto
conhecimento dessas arquiteturas de aplicao voc pode reusar. A arquitetura de
um sistema de software pode ser baseada em um modelo ou estilo de arquitetura
especifico. Em alguns casos a arquitetura geral de um sistema pode ser uma
arquitetura composta.
Os modelos de arquitetura que podem ser desenvolvidos podem
incluir:

Um modelo esttico de estrutura que mostra os subsistemas

ou componentes desenvolvidos como unidades separadas.

Um modelo dinmico de processo que mostra como o sistema

esta organizado em processos em tempo de execuo.

A organizao de um sistema reflete a estratgia bsica usada para

estrutur-lo. Voc precisa tomar decises sobre o modelo geral organizacional de
um sistema com antecedncia no processo de projeto de arquitetura. A organizao
pode refletir diretamente na estrutura subsistema. Possuem trs estilos de
organizacionais amplamente usados:

11

3.1.5.1.1 Modelo de repositrio

Os subsistemas que constituem um sistema devem trocar
informaes

de

mofo

que

possam

trabalhar

juntos

eficientemente.

Esse modelo , portanto, adequado para aplicaes em que os dados so gerados

por um subsistema e usados por outro. O repositrio passivo e o controle de
responsabilidade dos subsistemas que o usam.

3.1.5.1.2 Modelo Cliente Servidor

O modelo de arquitetura cliente servidor um modelo em que o

sistema organizado como um conjunto de servios e servidores e clientes
associados que acessam e usam os servios. Os clientes talvez precisem saber os
nomes dos servidores disponveis e os servios que eles fornecem. No entanto os
servidores no precisam saber a identidade do cliente ou quantos so. So
acessados os servios por meio de chamadas remotas de procedimento usando um
protocolo requesteply, o cliente faz um pedido a um servidor e espera ate receber
uma resposta. A vantagem de um modelo cliente servidor que ele uma
arquitetura distribuda. O uso efetivo de sistemas em rede pode ser feito com muitos
processadores distribudos. fcil adicionar um novo servidor e integr-lo ao
restante do sistema.

3.1.5.1.3 Modelo em Camadas

O modelo em camadas organiza um sistema em camadas, cada
uma das quais fornecendo um conjunto de servios. A abordagem em camadas
apia o desenvolvimento incremental de sistemas. medida que uma camada
desenvolvida

alguns

servios

fornecidos

por

essa

camada

podem

ser

disponibilizados para os usurios. Essa arquitetura tambm modificvel e portvel.

Desde que sua interface permanea inalterada, uma camada poder ser substituda

12

por outra equivalente. Uma desvantagem da abordagem em camadas que a

estruturao de sistemas dessa maneira pode ser difcil. As camadas mais internas
podem fornecer recursos bsicos, como gerenciamento de arquivos, necessrios em
todos os nveis. O desempenho tambm pode ser um problema devido aos vrios
nveis de interpretao de comandos algumas vezes exigidos.
3.1.5.1.4 Estilos de decomposio modular
Depois que a organizao geral do sistema foi escolhida, precisa-se
tomar uma deciso sobre a abordagem a ser usada na decomposio de
subsistemas em mdulos. Um modulo normalmente um componente de sistema
que fornece um ou mais servios para outros mdulos. Ele faz uso de servios
fornecidos por outros mdulos. Existem duas estratgias principais que voc pode
usar ao decompor um subsistema em mdulos. Decomposio orientada a objetos e
pipelining orientado a funes. Voc deve evitar tomar decises prematuras sobre a
simultaneidade de um sistema.
3.1.5.1.5 DECOMPOSIO ORIENTADA A OBJETOS.
Um modelo de arquitetura orientado a objetos estrutura o sistema
em um conjunto de objetos no firmemente acoplados com interfaces bem definidas.
Os objetos chamam servios oferecidos por outros objetos. Uma decomposio
orientada a objetos esta relacionada a classes de objetos, seus atributos e suas
operaes. Quando implementados os objetos so criados a partir dessas classes e
algum modelo de controle usado para coordenar as operaes de objetos. A
vantagem que implementao de objetos pode ser modificada sem afetar outros
objetos. A desvantagem que para usar servios os objetos devem fazer referencia
explicita ao nome e a interface de outros objetos.
3.1.5.1.6 Pipelining orientado a funes
No pipelining orientado a funes ou modelo de fluxo de dados, as
transformaes processam suas entradas e produzem sadas. Os dados fluem de

13

uma para outra funo e so transformados ao moverem se seqencialmente.

Cada etapa implementada como uma transformao. Os dados de entrada fluem
atravs dessas transaes ate serem convertidos em dados se sada. As vantagens
dessa arquitetura so: Apoiar o reusa de transformaes. Ele intuitiva, muitas
pessoas pensam em seu trabalho em termos de processamento de entrada e sada.
A evoluo do sistema pela adio de novas transformaes geralmente direta.
Ela simples de ser implementada tanto quanto um sistema concorrente ou
seqencial. O principal problema que ele necessita ser um formato comum para
transferir dados que possa ser reconhecido por todas as transformaes.
Sistemas interativos so difceis de escrever usando esse modelo por causa da
necessidade de uma seqncia de dados ser processada.
3.1.5.1.7 Modelos de controle
O modelo de controle tem como objetivo controlar subsistemas de
maneira que seus servios sejam entregues no lugar certo e no tempo certo.
Modelos de controle so usados em conjunto com estilos de estrutura. Todos os
estilos de estrutura que foi explicado podem ser implementados por meio de controle
centralizado ou baseado em eventos.
3.1.5.1.8 Controle Centralizado
Em modelo de controle centralizado, um subsistema designado
como controlado de sistema e tem a responsabilidade pelo gerenciamento da
execuo de outros subsistemas. Modelos de controle centralizados Dividem se
em duas classes, dependendo se forem executados seqencialmente ou
paralelamente.
O modelo chamado retorno: O controle comea no topo da
hierarquia de sub rotina e atravs de chamadas de sub-rotinas, passa para os
nveis mais baixos na arvore, so aplicados em modelos seqenciais.
O modelo gerenciado: Aplicados em modelos concorrentes. Um
sistema concorrente projetado como um gerenciador de sistema e controla o inicio,
a parada e a coordenao de outros processos do sistema.

14

3.1.5.1.9 Sistemas orientados a eventos

As decises dos modelos orientados a eventos so regidos pelos
eventos gerados externamente. O termo evento pode ser um sinal que pode assumir
uma gama de valores ou uma entrada de comando baseados em um menu.
Possuem dois modelos de controle orientados a eventos.
Modelos de broadcast: Nesse modelo, um evento transmitido a
todos os subsistemas. Qualquer subsistema programado para manipular o evento
pode responder a ele. A vantagem dessa abordagem que a evoluo
relativamente simples, um novo subsistema para tratar classes especifica de
eventos pode ser integrado por meio do registro de seus eventos no tratador de
eventos. A desvantagem que os subsistemas no sabem se ou quando os eventos
sero manipulados.
Modelos orientados a interrupes: So usados em sistemas de
tempo real como requisitos rigorosos de tempo, nos quais as interrupes externas
so detectadas por um trator de interrupes. A vantagem dessa abordagem que
ela permite respostas muito rpidas aos eventos a serem implementados. Sua
desvantagem a complexidade da programao e a dificuldade de validao.

3.1.5.1.10 Arquitetura de referencia

As arquiteturas de referencia no so geralmente consideradas um
roteiro de implementaes. Em vez disso, sua principal funo ser um meio de
discusso de arquiteturas de domnio especifico e de comparao de sistemas
diferentes em um domnio. Um modelo de referencia fornece um vocabulrio para
comparao. Ele atua como uma base, em relao a qual os sistemas podem ser
avaliados.
Uma proposta de modelo de referencia um modelo para ambientes
CASE que identifica cinco conjuntos de servios que um ambiente CASE deve
fornecer. Ele deve tambm fornecer recursos de plug in para ferramentas CASE
individuais que usam esses servios. Os cincos nveis de referencias so:
Servios de repositrio de dados: Estes servios fornecem recursos

15

para o armazenamento e o gerenciamento de itens de dados e seus

relacionamentos.
Servios de integrao de dados: Estes servios fornecem recursos
para o gerenciamento de grupos ou para definio de relacionamentos entre eles.
Servios de gerenciamento de tarefas, estes servios fornecem recursos para a
definio e aprovao de modelos de processo.
Servios de mensagem: Comunica ferramenta Ferramenta,
ambiente-ferramenta e ambiente ambiente.
Servios de interface com o usurio: Estes servios fornecem
recursos para o desenvolvimento de interface com o usurio.
A finalidade dessa arquitetura de referencia ser um meio de
classificao e comparao de ferramentas e ambientes CASE integrados.

3.5.2

CAPITULO 12 Arquitetura de sistemas distribudos

Um sistema distribudo aquele em que as informaes em fase de

processamento so distribudas a vrios computadores. Vantagens de usar uma

abordagem distribuda para desenvolvimento de sistemas.
1.

Compartilhamento de recursos Um sistema

distribudo

permite

compartilhamento

de

recursos de hardware e software, como discos,

impressoras, arquivos e computadores que esto
associados aos diferentes computadores de uma
rede.
2.

Abertura - permitem a equipamentos e software

de diferentes fabricantes serem combinados, pois
so projetados com base em protocolos padres.

3.

Concorrncia vrios processos podem operar ao

mesmo tempo em diferentes computadores, e
podem (mais no precisam) conversar uns com os
outros.

4.

Escalabilidade so escalonveis a maneira que

16

a capacidade de um sistema pode ser ampliada

pela adio de novos recursos para atender as
demandas dos sistemas.
5.

Tolerncia a defeitos pela disponibilidade de

vrios computadores e o potencial de duplicao
de

informao

significa

que

os

sistemas

distribudos possam ser tolerantes a algumas

falhas de hardware e software.
Esses sistemas de distribuio comparados aos sistemas que
operam com um processador ou com um cluster de processadores podem ter
algumas desvantagens como:
1.

Complexidade - os sistemas distribudos so mais

complexos que os sistemas centralizados.

2.

Proteo o sistema pode ser acessado de vrios

computadores diferentes, e o trafego na rede
pode estar sujeita a interceptaes.

3.

Gerenciamento os computadores do sistema

podem ser de tipos diferentes e podem operar em
verses diferentes de sistemas operacionais.
Defeitos em uma mquina podem se propagar a
outra maquinas com conseqncias inesperadas.

4.

Imprevisibilidade Como todos os usurios da

web

sabem,

os

sistemas

distribudos

so

imprevisveis em suas respostas. A resposta

depende

da

carga

total

do

sistema,

sua

organizao e a carga da rede.

Como tudo isso pode mudar em um curto perodo de tempo, o tempo
de resposta para uma solicitao do usurio pode variar drasticamente de uma
solicitao para outra.
Possuem dois tipos diferentes de arquiteturas de sistemas
distribudos:
1.

Arquitetura cliente-servidor: o sistema como um

17

conjunto

de

servios

fornecidos

aos

clientes que fazem uso desses servios. Os

servidores e clientes so tratados de maneiras
diferentes nesses sistemas.
2.

Arquiteturas de objetos distribudos. Podemos

pensar no sistema como um conjunto de objetos
que interagem e cuja localizao irrelevante.
No h distino entre cliente e servidor.
Tanto a arquitetura cliente-servidor e a arquitetura
de objetos distribudos so amplamente usadas
no setor, mais a aplicao ocorre geralmente
dentro de uma nica organizao. A organizao
, portanto, intra-organizacional.

3.1.5.2.1 Arquitetura de multiprocessadores

O multiprocessador So processos que podem ser executados
separados. Esses modelos tomam decises usando essas informaes e enviam
sinais aos atuadores, que modificam o ambiente do sistema. O uso de vrios
processadores aprimora o desempenho e a capacidade de recuperao do sistema.
3.1.5.2.2 Arquitetura Cliente-servidor
Em uma arquitetura cliente-servidor, uma aplicao modelada
como um conjunto de clientes que usam esses servios. Os clientes precisam estar
informados sobre os servios disponveis, mas geralmente no sabem da existncia
de outros clientes. Vrios processos de servios podem ser executados em um
nico processador de servio, portanto no h mapeamento entre processos e

18

processadores de um sistema.
O projeto de sistemas cliente-servidor deve refletir a estrutura lgica
da aplicao que esta sendo desenvolvida. Um exemplo uma aplicao que esta
dividida em trs camadas:

camada

de

apresentao:

que

se

encarrega

da

apresentao de informaes para o usurio e toda a

interao com o usurio.

A camada de processos de aplicaes se encarrega da

implementao da lgica da aplicao.

A camada de gerenciamento de dados se encarrega de todas

as operaes de banco de dados.

A arquitetura cliente-servidor mais simples denomina-se arquitetura

cliente-servidor de duas camadas, podem ter duas formas:

Modelo cliente-magro: O processamento e o gerenciamento

de dados so realizados no servidor. O cliente apenas
executa o software de apresentao.

Modelo cliente-gordo: O servidor responsvel somente pelo

gerenciamento de dados. O software do cliente implementa a
lgica da aplicao e as interaes com o usurio do sistema.

Uma desvantagem do modelo cliente-magro que ele impe uma

grande carga de processamento sobre o servidor e a rede. O modelo cliente-gordo
faz uso dessa capacidade de processamento disponvel e distribui o processamento
lgico de aplicao e a apresentao do cliente. O servidor essencialmente um
servidor de transaes que gerencia todas as transaes do banco de dados.
Enquanto o modelo cliente-gordo distribui o processamento mais eficientemente do
que um modelo cliente-magro, o gerenciamento do sistema mais complexo. A
funcionalidade da aplicao dividida entre vrios computadores. Quando o
software precisa ser alterado, isso envolve reinstalao em cada computador cliente,
o que pode resultar em um custo significativo se houver centenas de clientes no
sistema. O Problema com a abordagem cliente-servidor de duas camadas que as
trs camadas lgicas devem ser mapeadas sobre dois sistemas de computador o
cliente e o servidor. Pode haver problemas de escalabilidade e desempenho, se o

19

modelo cliente-magro for escolhido, ou problemas de gerenciamento de sistemas, se

o modelo cliente-gordo for usado. Para evitar esses problemas uma alternativa
usar o modelo cliente-servidor de trs camadas. Em alguns casos melhor estender
o modelo cliente-servidor de trs camadas para uma variante com varias camadas,
na qual servidores adicionais so incorporados ao sistema.
3.1.5.2.3 Arquiteturas de objetos distribudos
Nesse modelo os objetos podem ser distribudos entre uma serie de
computadores na rede e se comunicam atravs de um middleware, que chamado
de requisitor de objetos. O Middleware fornece uma interface transparente continua
entre os objetos. Ele fornece um conjunto de servios que permitem que os objetos
se comuniquem e sejam adicionados e removidos do sistema. As vantagens so que
permite que o projetista do sistema postergue decises sobre onde e como os
servios devem ser fornecidos. uma arquitetura de sistema aberto que permite que
novos recursos sejam adicionados.
Uma arquitetura de objetos distribudos pode ser usada como um
modelo lgico, que permite estruturar e organizar o sistema. Uma arquitetura de
objetos distribudos em lugar de uma arquitetura cliente-servidor adequada para
esse tipo de aplicao porque o modelo lgico do sistema no um dos
fornecimentos de servios em que existem servios distintos de gerenciamento de
dados e pode adicionar bancos de dados ao sistema sem grandes interrupes.
A maior Desvantagem que elas so mais complexas do que sistemas clienteservidor.
3.1.5.2.4 CORBA
Existem quatro elementos principais desse padro:
1.

Um modelo de objeto para objetos de aplicaes

em que um objeto corba um encapsulamento
de estado com uma interface bem definida em
linguagem neutra descrita em uma linguagem de
definio de interface.

20

2.

Um

requisitor

de

objetos

que

gerencia

solicitaes para servios de objetos.

3.

Um conjunto de servios de objetos que so

servios gerais com probabilidade de serem
solicitados por muitas aplicaes distribudas.

4.

Um

conjunto

de

componentes

comuns

construdos sobre esses servios bsicos que

podem ser solicitados pelas aplicaes.
O Corba considera um objeto como se fosse um encapsulamento de
atributos e servios, como normal em objetos.
Ele deve ter uma definio de interface separada que define
atributos e operaes publicas do objeto. As interfaces so definidas por uma
linguagem de definio de interface padronizada independe de linguagem.
O objeto corba tem um nico identificador chamado de referencia de
objeto interoperavel. Esse IOR usado quando um objeto solicita servios de outro
objeto. O requisitor de objetos conhece os objetos que esto solicitando servios e
suas interfaces. O ORB cuida da comunicao entre os objetos, os objetos que se
comunicam no precisam conhecer a localizao de outros objetos nem sobre sua
implementao. O objeto que fornece o servio tem um esqueleto de IDL associado
que liga a interface a implementao dos servios.
O corba foi desenvolvido desde 1980 e as verses recentes de
corba foram simplesmente dedicadas ao apoio aos objetos distribudos.
Os

padres

Corba

incluem

definies

de

interface

para uma grande variedade de componentes horizontais e verticais. Os

componentes verticais so componentes especficos de um domnio de aplicao.
Os componentes horizontais so componente de propsito geral,
como componentes de interface com o usurio.
3.1.5.2.5 COMPUTAO INTERORGANIZACIONAL DISTRIBUIDA
Por motivo de segurana e interoperabilidade, a computao
distribuda foi implementada inicialmente em nvel organizacional. Uma organizao
tem uma serie de servidores e distribui sua carga computacional entre eles. Devido

21

ao fato de eles estarem todos localizados dentro da mesma organizao, pode ser
aplicado padres e processos operacionais locais.
3.1.5.2.6 ARQUITETURAS PONTO A PONTO
So sistemas descentralizados em que as computaes podem ser
realizadas por qualquer n da rede, nenhuma distino feita entre clientes e
servidores. O sistema global projetado para beneficiar-se da capacidade
computacional e armazenamento disponvel em uma rede de computadores
potencialmente grande. Em principio, em sistemas ponto a ponto, todo n de rede
pode estar ciente a respeito de qualquer outro n, pode fazer conexes com ele e
pode trocar dados com ele. Em uma arquitetura descentralizada, os nos de rede no
so simplesmente elementos funcionais, mais tambm chaves de comunicao que
podem guiar os sinais de dados e de controle de um n para o outro.
No entanto quando se recupera um documento, o n que esta recuperando se torna
visvel para outros.
3.1.5.2.7 ARQUITETURA DE SITEMA ORIENTADO A SERVIOS
A essncia de um servio, que o fornecimento dos servios
independente

da

aplicao

que

usa

servio.

Os

provedores de servios podem desenvolver servios especializados e oferec-los a

uma gama de usurios de servios de organizaes diferentes. O proposto WEB
Service foi lanada, pois o acesso de servidores web era somente por meio de
navegar web, e o acesso direto aos repositrios de informaes por outros
programas no era pratico. Os trs padres fundamentais que possibilitam
comunicao entre WEB SERVICES so:

SOP: Define uma organizao para troca estruturada de

dados entre WEB SERVICES.

WSDL. Define como as interfaces dos WEB services podem

ser representadas.

UDDI. Este um padro de descobrimento que define como

as informaes de descrio do servio usadas pelos

22

solicitantes do servios para descobrir servios, pode ser

organizada.
Todos esses padres so baseados em XML.

3.5.3

CAPITULO 13 Arquitetura de Aplicaes

3.1.5.3.1 SISTEMAS DE PROCESSAMENTO DE DADOS

Aplicaes de processamento de dados so aplicaes voltadas aos
dados. Elas Processam dados em lotes sem intervenes explicitas do usurio
durante o processamento. As aes explicitam tomadas pela aplicao dependem
dos dados que so processados. Os sistemas de processamento em lotes so
normalmente usados em aplicaes de negcios nas quais as operaes similares
so realizadas sobre uma grande quantidade de dados. Eles tratam de uma grande
variedade de funes administrativas, como folha de pagamento, cobrana,
contabilidade e publicidade. Essas aplicaes enfocam os dados. Os bancos de
dados so geralmente maiores que os sistemas de informaes (SI).
Os

sistemas

de

processamento

de

dados

selecionam os dados de registros de entrada e, dependendo do valor dos campos

nos registros, tomam algumas aes especificadas no programa. Eles podem,
ento, enviar o resultado novamente do processamento ao banco de dados e
formatar

entrada

sada

processada

para

impresso.

Os sistemas de processamento de dados possuem trs componentes principais:

Entrada: A entrada coleta as entradas de uma ou mais fontes.

Processamento: O processamento realiza a computao

usando essas entradas.

Sada: A sada gera Sadas a serem escritas novamente no

banco de dados e ou impressas.

Os componentes de entrada, processamento e de sada podem ser

decompostos ainda em uma estrutura entrada-processamento-sada. Exemplo:

23

Um componente de entrada pode ler algum dado de um arquivo ou banco de dados

(entrada) e corrigir alguns erros (processo) e, depois enfileirar os dados validos para
processamento (sada).
So sistemas orientados a funes, pois os registros e as
transaes so processados em serie, sem necessidade de manter o estado entre
as transaes.
3.1.5.3.2 SISTEMAS DE PROCESSAMENTO DE TRANSAES
Os sistemas de transaes so projetados para processar
solicitaes de informaes por usurios de um banco de dados. Tecnicamente uma
seqncia de operaes tratada como uma unidade simples (uma unidade
atmica). Todas as operaes tm que ser realizadas antes que as mudanas
tornem-se permanentes no banco de dados.
Os sistemas de processamento de transaes so geralmente
sistemas interativos nos quais os usurios enviam solicitaes assncronas de
servio. Primeiro um usurio faz uma solicitao para o sistema atravs de um
componente de processamento de entrada/sada. A solicitao processada por
alguma lgica especifica da aplicao. Uma transao criada e passada para um
gerenciador de transaes, que em geral incorporado ao sistema de
gerenciamento de banco de dados. Depois que o gerenciador de transaes
assegurarem que a transao foi concluda adequadamente, ele sinalizara para a
aplicao que o processamento foi finalizado.
A estrutura entrada-processo-sada se aplica aos muitos sistemas de
processamento de transaes. Alguns desses sistemas so verses interativas de
sistemas de processamento de lotes.
Um exemplo de sistema de processamento de transaes um
sistema bancrio que permite aos clientes consultarem suas contas e retirarem
dinheiro de um caixa eletrnico. O sistema composto de dois subsistemas de
software que cooperam entre si o software de caixa eletrnico e o software de
processamento de contas localizadas no servidor de banco de dados. Os
subsistemas de entrada e de sada so implementados como softwares no caixa
eletrnico, uma vez que o subsistema de processamento est no servidor de banco

24

de dados.
Em sistemas como os de contabilidade de clientes de um banco,
pode haver diferentes maneiras de interagir com o sistema. Muitos clientes
interagiro por meio de caixas eletrnicos, mas uma equipe do banco usara
terminais de mesa para acessar o sistema. Pode haver vrios tipos de caixas
eletrnicos e terminais de mesa, e alguns clientes e a equipe do banco podem
acessar

os

dados

de

contas

por

meio

de

navegadores

WEB.

Para simplificar o gerenciamento de diferentes protocolos de comunicao entre

terminais, sistemas de processamento de transaes de larga escala podem incluir
middleware para comunicao com todos os tipos de terminal, organizao e
ordenao em serie dos dados dos terminais e envio dos dados para
processamento.
3.1.5.3.3 SISTEMAS DE GERENCIAMENTO DE INFORMAES E RECURSOS
Um sistema de informaes permite acesso controlado de uma
grande base de informaes, tais como catalogo de bibliotecas, tabela de horrios
de vos ou registros de pacientes em um hospital. O desenvolvimento da WEB fez
com que um grande numera de sistemas de informaes migrasse de sistemas
organizacionais especializados para sistemas de propsito geral acessveis
universalmente.
O sistema de informao modelado com o uso de uma abordagem
de camadas ou de maquina abstrata na qual a camada superior apia a interface
com o usurio e a camada inferior, o banco de dados de sistema. A camada de
comunicaes inclui uma lgica especifica de aplicao para acesso e atualizao
do banco de dados.
Sistemas de alocao de recursos uma classe de aplicao
amplamente usada. Sua arquitetura esta alinhada com o modelo de sistema de
informaes.
O componente de um sistema de alocao de recursos inclui:
1) Um banco de dados de recursos que mantm detalhe de recursos
que so alocados. Os recursos podem ser adicionados ou removidos do banco de
dados.

25

2) Um conjunto de regras que descreve as regras de alocao de

recursos.
3) Um componente de gerenciamento de recursos que permite que o
provedor de recursos adicione, edite ou elimine recursos do sistema.
4) Um componente de alocao de recursos que atualiza o banco de
dados de recursos quando eles so designados e que associa esse recursos a
detalhes do solicitante do recurso.
5) Um modulo de autenticao de usurios que permite ao sistema
verificar se os recursos esto sendo alocados para um usurio reconhecido.
6) Um modulo de gerenciamento de consultas que permite ao
usurio descobrir quais recursos esto disponveis.
7) Um componente de entrega de recursos que prepara os recursos
a serem entregues ao solicitante. Em um sistema de emisso de ingressos, isso
pode envolver a preparao de uma confirmao por e-mail, o envio de uma
solicitao para uma impressora que imprime os ingressos e os detalhes de para
onde os ingressos devem ser enviados.
8) Um componente de interface com o usurio que esta fora do
sistema e permite ao solicitante do recurso enviar consultas e solicitaes para o
recurso a ser alocado.
3.1.5.3.4 SISTEMAS DE PROCESSAMENTO DE EVENTOS
Os sistemas de processamento de eventos respondem aos eventos
do ambiente ou da interface com o usurio do sistema. A principal caracterstica dos
sistemas de processamento de eventos que a seqncia de eventos imprevisvel
e o sistema deve ser capaz de trabalhar com esses eventos quando eles ocorrerem.
Sistemas de tempo real, so tambm sistemas de processamento baseados em
eventos, porem ao invs de ter eventos de interface com o usurio, tem eventos
associados a sensores e atuadores do sistema.

26

3.1.5.3.5 SISTEMAS DE PROCESSAMENTO DE LINGUAGENS

Os sistemas de processamento de linguagens aceitam uma
linguagem natural ou artificial como entrada e geram alguma outra representao
dessa linguagem como sada. Em engenharia de software, os sistemas de
processamento de linguagens mais amplamente usados so os compiladores que
traduzem uma linguagem artificial de programao de alto nvel em cdigo de
maquina. Mais outros sistemas de processamento de linguagens traduzem uma
descrio de dados XML em comandos para consultar um banco de dados e
sistemas de processamento de linguagem natural que tentam traduzir uma
linguagem em outra.
Os tradutores em um sistema de processamento de linguagens tm
uma arquitetura genrica que inclui os seguintes componentes:
1.

Um analisador lxico, que obtm elementos da

linguagem de entrada e os converte em um
formato interno.

2.

Uma

tabela

de

smbolos

que

mantm

informaes sobre os nomes de entidades

(variveis, nomes de classes.) usadas no texto
que esta sendo traduzido.
3.

Um analisador sinttico, que verifica a sintaxe da

linguagem que est sendo traduzida. Ele usa uma
gramtica definida de linguagem e constri uma
arvore de sintaxe.

4.

Uma rvore de sintaxe, que uma estrutura

interna que representa o programa que esta
sendo compilado.

5.

Um analisador semntico, que usa informaes

da rvore de sintaxe e da tabela de smbolos para
verificar

correo

sinttica

do

texto

da

linguagem de entrada.
6.

Um gerador de cdigo que caminha pela rvore

27

de sintaxe e gera o cdigo de maquina abstrata.

3.5.4

CAPITULO 29 Gerenciamento de Configuraes

Gerenciamento de configuraes so o desenvolvimento e o uso de

padres e procedimentos para o gerenciamento de sistemas de software em

desenvolvimento. H muitas razes Por que os sistemas existem em diferentes
configuraes. Configuraes podem ser produzidas para diferentes computadores,
para diferentes sistemas operacionais, incorporando funes especificas de clientes.
Os gerentes de configuraes so responsveis por manter a rastreabilidade das
diferenas entre verses de software, para assegurar que as novas verses sejam
derivadas de maneira controlada e liberar novas verses para clientes certos no
momento certo.
3.1.5.4.1 PLANEJAMENTO DE GERENCIAMENTO DE CONFIGURAES
O plano de gerenciamento de configuraes descreve os padres e
procedimentos que devem ser usados para o gerenciamento. O ponto de partida
para o desenvolvimento do plano deve ser um conjunto de padres de configurao,
que devem ser adaptados para se atender aos requisitos e as restries de cada
projeto especfico.
3.1.5.4.1.1 IDENTIFICAO DE ITEM DE CONFIGURAO
Em um grande sistema de software, pode haver mdulos de
milhares de cdigos fonte, scripts de testes, documentos de projeto etc. Eles so
produzidos por pessoas diferentes e, quando criados, podem ser denominados com
nomes similares ou idnticos. Para manter a rastreabilidade de todas essas
informaes de maneira que o arquivo certo possa ser encontrado quando for
necessrio voc necessita de um esquema de identificao consistente para todos
os

itens

no

sistema

de

gerenciamento

de

configuraes.

Durante o processo de planejamento de gerenciamento de configurao, voc

28

decide

exatamente

quais

itens

sero

controlados.

Planos

de

projetos,

especificaes, projetos, programas, e massa de dados de teste so normalmente

mantidos como itens de configurao. Todos os documentos que podem ser teis
para a evoluo futura do sistema devem ser controlados pelo sistema de
gerenciamento de configurao. O esquema de identificao de itens de
configurao deve atribuir um nico nome para todos os documentos sob controle
de configurao. Esse nome pode refletir o tipo do item, uma parte do sistema ao
qual ele se aplica, o criador do item. No esquema de atribuio de nomes, voc
pode desejar evidenciar a relao entre os itens para garantir que os documentos
relacionados possuam uma mesma raiz em seus nomes. Portanto, voc pode definir
um esquema de hierarquia com nome. Esquemas de nomes hierarquizados so
simples e de fcil compreenso: algumas vezes, podem mapear uma estrutura de
diretrios usada para armazenar arquivos de projeto. No entanto, refletem a
estrutura de projeto na qual o software foi desenvolvido. Os nomes de itens de
configurao associam componentes com um projeto especifico e, dessa maneira,
reduzem as oportunidades para o reuso. Pode ser muito difcil encontrar
componentes relacionados.
3.1.5.4.1.2 BANCO DE DADOS DE CONFIGURAO
O banco de dados de configurao utilizado para registrar todas as
informaes relevantes sobre as configuraes de sistema e os itens de
configurao. Voc usa o banco de dados CM para auxiliar a avaliao do impacto
das mudanas de sistema e para gerar relatrios para a gerencia sobre o processo
de CM. Como parte do processo de CM, deve-se definir o esquema do banco de
dados de CM, os formulrios para coletar informaes para serem registradas no
banco de dados e procedimentos para registro e recuperao de informaes de
projeto.
Um banco de dados de configurao pode registrar informaes
sobre usurios de componentes, clientes de sistemas, plataformas de execuo,
mudanas propostas e etc. De preferncia, um banco de dados de configurao
deve ser integrado com a verso do sistema de gerenciamento usada para
armazenar

gerenciar

os

documentos

formais

do

projeto.

29

Um banco de dados de configurao armazena informaes sobre itens de

configurao e referencia seus nomes num sistema de gerenciamento de verso ou
depsito de arquivos.
3.1.5.4.2 GERENCIAMENTO DE MUDANAS
As necessidades e requisitos organizacionais alteram-se durante a
vida til de um sistema. Isso significa que voc precisa fazer as mudanas
correspondentes no sistema de software. Para garantir que essas mudanas sero
aplicadas ao sistema de maneira controlada, voc precisa de um conjunto de
procedimentos

de

gerenciamento

de

mudanas

apoiado

por

ferramentas.

Procedimentos de gerenciamento de mudana dizem respeito a analise de custo e

beneficio das mudanas propostas, a aprovao das mudanas viveis e a
rastreabilidade de quais componentes do sistema foram alterados. O processo de
gerenciamento de mudana deve surtir efeito quando o software ou a documentao
associada so colocados em baseline pela equipe de gerenciamento de
configuraes.
O primeiro estgio no processo de gerenciamento de configuraes
completar um formulrio de solicitao de mudana (CRF change request form)
que descreve a mudana necessria para o sistema. Uma vez que o formulrio de
solicitao de mudana enviado, ele deve ser registrado no banco de dados de
configurao. A solicitao de mudana ento analisada para verificar se a
mudana solicitada necessria.
Para mudanas validas, o estagio seguinte a avaliao da
mudana e o custo. O impacto da mudana no restante do sistema deve ser
verificado. Isso envolve todos os componentes afetados pela mudana. Se realizar a
mudana significa que mudanas adicionais em alguma parte do sistema so
necessrias, isso aumenta claramente o custo de sua implementao. Em seguida
as mudanas necessrias para os mdulos do sistema so avaliadas. Finalmente, o
custo para realizar a mudana estimado, considerando os custos de mudana nos
componentes relacionados.

30

3.1.5.4.3 GERENCIAMENTO DE VERSES E RELEASES

Os processos envolvidos no gerenciamento de verses e relases
preocupam-se com a identificao e a manuteno da rastreabilidade das verses
de um sistema. Gerentes de verses idealizam procedimentos para assegurar que
as verses de um sistema possam ser recuperadas quando solicitadas e no sejam
alteradas acidentalmente pela equipe de desenvolvimento. Para produtos, os
gerentes trabalham com a equipe de marketing, e , para sistemas feitos sob
encomenda, com os clientes, para planejar quando novos releases de um sistema
devem ser criados e distribudos para implantao.
Um release do sistema uma verso distribuda aos clientes. Cada
release deve incorporar novas funcionalidades ou ser planejado para uma
plataforma diferente de hardware.
3.1.5.4.3.1 IDENTIFICAO DE VERSES
Para criar uma verso especifica de um sistema, voc precisa
especificar as verses dos componentes de sistema que devem ser includas nele.
Voc no pode usar o nome do item de configurao para identificar a verso,
porque

ele

pode

ter

muitas

verses

para

cada

item

de configurao identificado.
A trs tcnicas bsicas para identificao da verso de componentes
so:
1.

Numerao de verses: O componente recebe

um numero explicito e nico de verso. Isso o
mais

comumente

usado

no

esquema

de

identificao.
2.

Identificao

baseada

em

atributos:

Cada

componente tem um nome (como o nome do item

de configurao, que no nico para diferentes
verses) e um grupo de atributos associados
para cada verso, componentes so portanto,
identificados pela especificao de seus nomes e

31

valores de atributos.
3.

Identificao

orientada

mudanas:

Cada

componente denominado como na identificao

baseada em atributos, mas tambm associado
com uma ou mais solicitaes de mudanas. Ou
seja,

considera

se

que

cada

verso

de

componente foi criada em resposta a uma ou

mais solicitaes de mudanas. A verso de
componente identificada pelo conjunto de
solicitaes de mudanas que se aplicam ao
componente.
3.1.5.4.3.2 GERENCIAMENTO DE RELEASES
Um release de sistema uma verso do sistema distribudo para os
clientes. Os gerentes de release de sistemas so responsveis por decidir quando
um sistema pode ser liberado para os clientes, gerenciar o processo de criao do
release e de meios de distribuio e documentar o release para assegurar que ele
pode

ser

recriado

exatamente

como

foi

distribudo,

se

for

necessrio.

A criao de um release um processo de criao de arquivos e documentos que

inclui todos os componentes do release do sistema. O cdigo executvel de
programas e todos os arquivos de dados associados devem ser coletados e
identificados.

Se

os

manuais

serem

lidos

em

computadores so distribudos, copias eletrnicas devem ser armazenadas com o

software. Finalmente, quando todas as informaes estiverem disponiveis, o
diretrio do release manipulado para a distribuio.
Quando um release de sistema produzido, ele deve ser
documentado para assegurar que possa ser recriado ipsis literis no futuro. Isso
importante para sistemas embutidos de ciclo de vida longo e feitos para os clientes,
como aqueles que controlam maquinas complexas.
Para documentar um release voc deve registrar as verses
especificas dos componentes de cdigo fonte usados para criar o cdigo executvel.
Voc deve manter compias dos cdigos fonte e cdigo executvel, e de todos os

32

arquivos de dados e de configurao. Voc deve tambm registrar as verses do

sistema operacional, as bibliotecas, os compiladores e outras ferramentas usadas
para construir o software. Elas podem ser necessrias para construir exatamente o
mesmo sistema em alguma data posterior.
3.1.5.4.4 CONTRUO DE SISTEMAS
A construo de sistemas um processo de compilao e ligao de
componentes de software num programa que executa determinada configurao
definida. Quando voc esta construindo um sistema com base em seus
componentes, voc deve pensar nas seguintes questes:
1.

Todos os componentes que compem um sistema

foram includos nas instrues de construo?

2.

verso

necessrio

apropriada
foi

de

includa

cada
nas

componente

instrues

de

construo ?
3.

Todos os arquivos de dados necessrios esto

disponveis?

4.

Se os arquivos de dados esto referenciados

dentro de um componente, o nome usado o
mesmo que o do arquivo de dados na maquina
alvo?

5.

A verso apropriada do compilador e de outras

ferramentas requeridas esta disponvel?

As verses atuais das ferramentas de software podem ser

incompatveis com as verses antigas usadas para desenvolver o sistema.
3.1.5.4.5 FERRAMENTAS CASE PARA GERENCIAMENTO DE CONFIGURAES
Processos de gerenciamento de configuraes so normalmente
padronizados e envolvem aplicaes de procedimentos predefinidos. Eles requerem
o gerenciamento cuidadoso de grande quantidade de dados e essencial a ateno
aos detalhes. Quando um sistema est sendo construdo com base em verses de

33

componentes, um nico erro de gerenciamento de configurao pode significar que

o software no ir operar adequadamente. Consequentemente, o apoio de uma
ferramenta CASE essencial para o gerenciamento de configurao. Essas
ferramentas podem ser combinadas para criar uma rea de trabalho para apoiar
todas as atividades de CM.

3.2 FRAMEWORKS PARA DESENVOLVIMENTO WEB

3.2.1 Comparao de frameworks para desenvolvimento web (Java).
Devido ao crescimento acelerado da Internet e, conseqentemente,
as facilidades que a mesma oferece, a empresa China Telecom decidiu migrar de
seus sistemas Desktop para sistemas Web. Esta migrao em grande escala fez
com que o desenvolvimento Web tambm crescesse para atender essa demanda e,
com isto, esta empresa assim como as empresas que decidiram investir nessa
migrao tiveram vantagens como: Disponibilizar servios a um maior nmero de
pessoas; Expandir o horizonte da empresa graas ao maior alcance da Internet.
Porm, era necessrio que as formas de desenvolvimento Web
tambm evolussem, pois ainda eram usadas tcnicas que no proporcionavam a
produtividade esperada, e um sistema Web era considerado muito complexo de
desenvolver, afinal, as ferramentas de programao para essa plataforma no eram
muito eficazes em relao s seguintes caractersticas: confiabilidade, produtividade,
facilidade de desenvolvimento e o principal, reusabilidade. Em paralelo a essa
necessidade, um padro usado em smalltalk nos anos 80 voltou a ser utilizado, o
MVC (Modelo-View-Controller ou Modelo-Viso-Controle), onde os programadores
criam interfaces e 15 telas, acesso a dados e lgica de negcios de forma
independente, o que se notou uma forma eficiente de se desenvolver aplicativos
Web.
A importncia de usar frameworks tambm notada ao seguir o
modelo MVC, porque, sem frameworks fica praticamente impossvel utilizar

34

corretamente esse modelo, usando Java EE (Enterprise Edition) como exemplo,

possvel seguir esse modelo usando Java Server Pages para a criao do layout de
pginas na camada de viso; usar um banco de dados conectado ao JDBC para a
camada de modelo. No entanto, a camada de controle no possvel cri-la
independentemente das outras camadas, ou seja, para desenvolver a camada de
controle puramente em Java EE seria necessrio usar cdigo correspondente a
lgica de negcios em todas as pginas JSP (Java Server Pages) o que no torna a
aplicao independente entre camadas, pois assim a camada de viso estaria sobre
a camada de controle o que em manutenes futuras seria um agravante, pois para
uma simples alterao no layout da pgina poderia afetar o cdigo referente
camada de controle justamente por eles encontrarem-se no mesmo arquivo.
3.2.2 Custo Benefcio de frameworks no desenvolvimento Web

Parvolteis de implementao atravs de interfaces estveis.

Aumenta a reutilizao definio de componentes genricos

que podem ser replicados para criar novos sistemas.

Extensibilidade favorecida pelo uso de mtodos hooks que

permitem que as aplicaes estendam interfaces estveis.

Inverso de controle IoC o cdigo do desenvolvedor

chamado pelo cdigo do framework. Dessa forma, o
framework controla a estrutura e o fluxo de execuo dos
programas.

3.2.3 Programao Java Web (plataforma de desenvolvimento).

Aplicao web designa, de forma geral, sistemas de informtica
projetados para utilizao atravs de um navegador, atravs da internet ou
aplicativos desenvolvidos utilizando tecnologias web HTML, JavaScript e CSS.1
Pode ser executado a partir de um servidor HTTP (Web Host) ou localmente, no
dispositivo do usurio.
Uma aplicao web tambm definida em tudo que se processado

35

em algum servidor, exemplo: quando voc entra em um e-commerce a pgina que

voc acessa antes de vir at seu navegador processada em um computador ligado
a internet que retorna o processamento das regras de negcio nele contido. Por isso
se chama aplicao e no simplesmente site web.
A funo do servidor web receber uma solicitao (requisio) e
devolver (resposta) algo para o cliente.O browser permite ao usurio solicitar um
recurso e quando o servidor responde a uma solicitao so encontrados recursos
como: pginas HTML, figuras e documento PDF que so exibidas depois para o
usurio. Geralmente os servidores enviam instrues para o browser escritas em
HTML. O HTML diz ao browser como apresentar contedo ao usurio web.
O servidor em si tem alguns recursos, mas por algumas deficincias
no consegue processar tudo sozinho como: criaes de pginas dinmicas e o
armazenamento de dados em um banco de dados.
Pginas dinmicas Quando a aplicao roda no servidor, este
disponibiliza somente pginas estticas. Porm, para efetuar essa comunicao
necessrio o auxlio de uma outra aplicao de ajuda que passada atravs de
Servlet.
Armazenar dados no servidor Para efetuar essa ao o servidor
precisa de uma aplicao de apoio (Servlet), fazendo com que o servidor envie
esses parmetros para o Servlet.
As falhas de segurana podem surgir em diferentes etapas, tais
como: anlise de requisito; especificao; Implementao. Os riscos de aplicao na
vulnerabilidade de uma empresa pode causar impactos.
O HTTP usa um modelo de solicitaes e respostas. Uma solicitao
ocorre quando o usurio faz uma solicitao HTTP e o servidor web devolve uma
resposta HTTP, sendo que o browser verifica como tratar esse contedo. Se a
resposta que vem do servidor for uma pgina HTML, ento inserido na resposta
HTTP.
As diferenas entre as solicitaes GET e POST so que enquanto o
GET anexa dados do formulrio no final da URL o POST inclui dados do formulrio
no corpo da solicitao.

36

3.3 PROJETO ORIENTADO A OBJETOS

Como j foi dito na descrio do problema da China Telecon, a
melhor soluo para essa empresa seria realmente adotar um software de uma
empresa especializada e com um bom suporte. Mas nos baseando na hiptese de a
empresa querer desenvolver seu prprio software, para reduzir os custos seria
necessrio tambm reduzir o tempo de desenvolvimento do mesmo e manter a
qualidade e produtividade no desenvolvimento. Alm de contar com uma equipe de
profissionais capacitados, tambm seria necessrio adotar padres e tcnicas que
iro ajudar a desenvolver um bom sistema para a empresa.
Analisando entre os padres existentes, fcil chegar concluso
que o melhor padro para ser adotado no desenvolvimento do software em questo
seria a arquitetura MVC.
A arquitetura MVC foi desenvolvida para ser usado em projetos de
interface visual em Smalltalk, linguagem de programao que juntamente com o C+
+ ganhou grande reconhecimento na poca, o MVC foi criado na dcada de 70, e
aps esses anos de sua criao ainda um pattern aplicvel nas mais variadas
aplicaes, principalmente em aplicaes web.
Quando um software comea a ficar grande e complexo, muitos
dados so apresentados para os usurios, sentimos a necessidade de aplicar uma
arquitetura que facilite nosso trabalho, desde a organizao do projeto, as divises
das responsabilidades at as possveis modificaes que podero ser efetuadas ao
longo do desenvolvimento do software para isso precisaram dividir o projeto em trs
objetos para aplicar o MVC.
MVC composto por trs tipos de objetos. O modelo o objeto de
aplicao, a vista a apresentao na tela e o controlador define a maneira como a
interface do usurio reage s entradas do mesmo. Antes do MVC, os projetos de
interface para o usurio tendiam em agrupar esses objetos. MVC para aumentar a
flexibilidade e a reutilizao. (GAMMA et al. 2000, p. 20).
O MVC tem como principal objetivo: separar dados ou lgicos de
negcios (Model) da interface do usurio (View) e o fluxo da aplicao (Controller), a
idia permitir que uma mensagem da lgica de negcios possa ser acessada e

37

visualizada atravs de vrias interfaces. Na arquitetura MVC, lgica de negcios,

ou seja, nosso Model no sabe quantas nem quais as interfaces com o usurio esta
exibindo seu estado, a view no se importa de onde esta recebendo os dados, mas
ela tem que garantir que sua aparncia reflita o estado do modelo, ou seja, sempre
que os estados do modelo mudam, o modelo notifica as view para que as mesmas
atualizem-se.
MVC um conceito (paradigma) de desenvolvimento e design que
tenta separar uma aplicao em trs partes distintas. Uma parte, a Model, esta
relacionada ao trabalho atual que a aplicao administra outra parte a View esta
relacionada a exibir os dados ou informaes dessa uma aplicao e a terceira
parte, Controller, em coordenar os dois anteriores exibindo a interface correta ou
executando algum trabalho que a aplicao precisa completar. (GONALVES, 2007,
p. 141).
Model ou modelo a camada que contm a lgica da aplicao,
responsvel pelas regras de negcio, para sistemas persistentes, o modelo
representa a informao (dados) dos formulrios e as regras SQL para manipular
dados do banco, o modelo mantm o estado persistente do negcio e fornece ao
controlador capacidade de acessar as funcionalidades da aplicao, o modelo o
principal responsvel toda aplicao deve representar o modelo atua isoladamente
no tem conhecimento de quais sero a ou as interfaces que ter de atualizar, o
modelo somente acessa base de dados e deixa os dados prontos para o
controlador este por sua vez encaminha para a viso correta.
View: ou viso a camada de apresentao com usurio, a
interface que proporcionar entrada de dados e a visualizao de respostas
geradas, nas aplicaes web representado pelo HTML que mostrado pelo
browser, geralmente a viso contm formulrios, tabelas, menus e botes para
entrada e sada de dados. A viso deve garantir que sua apresentao reflita o
estado do modelo, quando os dados do modelo mudam, o modelo notifica as vistas
que dependem dele, cada vista tem a chance de atualizar-se. Desta maneira permite
ligar muitas vistas a um modelo podendo fornecer diferentes apresentaes, essa
camada no contm cdigos relacionados lgica de negcios, ou seja, todo o
processamento feito pelo Modelo e este repassa para a viso, evidenciaremos

38

abaixo um exemplo de duas vistas atuando sobre o mesmo modelo.

Controller: j descrevemos da view e do modelo, mas, temos de
concordar que tudo isso se tornaria uma baguna se tivesse algum para organizar
esta arquitetura, um controlador funciona de intermedirio entre a camada de
apresentao e a camada de negcios, sua funo como j diz controlar
coordenar o envio de requisies feitas entre a viso e o modelo. O controller define
o comportamento da aplicao, o controle quem interpreta as solicitaes (cliques,
selees de menus) feitas por usurios com bases nestes requerimentos o
controlador comunica-se com o modelo que seleciona a view e atualiza-a para o
usurio, ou seja, o controlador controla e mapeia as aes.
Embora o MVC s contenha trs camadas h outra camada
fundamental para o bom andamento da arquitetura, esta um mecanismo de
eventos necessrio a comunicao entre outros trs elementos, este elemento
permite uma comunicao assncrona que invocada quando algum evento
interessante acontece, esta quarta camada contm os beans de entidade onde se
localizam os mtodos get e set das classes.
A arquitetura MVC utiliza padres de projetos em suas camadas
analisamos a arquitetura agora com os patterns.
O MVC usa outros padres de projeto, tais como Factory Method,
para especificar por falta (by default) a classe controladora para uma vista e
Decarator, para acrescentar capacidade de rolagem (scrolling) a uma vista. Mais os
principais relacionamentos do MVC so fornecidos pelos padres Observer,
Composite, Strategy. (GAMMA et al. , 2000, p. 22)
Os designs patterns nos ajuda explicar a arquitetura MVC, e com
eles podemos perceber que por traz do MVC pode conter um conjunto de padres
trabalhando

juntos

patterns Observer

em
e

uma

mesma

Strategy que

estrutura.

so

Abordamos

padres

agora

os

comportamentais

o Composite padro estrutural, o objetivo de abordar os patterns para facilitar a

compreenso de como a arquitetura MVC trabalha, sabendo que um padro de
arquitetural que confundem projetistas e desenvolvedores.
Nas

palavras

de Gamma

et

al. os

principais

padres

que

o MVC utiliza so os Observer, Composite e o Strategy. Analisemos a Figura 3 do

39

livro de Padres de Projetos dos autores Freeman & Freeman que nos ajudar a
explicar como os padres contribuem na arquitetura MVC:
A visualizao ou a View juntamente com o padro Composite est
disposio do usurio esperando por qualquer evento, quando este evento ativado
o controlador avisado sobre o evento, este avisa para a viso se atualizar, e ao
mesmo tempo manda o modelo para que ele atue para contemplar o evento
provocado pelo usurio, depois de atuado o modelo fica pronto para ser acessada
pela visualizao esta por sua vez acessa e atualiza-se para o usurio assim
funciona a arquitetura MVC em conjunto com os padres de projetos.
Utilizando essa arquitetura, o tempo de desenvolvimento do software
diminuir sem perde a qualidade e sem aumento de custos.
Uma das melhores opes seria o Hibernate como framework de
persistncia de dados.
O Hibernate um framework para mapeamento objeto/relacional em
Java, que abstrai o cdigo SQL da aplicao, permitindo, entre outra coisas,
modificar a base de dados para outro SGBD (Sistema Gerenciador de Banco de
Dados) sem modificar uma linha de cdigo Java.
O Hibernate um framework open source de mapeamento
objeto/relacional desenvolvido em Java, ou seja, ele transforma objetos definidos
pelo desenvolvedor em dados tabulares de uma base de dados, portanto com ele o
programador se livra de escrever uma grande quantidade de cdigo de acesso ao
banco de dados e de SQL.
Se comparado com a codificao manual e SQL, o Hibernate
capaz de diminuir 95% das tarefas relacionadas persistncia.
A utilizao de cdigo SQL dentro de uma aplicao agrava o
problema da independncia de plataforma de banco de dados e complica, em muito,
o trabalho de mapeamento entre classes e banco de dados relacional.
O Hibernate abstrai o cdigo SQL da nossa aplicao e permite
escolher o tipo de banco de dados enquanto o programa est rodando, permitindo
mudar sua base sem alterar nada no seu cdigo Java.
Alm disso, ele permite criar suas tabelas do banco de dados de um
jeito bem simples, no se fazendo necessrio todo um design de tabelas antes de

40

desenvolver seu projeto que pode ser muito bem utilizado em projetos pequenos.
O Hibernate no apresenta apenas a funo de realizar o
mapeamento objeto relacional. Tambm disponibiliza um poderoso mecanismo de
consulta

de

dados,

permitindo

uma

reduo

considervel

no

tempo

de

desenvolvimento da aplicao.
No caso do desenvolvimento do sistema China Telecon poderia ser
utilizada qualquer ferramenta de base Java, como Eclipse ou NetBeans. O que vai
definir a escolha de uma ferramenta seria a afinidade da equipe com determinada
ferramenta. No meu caso utilizaria o netbeans por ter uma interface grfica mais
atraente e por suportar os diversos Frameworks para Java.
O Netbeans uma poderosa ferramenta de desenvolvimento Java.
Entre muitas melhorias, esta verso dar suporte s plataformas PHP, JavaScript e
Ajax, Ruby e Ruby em Rails, Groovy e C/C++.
O NetBeans tem um interface bem organizado e disponibiliza um
conjunto de funes que permitem aos programadores desenvolver aplicaes de
alto nvel. Considerando que a linguagem de programao Java uma das mais
usadas atualmente, o Netbeans torna-se um excelente IDE para desenvolvimento

41

4 CONCLUSO
Vemos que na atual situao em que se encontra a empresa China
Telecom, e pelas mudanas que quer realizar, a importncia da Engenharia de
Software para planejar todos os requisitos e aes de inovaes que quer implantar.
Tambm da importncia que so os frameworks e a plataforma Java para a
aplicao Web e da arquitetura MVC no projeto orientado a objetos para um melhor
resultado de seu software.

42

5 REFERNCIAS
Wikipdia. Aplicao Web. Wikipdia, a enciclopdia livre. Disponvel em: <
http://pt.wikipedia.org/wiki/Aplica%C3%A7%C3%A3o_web>. Acesso em: 10 de mai
2015.
Wikipdia.

Framework.

Wikipdia,

enciclopdia

livre.

Disponvel

em:

<http://pt.wikipedia.org/wiki/Framework>. Acesso em: 10 de mai 2015.

SOMMERVILE, Ian. ENGENHARIA DE SOFTWARE. 8 Edio. So Paulo: Pearson
Addison Wesley, 2007.
Lima, Maria, Gerenciamento de escopo em projetos, acessado em 10 de maio de
2015,

disponvel

em:

<http://www.devmedia.com.br/pmbok-gerenciamento-de-

escopo-em-projetos/29787>
Project Management Institute, Um Guia do Conhecimento Em Gerenciamento de
Projetos - Guia Pmbok - 5 Ed. 2014 -