3

SUMRIO
1

INTRODUO 6

OBJETIVO

DESENVOLVIMENTO 8

3.1

PROGRAMAO PARA WEB II 17

3.1.1

Comparao de frameworks

3.1.2

Relacione custo de frameworks18

3.1.3

Programao Java Web plataforma de desenvolvimento 18

3.2

17

PROJETO ORIENTADO A OBJETOS

CONCLUSO

20

REFERNCIAS

21

18

1 INTRODUO
O trabalho China Telecom -

prope que o aluno entenda os

requisitos para desenvolver o sistema com qualidade e tambm no gerenciamento

de recursos.

2 OBJETIVO
Este trabalho o aluno poder aprofundar seus conhecimentos
adquiridos, aprender a adotar os padres do guia pmbok(guia de pratica na gesto
de projetos) e dos captulos do livro engenharia de software, alem do conhecimento
pratico no desenvolvimento de aplicaes Java com frameworks.

3 DESENVOLVIMENTO
3.1 Este projeto descrito abaixo China Telecom demanda recursos de vrias
pessoas e
especialistas, alm de inmeros recursos, entre hardware, software, fornecedores,
viagens, entre outros.
Pesquisar e descrever uma resenha sobre as reas da competncia, segundo
PMBoK,
para as seguintes reas:

Riscos: o processo de analisar, identificar, monitorar e controlar os riscos do

projeto. Tendo como objetivo maximizar sua exposio aos eventos positivos
e minimizar aos eventos negativos.
Processos da gerencia de riscos.

1. Planeja o gerenciamento: definir como ser conduzida o gerenciamento de

riscos no projeto.
2. Identificar: identificar e catalogar os riscos que podem afetar o seu projeto.
3. Analise qualitativa: analisar a exposio aos riscos para a partir da ver a
prioridade dos riscos que sero objeto de anlise ou outra ao adicional.
4. Analise quantitativa: analisar o numero dos efeitos dos riscos identificado nos
objetivos do projeto.
5. Planejar resposta: desenvolver aes e mtodos para reduzir as ameaas ao
projeto.
6. Controlar: controlar e monitorar os riscos durante toda vida til do projeto

Escopo: Segundo o Guia PMBOK

O gerenciamento do escopo trata

principalmente da definio e controle do que do que no est includo no

projeto.
Processos da gerencia de escopo:
1. Planejamento do escopo: definir estratgias e documentaes para o
desenvolvimento do escopo. Durante este processo importante definir o
escopo do cliente para saber os produtos e servios relacionados ao
projeto que ser entregue a ele.
2. Definio do escopo: deve-se definir as datas de entrega do projeto e o
trabalho a ser realizado para cumprir esta entrega.
3. Criao de EAP: Segundo o Guia PMBOK A EAP uma decomposio
hierrquica orientada entrega do trabalho a ser executado pela equipe
do projeto, para atingir os objetivos do projeto e criar as entregas

necessrias. A EAP organiza e define o escopo total do projeto.

Com a criao da EAP fica mais fcil a visualizao do projeto e as
entregas por ambas as partes, melhorando assim o gerenciamento do
projeto de forma geral.
4.

Verificao do escopo: responsvel pelo recebimento e entrega das

atividades, durante as fases do projeto ou at mesmo sua entrega final e
tambm por dar um retorno dessa entrega que pode ser aceitao total,
parcial ou negativa. Em todos os casos junto tem que vir a justificativa dos
atos.

Fornecedores: o processo necessrio para comprar produtos, servios ou

resultados externos a sua equipe de projetos, j que nem sempre possvel
desenvolver seus produtos na sua totalidade. Trazendo isso pra rea de
desenvolvimento de sistemas, podemos utilizar para terceirizar um servio ou
comprar alguma ferramenta pronta, j que ficaria caro, demandaria muito
tempo e necessitaria de uma equipe altamente qualificada para desenvolver
internamento no projeto.

11. Projeto de arquitetura

O projeto de arquitetura consiste em identificar subsistemas, em um sistema
grande, e estabelecer um framework para a comunicao destes subsistemas,
sendo o primeiro estagio no processo de projetos. Segundo o livro, existem trs
vantagens em projetar e documentar uma arquitetura:
Comunicao de stakeholders: uma apresentao em alto nvel do sistema que
enfoca
a
discusso
entre
diferentes
stakeholders.
Analise de sistemas: mostra como o sistema trabalha com os principais requisitos
como
confiabilidade,
desempenho
e
facilidade
de
manuteno.
Reuso em larga escala: utiliza a mesma arquitetura para sistemas com requisitos
similares, utilizando assim o reuso de software em larga escala.
O projeto de arquitetura de sistema pode afetar o desempenho a manuteno
e a distribuio, a estrutura pode no entanto depende de requisitos no funcionais
no sistema de acordo com suas prioridades, como por exemplo:
1. Desempenho: a arquitetura deve ser projetada para localizar operaes critica
dentro de alguns subsistema, quanto menos comunicao entre eles melhor.
2. Proteo: deve-se usar uma estrutura em camada com os itens mais crticos
protegidos com camadas mais internas e um alto nvel de validao.
3. Segurana: as operaes relacionadas a segurana devem estar em um nico
subsistema ou em pequeno numero, reduzindo problemas de segurana e validao
4. Disponibilidade: deve-se utilizar componentes redundantes podendo assim
substituir ou atualizar componentes sem parar o sistema
5. Facilidade de manuteno: a arquitetura deve usar componentes de baixa
granularidades e autocontidos que poder ser modificados a qualquer momento.

10

Como vimos nos exemplos acima algumas dessas arquiteturas entram em conflito
com outras, se ambas forem requisitos importante deve-se procurar uma soluo
eficaz.
11.1 Decises de projeto de arquitetura
O projeto de arquitetura depende muito da criatividade, experincia e
conhecimento do arquiteto, do tipo de sistema e dos requisitos especficos. O
arquiteto deve analisar o que seu sistema e classe tem em comum e decidir quais
podem reusar.
11.2 Organizao de sistema
A organizao de sistema esta relacionada de maneira subjetiva com suas
decises com um modelo organizacional de um sistema antes do projeto de
arquitetura. A organizao reflete diretamente nos subsistemas, agora vamos ver
trs estilos organizacionais amplamente utilizados no mercado.
11.2.1 Modelo repositrio
Os subsistemas trocam informaes como se trabalhassem juntos, podendo
fazer isso de duas formas: os dados compartilhados podem ser acessados por
subsistemas atravs de banco de dados compartilhado, ou cada subsistema
mantm seu prprio BD trocando dados atravs de mensagem entre eles.
11.2.2 Modelo cliente-servidor
um sistema organizado geralmente em redes, com exceo quando o
computador cliente e servidor ao mesmo tempo, que acessam e usam servios de
modo que os clientes solicitam os servios oferecidos e os servidores atendem as
requisies dos subsistemas, as vezes os clientes tem que saber os nomes e os
servios que os servidores oferecem.
11.2.3 Modelo em camadas
Organiza um sistema em camada que fornecem um conjunto de servios.
Este modelo apia o desenvolvimento incremental de sistemas, disponibilizando
servios para o usurio a medida que uma camada desenvolvida. Nessa
arquitetura uma camada pode ser substituda por outra equivalente.Este modelo tem
alguma desvantagens por sua dificuldade em estruturar sistemas dessa maneira e o
desempenho pode ser um problema devido a vrios nveis de interpretao
11.3 Estilos de decomposio modular
Feita a escolha da organizao geral do sistema, deve-se definir a forma
usada na decomposio dos subsistemas em mdulos, usando duas estratgias
para decompor estes subsistemas.
11.3.1 Decomposio orientada a objetos
O sistema estruturado em um conjunto de objetos, no firmemente
acoplados, e os objetos chamam servios disponibilizados por outros objetos.
Essa decomposio esta relacionada a classe de objetos, operaes e seus
atributos. Os objetos so criados a partir dessas classes e para coordenar as
operaes usado algum modelo de controle .
11.3.2 Pipelining orientado a funes
As transformaes processam entradas e produzem sadas, com os dados
fluindo de uma funo para outra, transformados ao se moverem em seqncia. A
implementao feita a cada transformao. So convertidos em dados de sada
atravs dessas transaes.
Temos algumas vantagens com o uso dessa arquitetura: reuso de
transformaes, arquitetura intuitiva, fcil implementao, novas transformaes na

11

maior parte de forma direta. Mas temos um problema, necessrio um formato

comum pare que os dados possa ser reconhecido por todas as transformaes.
11.4 Modelos de controle
Tem como finalidade controlar subsistemas para que seus servios no lugar e
no tempo certo, para assim funcionar como um sistema. O modelo de controle deve
ser suplementar ao modelo de arquitetura utilizado.
11.4.1 Controle centralizado
Como o prprio nome j diz, o controle feito de forma centralizada com um
subsistema responsvel pelo gerenciamento e execuo de outros subsistemas.
Esse sistema dividido em duas classes: modelo chamada - retorno e modelo
gerenciados.
11.4.2 Sistemas orientados a eventos
Nos modelos orientados a eventos as decises so geradas de maneira
externa e pode assumir uma gama de valores, o que gera e depende uma interao
com o usurio e bastante usado tambm em sistemas de inteligncia artificial.
11.5 Arquitetura de referencia
Serve como uma referencia para comparar conceitos de domnio ou comparar
possveis arquiteturas. Na verdade serve como um roteiro de implementaes
fornecendo uma base na qual os sistemas podem ser avaliados e comparados
seguindo os padres OSI ou CASE.
Capitulo 12 Arquitetura de sistemas distribudos
No sistema distribudo as aplicaes so distribudas e processadas por
vrios computadores e no em apenas uma maquina.
Temos algumas vantagens ao usar sistemas distribudos: compartilhamento
de recursos de software e hardware,uso de arquiteturas de hardware e software de
diferente fabricantes, vrios processos podem operar em computadores diferentes,
com a duplicao da informao o sistema se torna tolerante a algumas falhas de
hardware e software, facilidade de adio de novos recursos para atender
demandas do sistema.
Se comparado com sistemas que trabalham com um processador ou em
cluster podemos ter algumas desvantagens: os sistemas distribudos so mais
complexos, podem ser acessados por vrios computadores diferentes, podendo
sofrer interceptao na rede, defeito de uma maquina pode passar pra outra e
dificultar a identificao do problema, a depender do trafego da rede (lan, wan, man)
podemos ter um desempenho imprevisvel podendo variar de forma imprevisvel.
Os sistemas distribudos possuem dois tipos de arquiteturas:
1. cliente-servidor. O servidor disponibiliza os servios e estes so usados
pelos clientes, neste modelo clientes e servidores so tratados de formas
distintas.
2. Arquiteturas de objetos distribudos. No a diferena entre cliente e
servidor, todos interagem independente de sua localizao e de sua
importncia.
12.1 Arquitetura de multiprocessadores
Nessa arquitetura os processos podem ser executados em vrios
processadores, aumentando assim o desempenho e a capacidade de recuperao
do sistema, esse sistema muito comum em sistemas de processamento de grande

12

porte e em tempo real.

12.2 Arquitetura cliente-servidor
Como j vimos no capitulo anterior, basicamente um conjunto de servios
fornecidos pelos servidores e acessados pelos clientes, que precisa apenas saber
os servios disponveis.
Nesse modelo podemos trabalhar com duas arquiteturas diferentes. A mais
simples o modelo de duas camadas, tendo duas formas:
Modelo cliente-magro: o gerenciamento e processamento so realizados no
servidor e os resultados apresentado na tela do cliente.
Modelo cliente-gordo: o servidor apenas gerencia os dados, o cliente executa
toda aplicao e interao com o cliente.
O cliente-magro tem a desvantagem de gerar grande trafego na rede e
sobrecarregar o processamento do servidor. Enquanto o cliente-gordo distribui a
capacidade de processamento disponvel e a apresentao ao cliente, porem o
gerenciamento do sistema se torna mais complexo e quando h alterao no
software, necessrio reinstalar todos os clientes, o que demanda tempo e custos
elevados a depender do numero de clientes.
Para resolver estes problemas pode ser adotado o modelo cliente-servidor em
trs camadas, sendo necessrio as vezes estender este modelo para uma variante
com varias camadas.
12.3 Arquiteturas de objetos distribudos
Nesse modelo os clientes recebem servios apenas dos servidores e nunca
de outros clientes e os servidores podem ser clientes de outros servidores para
receber servios. Os componentes principais desse sistema so os objetos que
fornecem uma interface para um conjunto de servios, que por sua vez chamado
por outros objetos sem distino lgica entre servidores e clientes.
Os objetos se comunicam atravs de um middleware( resquisitor de objetos),
distribudo em vrios computadores na rede, que fornece uma interface continua e
transparente entre os objetos alem de um conjunto de servios que permitem que
objetos sejam removidos e adicionados do sistemas.
12.3.1 CORBA
Os padres CORBA abrangem em todos os aspectos os objetos definidos
pela OMG( que define padres para o desenvolvimento orientado a objetos), no qual
podemos destacar quatro principais elementos desse padro:
1. Modelo de objeto. Trata os objetos como um encapsulamento de servios e
atributos, com uma interface separada que define as operaes publicas dos
objetos e os seus atributos. Para um objeto usar os servios oferecidos por
outros objetos ele solicita uma atravs da interface IDL e cada objeto
identificado atravs de seu identificador de referencia, chamado de IOR.
2. Requisitor de objetos. Cuida da comunicao entre os objetos, identifica os
objetos que esto solicitando servios e suas interfaces, sendo que os objetos
no precisar saber a localizao nem a implementao de outros objetos.
3. Conjunto de servios. a probabilidade dos recursos serem solicitados por
vrios sistemas distribudos.
4. Conjunto de componentes. Definio de interface para componentes
horizontais( componentes de propsitos geral) e verticais( componentes
especficos de um domnio de aplicao), que so usados por quem
desenvolve aplicaes distribudas.

13

12.4 Computao interorganizacional distribuda

Implementada inicialmente em modelo organizacional por motivos de
interoperabilidade e seguranas. Geralmente tem vrios servidores com distribuio
de tarefas entre eles, pelo fato de estarem na mesma organizao facilita a
aplicao
de
padres
e
operaes
locais.
12.4.1 Arquitetura ponto a ponto
No sistema ponto a ponto(p2p) os dados so descentralizados, no existe a
figura do cliente servidor. Os dados ficam distribudos por vrios computadores
espalhados por uma grande rede, geralmente a internet, onde todo n tem cincia
do que o outro compartilhar e pode trocar dados simultaneamente com vrios ns
que
disponibilizam
os
mesmos
dados
12.4.2 Arquitetura de sistema orientado a servios
Com a popularizao da internet e a necessidade de acesso aos dados fora
da organizao. Foi criado o web service tornando assim acessveis programas e
informaes
na
internet.
CAPITULO 13 Arquitetura de aplicaes
Sistema de aplicaes so criados para atender rotinas em comum em muitas
organizaes. Geral mente esses sistemas possuem arquiteturas similares, na
verdade e um sistema genrico que pode ser adaptado e configurado para uma
aplicao
especifica.
13.1 Sistema de processamento de dados
So sistemas de processamento(orientado a funes) que processam os
dados de entradas e sada em lotes, na forma de arquivo ou banco de dados sem
interveno do usurio durante este processo. Sistemas de processamento em lotes
geralmente so usados quando as operaes so usadas sobre uma grande
quantidade de dados.
O sistema de processamento de dados trabalha basicamente da seguinte
forma: A entrada, recebe a entrada de dados de uma ou varias fontes, o
processamento faz as operaes lgicas destes dados e a sada ao receber os
dados j processados, gera as sada a serem gravadas no BD.
13.2 Sistemas de processamento de transaes
O sistema de transaes funciona com uma ponte entre o usurio e o BD. As
operaes de transaes iteragem o tempo todo com o usurio e o banco de dados
e s gravada quando confirmada a consistncia e a viabilidade dos dois lados.
Como exemplo temos o caixa eletrnico, o usurio que deseja fazer um saque, o
sistema do caixa verifica no banco de dados do servidor, o saldo, o valor a ser
sacado e s grava no BD se a transao for concluda e o valor a ser sacado for
compatvel menor ou igual ao saldo.
13.3 Sistemas de gerenciamento de informaes e recursos
Controla o acesso a uma base de informaes muito grande. Com o advento
da internet e o acesso universal de sistemas e dados de forma remota, surgiu a
necessidade de controlar o acesso a informao e seus recursos.
Esse sistema modelado em camadas de modo que a camada superior

14

trabalha com a interface do usurio e a camada inferior com o banco de dados. A

camada de comunicao do usurio registra as entradas e sadas da interface do
usurio, que por sua vez interage com a camada de recuperao de informaes
que tem uma lgica para acesso e gravao no banco de dados.
13.3 Sistemas de processamento de eventos
Os sistemas de eventos interagem com ambiente e interface de usurios,
eventos estes imprevisveis e o sistema s pode tomar uma deciso quando eles
ocorrem. Temos vrios exemplos destes eventos com: processadores de texto,
editores de imagem, uso do mouse at exemplos mais complexo que ao invs de
usar interface de usurio utiliza sensores e inteligncia artificial em tempo real como
carros que estacionam s, entre outros.
13.3 Sistemas de processamento de linguagens
Basicamente recebe uma linguagem natural/artificial como entrada e geram
outra representao de linguagem como sada. Temo como exemplo os
compiladores que traduzem a linguagem de programao de alto nvel em
linguagem de maquina, sistemas que traduzem linguagem XML em comando para
BD e sistemas que tentam traduzir de uma linguagem para outra.
CAPITULO 29 gerenciamento de configuraes
O gerenciamento de configuraes feito com uso de procedimento e
padres para gerenciar o sistema em desenvolvimento, importante fazer esse
gerenciamento porque o engenheiro pode ter dificuldade em saber quais mudanas
foram incomporadas em que verso do sistema perdendo assim a rastreabilidade.
29.1 Planejamento de gerenciamento de configuraes
Deve-se descrever os procedimentos e padres usado para o gerenciamento.
Partindo do ponto do uso de um padro de configurao, que pode ser adaptado
para
atender
as
restries
e
requisitos
de
projetos
especficos.
29.1.1 Identificao de item de configurao
Um software grande criado por varias pessoas diferente e pode haver
milhares de cdigos, scripts de teste etc. e podem ter nomes parecidos, para
garantir a rastreabilidade necessrio um esquema de identificao consistente
para todos itens no sistema de gerenciamento de configurao.
Durante o planejamento do gerenciamento voc decide quais itens vo ser
controlados. Normalmente por padro projetos, programas, planos de projetos,
massa de dados e testes e especificaes, so itens de configurao, assim como
todos os documentos que forem teis para uma futura evoluo do sistema.
29.1.2 Banco de dados de configurao
Registra todas as informaes importantes sobre os itens e as configuraes
de sistema. usado tambm o banco de dados CM para auxiliar o impacto das
mudanas no sistema e para gerar relatrios sobre o processo de CM para a
gerncia. O esquema do CM deve ser definido, os formulrios para coletar para
serem registrada e procedimentos para recuperao de informaes e registro de
projeto.
29.2 Gerenciamento de mudanas
Como tudo na vida os sistemas tambm tem sua vida til e diante isso deve-

15

se analisar as necessidade e a mudana de requisito organizacionais, o que significa

que necessrio fazer mudanas no sistema.
Para que estas mudanas seja feita de maneira controlada voc precisa
adotar procedimentos de gerencia de mudanas com apoio de ferramentas. Tem que
levar tambm em considerao o custo-benefcio das mudanas, a viabilidade e a
rastreabilidade
dos
componentes
alterados.
O primeiro processo de gerenciamento de configuraes fazer o CRF change
request form, que descreve as mudanas necessria no sistema. Eviado o CRF, ele
deve ser registrado no banco de dados de configurao e a solicitao de mudana
ento analisada para verificar se realmente necessrio realizar tal mudana.
Para mudanas realmente necessrias deve-se tambm avaliar os custos, o
impacto dessa mudana no restante do sistema, envolvendo os componentes
afetados
pela
mudana.
29.3 Gerenciamento de verses e releases
Gerencia a manuteno da rastreabilidade e identificao das verses do
sistema, o gerente de verses idealiza procedimentos para que as verses do
sistema sejam recuperadas quando solicitadas e que no corra o risco de ser
alterada por engano pela equipe de desenvolvimento. Para sistemas sob
encomenda deve-se planeja quando novos releases sejam criados e distribudos pra
implantao. O release uma verso distribuda para os clientes e cada novo
release deve incorporar funcionalidades novas ou ser planejado para hardware
diferente.
29.3.1 Identificao de verses
Em grandes sistemas existem centenas de componentes de software e para
criar uma verso especifica necessrio especificar as verses dos componentes
que devem ser includas nesse sistema. Basicamente existem trs tcnicas para
identificar verso de componentes: numerao de verses, onde o componente
recebe um numero nico de verso, identificao baseada em atributos, onde cada
componente tem um nome do item de configurao associados por um grupo de
atributos para cada verso e identificao orientada a mudanas, onde cada
componente denominada como na identificao anterior, porem tambm
associado com solicitaes de mudanas.
29.3.2 Gerenciamento de releases
Como vimos anteriormente um release uma verso do sistema distribudos
para o clientes e os gerentes que devem decidir quando um release esta pronto pra
ser liberado para os clientes, gerenciando o processo de criao e os meios de
distribuio, documentado o release para garantir que ele possa ser recriado como
foi distribudo originalmente caso haja necessidade.
A criao de release um procedimento de criao de documentos e arquivos
que devem conter todos os componentes do sistema, todos arquivos de dados
associados e o cdigo executvel dos programas devem ser identificados e
coletados. E todos manuais devem ser distribudo de todas as formas possveis para
se tornar acessvel aos usurios e sua limitaes. Aps todo este procedimento o
release
j
pode
ser
encaminhado
para
distribuio.

16

29.4 Construo de sistemas

um processo de compilao que faz a ligao de componentes de software
em um programa que executa uma configurao definida. Alguma ferramentas de
gerenciamento de configurao ou de ambiente de programao podem ser usadas
pra automatizar processo de construo de sistemas. Um script de construo
escrito pela CM com dependncias bem definidas entre os componentes de
sistemas, o script define as ferramentas para compilar e ligar os componentes e as
ferramentas de construo de sistemas interpretam o script e chamam outros
programas.
29.5 Ferramentas CASE para gerenciamento de configuraes
O uso de uma ferramenta CASE como apoio de extrema importncia para o
gerenciamento de configurao, podendo ser combinadas para criar uma rea de
trabalho e apoiar as atividades de CM. No mercado temos diversas ferramentas,
alguma inclusive de cdigo aberto e outras com sistemas mais abrangentes
integrados.
29.5.1 Apoio para gerenciamento de mudanas
As tarefas so divididas e cada pessoa fica responsvel por alguma atividade,
quando completadas passam os itens de configurao e os formulrios para os
outros. Nesse modelo os documentos certos so direcionados para pessoa certa a
todo momento.

17

3.1 PROGRAMAO PARA WEB II

3.1.1 Comparao de frameworks
Zend Framework: de uma empresa em que os fundadores so
grandes colaborares no desenvolvimento da linguagem PHP. Alem de ser uma
empresa bem antiga no mercado e com grandes parcerias como IBM e Oracle.
um framework muito bom para desenvolver grandes aplicaes e
conta com grande numero de colaboradores, tendo uma documentao bem
completa e com uma vasta biblioteca.
CodeIgniter: um framework de fcil desenvolvimento e muito
focado na questo do desempenho, traz com ele um MVC e algumas ferramentas
teis, porem no trabalha muito com outras tecnologias, como exemplo de no ter
ferramentas para Java script e no trabalhar com OMR.
Symfony: um dos frameworks mais antigos do mercado, trabalha
com geradores de cdigos, com o

YAML para especificaes, configuraes,

linguagem simples de marcao, alem de possuir uma grande quantidade de

funcionalidades e uma forte comunidade.

18

3.1.2 Relacione custo de frameworks

O uso de frameworks para desenvolvimento de aplicaes web
praticamente imprescindvel nos dias atuais no desenvolvimento de sistemas
voltados pra internet e intranet( aplicaes web).
Existem vrios benefcios em adotar o uso de frameworks dentre os
quais podemos destaca: ganho de produtividade, reduo de erros, maior
nvel de abstrao, integrao e compatibilidade entre aplicaes, alem de
contar com apoio e suporte de comunidades.
3.1.3 Programao Java Web plataforma de desenvolvimento
No mercado existem diversas IDEs que voc pode utilizar para
desenvolver sistemas web em Java, tendo como diferena bsica a integrao dos
recursos e a facilidade de uso. Algumas dessa IDEs so gratuitas (opensource) e
outra pagas.
Primeiramente vamos ver algumas gratuitas:
Netbeans. Ela bastante interessante e tem um ponto forte por ser
mantida pela prpria SUN ( empresa que criou a linguagem Java), ales de servir
para programar uma serie de linguagens como Javascript, Php, C++ e muitas outras,
roda em qualquer sistema operacional e tem milhares de plugins.
Eclipse. a IDE mais utilizada no mundo, mantida pela gigante IBM,
usa o modelo Swing como biblioteca grfica,

seu desenvolvimento orientado

baseado em plugins com amplo suporte ao desenvolvedores.

Das pagas podemos destacar a JBuilder da Borland, a mesma do
Delphi. Apesar de ser paga e baseada na Eclipse, possui um recurso inovador de
reaproveitamento de cdigo e uma forte integrao com padres de projeto,
ferramentas Case, UML etc.
3.2 PROJETO ORIENTADO A OBJETOS
Para o desenvolvimento do sistema China Telecom, ns usaremos o
modelo de arquitetura cliente-servidor em 3 camadas, podendo implementar outras
camadas caso haja necessidade. J que o sistema vai integrar o servidor web com o
banco de dados.
O framework adotado ser o Zend Framework que utilizado para

19

desenvolvimento de grande aplicaes, alem de possuir muitos recursos em sua

biblioteca como: ferramentas para WebService, formulrios com validao php,
conexo com vrios BD e muito mais. um framework orientado a objetos e j vem
em MVC e a documentao extensa e fcil de usar.

20

CONCLUSO
Este trabalho tambm me proporcionou um grande aprendizado e
aprimorou os conhecimentos adquiridos durante este semestre e possibilitou ainda
aliar o conhecimento terico com a pratica, atuando assim com um profissional da
rea .

21

REFERNCIAS
PMI Project Management Institute (Editor). PMBOK (Project Management
Body of Knowledge) Guide Um Guia do Conjunto de Conhecimentos em
Gerenciamento de Projetos.
SOMMERVILE, Ian. ENGENHARIA DE SOFTWARE. 8 Edio. So Paulo: Pearson
Addison Wesley, 2007."
http://lpriori.org/artigo/COMPARATIVO%20DE%20FRAMEWORK%20PHP.pdf