SUMRIO

INTRODUO.......................................................................................................3

Objetivo..................................................................................................................4

DESENVOLVIMENTO...........................................................................................5

3.1

Engenharia e Projeto de Software..................................................................5

3.2

Projeto de Arquitetura......................................................................................7

3.2.1

Capitulo 11 Projeto de Arquitetura...............................................................7

3.2.2

Capitulo 12 Arquitetura de Sistemas Distribudos.....................................11

3.2.3

Capitulo 13 Arquitetura de Aplicaes.......................................................15

3.2.4

Capitulo 29 Gerenciamento de Configurao...........................................17

3.3

Programao para Web II..............................................................................20

3.3.1

Comparao de Frameworks para Desenvolvimento Web (Java)...............20

3.3.2

Custo Benefcio de Frameworks no Desenvolvimento Web........................21

3.3.3

Programao Java Web (Plataforma de Desenvolvimento)........................22

3.4
4

Projeto Orientado a Objetos..........................................................................23

CONCLUSO......................................................................................................27

REFERNCIA.............................................................................................................28

1 INTRODUO

O trabalho a seguir China Telecom prope que o aluno entenda a demanda de

recursos (pessoas especialistas, hardwares e softwares, fornecedores, viagens,
entre outros).

2 OBJETIVO
Desenvolvimento

de

sistema

de

informao,

analisando,

incrementando o conhecimento em engenharia de software, gesto de projetos, e

programao para web. Com eixo temtico sobre a China Telecom, para
compreender o motivo da contratao de uma empresa de renome do que ela
mesma o fazer.

3 DESENVOLVIMENTO
3.1 ENGENHARIA E PROJETO DE SOFTWARE
Desafio 01
Analisamos, dentre as dificuldades e facilidades mapeadas na literatura, quais
e por que as mesmas esto presentes no processo de gerenciamento de projetos
com base no guia PMBOK. Verificamos quais os possveis argumentos que os
gestores vivenciam no gerenciamento de projetos no que diz respeito aos sucessos
e fracassos apresentados. O estudo se concentrou em profissionais com certificao
PMP por apresentarem o conhecimento em Gerenciamento de Projetos com base no
guia PMBOK e, por ser uma rea de crescimento onde as empresas buscam
profissionais com melhores prticas e vantagem competitiva. Valendo-se do
questionrio estruturado como instrumento de coleta de dados e analisando os
resultados, os principais pontos encontrados dizem respeito ao tempo em que os
gerentes lidam com gerenciamento de projetos, as dificuldades encontradas pelos
gerentes em sua prtica profissional, a rea do PMBOK com maior dificuldade de
ser gerenciada, os itens que geram sucessos e fracassos nos projetos. A entrevista
semiestruturada evidenciou que o gerenciamento de projetos apresenta algumas
dificuldades presentes na prtica profissional dos gerentes. Sugerimos investigar
melhor o impacto que a certificao PMP proporciona aos gerentes de projetos e se
a relao maturidade organizacional e experincia em gerenciamento de projetos
fator de sucesso para o projeto.
Algumas reas da competncia, segundo PMBOK esto relacionadas abaixo:
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 tem como objetivo determinar como os
riscos sero identificados, analisados e como as respostas sero planejadas 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 risco com novos risco sendo identificados, 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.
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.
Os processos dessa rea so: Coletar requisitos, definir o escopo, cria a EAP,
verificar o Escopo e Controlar o Escopo.
.
Fornecedores: Os processos de gerenciamento das aquisies do projeto
envolvem acordos, incluindo contratos, que so documentos legais entre um
comprador e um fornecedor. Um contrato representa um acordo mtuo que obriga o
fornecedor a oferecer algo de valor (por exemplo, produtos, servios ou resultados
especificados) e obriga o comprador a fornecer uma compensao monetria ou de
outro tipo. O acordo pode ser simples ou complexo, e pode refletir a simplicidade ou
complexidade dos resultados e do esforo necessrio.

3.2 PROJETO DE ARQUITETURA

Desafio 02

3.2.1 Capitulo 11 Projeto de Arquitetura

O projeto de arquitetura primeiro estgio no processo de projetos.
No livro diz que ele idntica subsistemas e estabelece um framework para controlar
a comunicao dos subsistemas, 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, Analise de sistemas, Reuso em larga
escala:
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.
Se o desempenho for um requisito crtico a aplicao deve localizar operaes
crticas 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 auto contidos que
possam ser prontamente mudados.
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.
Durante o processo de projeto de arquitetura os arquitetos de sistemas devem ser
feita 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 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?
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 est 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 do subsistema.
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.
O modelo em camadas organiza um sistema em camadas, cada uma das quais
fornecendo um conjunto de servios.
A abordagem em camadas apoia o desenvolvimento incremental de sistemas. A
medida que uma camada desenvolvida alguns servios fornecidos por essa
camada podem ser disponibilizados para os usurios. Essa arquitetura tambm
modificvel e portvel.
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.
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.
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 est relacionada a classes de objetos, seus
atributos e suas operaes. A vantagem que implementao de objetos pode ser
modificada sem afetar outros objetos.
A desvantagem que para usar servios os objetos devem fazer referncia explicita
ao nome e a interface de outros objetos.
No Pipelining orientado a funes ou modelo de fluxo de dados, as transformaes
processam suas entradas e produzem sadas. Os dados fluem de uma para outra
funo e so transformados ao moverem-se sequencialmente. Cada etapa
implementada como uma transformao.
Os dados de entrada fluem atravs dessas transaes at serem convertidos em
dados se sada.
Vantagens: Apoiar o reuso de transformaes.
Os modelos 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.
Em modelo de controle centralizado, um subsistema designado como controlado
de sistema e tem a responsabilidade pelo gerenciamento da execuo de outros
subsistemas. Tendo duas classes, dependendo se forem executados
sequencialmente ou paralelamente.
O modelo retorno 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 sequenciais.
Os modelos gerenciados, aplicados em modelos concorrentes. Sistema concorrente
projetado como um gerenciador de sistema e controla o incio, a parada e a
coordenao de outros processos do sistema.
As arquiteturas de referncia no so geralmente consideradas um roteiro de

10

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.
Uma proposta de modelo de referncia 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.

11

3.2.2 Capitulo 12 Arquitetura de Sistemas Distribudos

Um sistema bem 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:
Compartilhamento de recursos, Abertura, Concorrncia, Escalabilidade, Tolerncia a
defeitos.
Esses sistemas de distribuio comparados aos sistemas que operam com um
processador ou com um cluster de processadores podem ter algumas desvantagens
como: Complexidade, Proteo, Gerenciamento, Imprevisibilidade e Defeitos que em
uma mquina podem se propagar a outra maquinas com consequncias
inesperadas.
Tipos diferentes de arquiteturas de sistemas distribudos:
Arquitetura cliente-servidor. o sistema como um conjunto de servios fornecidos
aos
clientes que fazem uso desses servios. Os servidores e clientes so tratados de
maneiras diferentes nesses sistemas.
Arquiteturas de objetos distribudos. Podemos pensar no sistema como um conjunto
de objetos que interagem e cuja a 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, intraorganizacional.

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

12

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:
Permite que o projetista do sistema postergue decises sobre onde e como os
servios devem ser fornecidos.
Uma arquitetura de objetos distribudos em lugar de uma arquitetura cliente-servidor
adequada para esse tipo de aplicao por trs razes:
O modelo lgico do sistema no um dos fornecimentos de servios em que
existem servios distintos de gerenciamento de dados.
Pode adicionar bancos de dados ao sistema sem grande interrupes.
A maior Desvantagem que elas so mais complexas do que sistemas clienteservidor.

CORBA
Existem quatro elementos principais desse padro:
Um modelo de objeto para objetos de aplicaes.
Um requisitor de objetos.
Um conjunto de servios de objetos.
Um conjunto de componentes comum.
O Corba considera um objeto como se fosse um encapsula mento de atributos e
servios, como normal em objetos.
Os objetos Corba tem um nico identificador chamado de referncia de objeto
interopervel. Esse IOR usado quando um objeto solicita servios de um outro
objeto.
O requisitor de objetos conhece os objetos que esto solicitando servios e suas

13

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.
Os componentes verticais so componentes especficos de um domnio de
aplicao. Os componentes horizontais so componentes de propsito geral, como
componentes de interface com o usurio.
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 ao fato de eles
estarem todos localizados dentro da mesma organizao, podem ser aplicados
padres e processos operacionais locais.

A essncia de um servio, que o fornecimento dos servios independente da

aplicao que usa o servio. Os provedores de servios podem desenvolver servios
especializados e oferec-los a uma gama de usurios de servios de organizaes
diferentes.
A 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 prtico.

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 solicitantes do servios para descobrir servios,
pode ser organizada.

14

Todos estes padres baseados em XML.

15

3.2.3 Capitulo 13 Arquitetura de Aplicaes

Aplicaes de processamento de dados.
So Aplicaes voltados a dados. Elas processam dados em lotes sem intervenes
explicitas do usurio durante o processamento. As Aes explicitas 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.
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 a entrada e a sada processada para
impresso.
Os sistemas de transaes so projetados para processar solicitaes de
informaes por usurios de um banco de dados. Tecnicamente uma sequncia de
operaes tratada como uma unidade simples.
Todas as operaes tm que ser realizadas antes que as mudanas se tornem
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.
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.
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

16

meio de navegadores WEB.

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 mquina. 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:
Um analisador lxico, uma tabela de smbolos, um analisador sinttico, uma rvore
de sintaxe, um analisador semntico e um gerador de cdigo.

17

3.2.4 Capitulo 29 Gerenciamento de Configurao

Gerenciamento de configuraes o desenvolvimento e o uso de
padres e procedimentos para o gerenciamento de sistemas de software em
desenvolvimento. Ha muitas razes por que os sistemas existem em diferentes
configuraes.
Configuraes podem ser produzidas para diferentes computadores, diferentes
sistemas operacionais, incorporando funes especificas para 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.
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.
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.
Todos os documentos podem ser teis para a evoluo do sistema. O esquema de
identificao de itens de configurao deve atribuir um nico nome para todos os
documentos sob controle de configurao. 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.
O banco de dados de configurao utilizado para registrar todas as informaes
relevantes sobre as configuraes de sistema e os itens de configurao. Como
parte do processo de CM, deve-se definir o esquema do banco de dados de CM, os

18

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 e gerenciar os
documentos formais do projeto.
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.
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 estgio seguinte a avaliao da mudana e o custo. 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.
Uma das trs tcnicas bsicas para identificao da verso de componentes
Numerao de verses. O componente recebe um nmero explicito e nico de
verso. Isso o mais comumente usado no esquema de identificao.
"A verso de componente identificada pelo conjunto de solicitaes de mudanas
que se aplicam ao componente."

19

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 componentes,
um nico erro de gerenciamento de configurao pode significar que o software no
ir operar adequadamente.
Consequentemente, o apoio de um 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.

20

3.3 PROGRAMAO PARA WEB II

Desafio 03
3.3.1 Comparao de Frameworks para Desenvolvimento Web (Java).
Classifica-se um framework de acordo com duas dimenses: como ele utilizado e
onde utilizado. No tratamento de como um framework pode ser utilizado, ser
analisado o ponto de como introduzir as particularidades de uma aplicao. Neste
sentido Willemann e Ibarra (2007) os classificam em:

Caixa branca: so baseados na especializao por herana e sobrescrita de

mtodos, modificando assim as funcionalidades bsicas do framework.

Caixa preta: so os frameworks focados na composio, devendo utilizar as

funcionalidades j presentes no framework, ou seja, neste tipo de framework as

funcionalidades internas no podem ser vistas nem modificadas e devem-se
utilizar as interfaces fornecidas pelo framework. Neste framework as
instanciaes e composies feitas o que determinam as particularidades da
aplicao.
Caixa cinza: so frameworks hbridos, misturam os dois focos, herana e

composio, ou seja, so frameworks baseados em herana (caixa branca) com

algumas funcionalidades prontas.
A seguir so apresentadas as formas de utilizao de um framework.

Frameworks de suporte ou de integrao middleware: oferecem servios de

sistema de baixo nvel, tais como dispositivos de interface para perifricos

(drivers) e de acesso a arquivos, sendo normalmente usados para integrar
aplicaes e componentes distribudos, como frameworks BORBA ORB, DCOM,
implementaes do padro ODMG, entre outros (MATOS, 2008).
Frameworks de aplicao ou de infraestrutura: so frameworks que cobrem

funcionalidades que podem ser aplicadas a diferentes domnios. Ou seja, so

independentes do domnio ao qual ser endereado, como por exemplo, os
frameworks para sistemas operacionais, comunicao, redes e para construo
de interfaces (MATOS, 2008).
Frameworks de domnio: capturam conhecimento e especialidade em um
domnio de problema particular. Representam um projeto geral de aplicaes
para domnios especficos, como telecomunicaes, manufatura, jogos, controle
de produo, multimdia e engenharia financeira (MATOS, 2008).

21

3.3.2 Custo Benefcio de Frameworks no Desenvolvimento Web

Melhora a modularizao encapsulamento dos detalhes

volteis 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.

De acordo com Willemann e Ibarra (2007), a principal vantagem na utilizando de

frameworks a reduo de custos, sendo que j existe uma estrutura definida e
que o desenvolvimento pode concentrar-se em desenvolver as regras especficas
do negcio em que o sistema deve atuar. Um framework ainda proporciona uma
maior reutilizao de cdigos e a fatorao de problemas em aspectos comuns a
vrias aplicaes, permite tambm obter sistemas com cdigos menos frgeis e
com menos defeitos.
Entretanto, caso se decida construir um framework deve ter em mente que uma
tarefa complexa, pois o reuso no acontece por acaso, devendo ser
adequadamente planejado. Iniciar a construo de um framework sem um bom
planejamento pode trazer mais prejuzos do que vantagens.
Com certeza, construir uma aplicao e construir um framework paralelamente,
demora muito mais do que construir uma aplicao isolada. Isso tudo pelo fato de
que quando se constri um framework, deve-se planej-lo de forma que atenda a
mais do que uma aplicao, ou seja, atenda a um domnio especfico de aplicaes
e no somente uma. As vantagens de um framework s aparecem em longo prazo,
na medida em que a estrutura se torna consistente e de domnio das equipes de
desenvolvimento.

3.3.3 Programao Java Web (Plataforma de Desenvolvimento).

Os critrios que mais contriburam para selecionar as ferramentas que
utilizaremos ao longo do livro so simples: popularidade e experincia. Alm das

22

ferramentas selecionadas estarem entre as mais populares, elas fazem parte do diaa-dia dos autores. Isso com certeza possibilita criar um texto ao mesmo tempo
tcnico e composto de dicas, que so baseadas na experincia adquirida pelo uso
de tais ferramentas.
Alm disso, se voc desenvolver seu projeto usando o Apache Tomcat e o
MySQL, encontrar com mais facilidade algum servio de hospedagem que tenha
exatamente essa configurao. No basta ter uma excelente ideia de um novo
produto para a internet e execut-lo somente em seu computador domstico.
preciso pensar no futuro: seu produto pode ser o prximo a ser comprado por alguns
milhes de dlares por alguma megaempresa da internet.

3.4 PROJETO ORIENTADO A OBJETOS

Desafio 04
A melhor soluo para China Telecom 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

23

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.
Para a Gamma et al. 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 ideia
permitir que uma mensagem da lgica de negcios possa ser acessada e
visualizada atravs de vrias interfaces. Na arquitetura MVC, a lgica de negcios,
ou seja, nosso Model no sabe quantas nem quais as interfaces com o usurio
esto exibindo seu estado, a view no se importa de onde est 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

se

atualizem.

MVC um conceito (paradigma) de desenvolvimento e design que tenta separar

uma aplicao em trs partes distintas. Uma parte, a Model, est relacionada ao
trabalho atual que a aplicao administra outra parte a View est relacionada a exibir

24

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 a 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 a 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 a lgica de negcios, ou seja, todo o processamento
feito pelo Modelo e este repassa para a viso, evidenciaremos 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

25

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.
5. Design Patterns aplicados na arquitetura MVC
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 a 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

so

estrutura.
padres

Abordamos

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. 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 est por sua vez acessa e atualiza-se
para o usurio assim funciona a arquitetura MVC em conjunto com os padres de
projetos.
Ferramenta Utilizada
No caso do desenvolvimento do sistema China Telecom 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.

26

O Netbeans uma poderosa ferramenta de desenvolvimento Java. Entre muitas

melhorias, esta verso dar suporte s plataformas PHP, JavaScript e Ajax, Ruby e
Ruby on Rails, Groovy e C/C++.
O Netbeans 7 apresenta algumas melhorias comparativamente a verses anteriores
e das quais destacamos:

Suporte para o Java 7

Melhorias a nvel do editor

Suporte para HTML5

Suporte para quebras de linha

Suporte para Git 1.7.

Melhor integrao com bases de dados Oracle

O NetBeans tem uma 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.

27

4 CONCLUSO
A China Telecom se concentrar em usar o sistema para uma integrao mais profunda
com outros sistemas, de maneira que a empresa tenha uma viso completa de todos os
seus processos com clientes, fornecedores e funcionrio.

28

REFERNCIA
Silva, Flvio de Almeida e. Desenvolvimento Orientado a Objetos I. So Paulo:
Pearson Prentice Hall, 2009.
Perine, Luis Cludio. Engenharia de Software / Luis Cludio Perine, Marco Ikuno
Hisatomi, Wagner Luiz Berto. So Paulo: Pearson Prentice Hall, 2009.
Sommerville, Ian. Engenharia de Software,8 edio. So Paulo: Pearson AddisonWesley, 2007.