2015

3

SISTEMA DE ENSINO PRESENCIAL CONECTADOANALISE E DESENVOLVIMENTO DE SISTEMAS

CHINA TELECOM

2015

4

CHINA TELECOM

Trabalho de apresentado à Universidade Norte do Paraná - UNOPAR, como requisito parcial para a obtenção de média bimestral na disciplina de Analise e Desenvolvimento de Sistemas.

Orientadores: Prof. Anderson Emídio M. Gonçalves;Prof. Marcio Roberto Chiaveli;Prof. Roberto Y. Nishimura;Prof. Veronice de Freitas.

=

SUMÁRIO

1 INTRODUÇÃO 6

2 OBJETIVO 7

3 DESENVOLVIMENTO 8

3.1 PROGRAMAÇÃO PARA WEB II 17

3.1.1 Comparação de frameworks 17

3.1.2 Relacione custo de frameworks18

3.1.3 Programação Java Web – plataforma de desenvolvimento 18

3.2 PROJETO ORIENTADO A OBJETOS 18

CONCLUSÃO 20

REFERÊNCIAS 21

5

1 INTRODUÇÃO

O trabalho China Telecom - propõe que o aluno entenda os

requisitos para desenvolver o sistema com qualidade e também no gerenciamento

de recursos.

6

2 OBJETIVO

Este trabalho o aluno poderá aprofundar seus conhecimentos

adquiridos, aprender a adotar os padrões do guia pmbok(guia de pratica na gestão

de projetos) e dos capítulos do livro engenharia de software, alem do conhecimento

pratico no desenvolvimento de aplicações Java com frameworks.

7

3 DESENVOLVIMENTO

3.1 Este projeto descrito abaixo – China Telecom – demanda recursos de várias pessoas eespecialistas, além de inúmeros recursos, entre hardware, software, fornecedores,viagens, entre outros.Pesquisar e descrever uma resenha sobre as áreas da competência, segundo PMBoK,para as seguintes áreas:

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

projeto. Tendo como objetivo maximizar sua exposição 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 exposição aos riscos para a partir daí ver a

prioridade dos riscos que serão objeto de análise ou outra ação adicional.

4. Analise quantitativa: analisar o numero dos efeitos dos riscos identificado nos

objetivos do projeto.

5. Planejar resposta: desenvolver ações e métodos para reduzir as ameaças 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 definição e controle do que é do que não está incluído no

projeto”.

Processos da gerencia de escopo:

1. Planejamento do escopo: definir estratégias e documentações para o

desenvolvimento do escopo. Durante este processo é importante definir o

escopo do cliente para saber os produtos e serviços relacionados ao

projeto que será entregue a ele.

2. Definição do escopo: deve-se definir as datas de entrega do projeto e o

trabalho a ser realizado para cumprir esta entrega.

3. Criação de EAP: Segundo o Guia PMBOK “A EAP é uma decomposição

hierárquica orientada à entrega do trabalho a ser executado pela equipe

do projeto, para atingir os objetivos do projeto e criar as entregas

8

necessárias. A EAP organiza e define o escopo total do projeto”.

Com a criação da EAP fica mais fácil a visualização do projeto e as

entregas por ambas as partes, melhorando assim o gerenciamento do

projeto de forma geral.

4. Verificação do escopo: é responsável pelo recebimento e entrega das

atividades, durante as fases do projeto ou até mesmo sua entrega final e

também por dar um retorno dessa entrega que pode ser aceitação total,

parcial ou negativa. Em todos os casos junto tem que vir a justificativa dos

atos.

Fornecedores: é o processo necessário para comprar produtos, serviços ou

resultados externos a sua equipe de projetos, já que nem sempre é possível

desenvolver seus produtos na sua totalidade. Trazendo isso pra área de

desenvolvimento de sistemas, podemos utilizar para terceirizar um serviço 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 comunicação destes subsistemas, sendo o primeiro estagio no processo de projetos. Segundo o livro, existem três vantagens em projetar e documentar uma arquitetura:Comunicação de stakeholders: é uma apresentação em alto nível do sistema que enfoca a discussão entre diferentes stakeholders.Analise de sistemas: mostra como o sistema trabalha com os principais requisitos como confiabilidade, desempenho e facilidade de manutenção.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 manutenção e a distribuição, a estrutura pode no entanto depende de requisitos não funcionais no sistema de acordo com suas prioridades, como por exemplo:1. Desempenho: a arquitetura deve ser projetada para localizar operações critica dentro de alguns subsistema, quanto menos comunicação entre eles melhor. 2. Proteção: deve-se usar uma estrutura em camada com os itens mais críticos protegidos com camadas mais internas e um alto nível de validação.3. Segurança: as operações relacionadas a segurança devem estar em um único subsistema ou em pequeno numero, reduzindo problemas de segurança e validação4. Disponibilidade: deve-se utilizar componentes redundantes podendo assim substituir ou atualizar componentes sem parar o sistema5. Facilidade de manutenção: a arquitetura deve usar componentes de baixa granularidades e autocontidos que poder ser modificados a qualquer momento.

9

Como vimos nos exemplos acima algumas dessas arquiteturas entram em conflito com outras, se ambas forem requisitos importante deve-se procurar uma solução eficaz.11.1 Decisões de projeto de arquitetura

O projeto de arquitetura depende muito da criatividade, experiência e conhecimento do arquiteto, do tipo de sistema e dos requisitos específicos. O arquiteto deve analisar o que seu sistema e classe tem em comum e decidir quais podem reusar.11.2 Organização de sistema

A organização de sistema esta relacionada de maneira subjetiva com suas decisões com um modelo organizacional de um sistema antes do projeto de arquitetura. A organização reflete diretamente nos subsistemas, agora vamos ver três estilos organizacionais amplamente utilizados no mercado. 11.2.1 Modelo repositório

Os subsistemas trocam informações como se trabalhassem juntos, podendo fazer isso de duas formas: os dados compartilhados podem ser acessados por subsistemas através de banco de dados compartilhado, ou cada subsistema mantém seu próprio BD trocando dados através de mensagem entre eles.11.2.2 Modelo cliente-servidor

É um sistema organizado geralmente em redes, com exceção quando o computador é cliente e servidor ao mesmo tempo, que acessam e usam serviços de modo que os clientes solicitam os serviços oferecidos e os servidores atendem as requisições dos subsistemas, as vezes os clientes tem que saber os nomes e os serviços que os servidores oferecem.11.2.3 Modelo em camadas

Organiza um sistema em camada que fornecem um conjunto de serviços. Este modelo apóia o desenvolvimento incremental de sistemas, disponibilizando serviços para o usuário a medida que uma camada é desenvolvida. Nessa arquitetura uma camada pode ser substituída 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 vários níveis de interpretação11.3 Estilos de decomposição modular

Feita a escolha da organização geral do sistema, deve-se definir a forma usada na decomposição dos subsistemas em módulos, usando duas estratégias para decompor estes subsistemas. 11.3.1 Decomposição orientada a objetos

O sistema é estruturado em um conjunto de objetos, não firmemente acoplados, e os objetos chamam serviços disponibilizados por outros objetos.

Essa decomposição esta relacionada a classe de objetos, operações e seus atributos. Os objetos são criados a partir dessas classes e para coordenar as operações é usado algum modelo de controle .

11.3.2 Pipelining orientado a funçõesAs transformações processam entradas e produzem saídas, com os dados

fluindo de uma função para outra, transformados ao se moverem em seqüência. A implementação é feita a cada transformação. São convertidos em dados de saída através dessas transações.

Temos algumas vantagens com o uso dessa arquitetura: reuso de transformações, arquitetura intuitiva, fácil implementação, novas transformações na

10

maior parte de forma direta. Mas temos um problema, é necessário um formato comum pare que os dados possa ser reconhecido por todas as transformações.11.4 Modelos de controle

Tem como finalidade controlar subsistemas para que seus serviços 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 próprio nome já diz, o controle é feito de forma centralizada com um subsistema responsável pelo gerenciamento e execução 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 decisões são geradas de maneira externa e pode assumir uma gama de valores, o que gera e depende uma interação com o usuário e é bastante usado também em sistemas de inteligência artificial.11.5 Arquitetura de referencia

Serve como uma referencia para comparar conceitos de domínio ou comparar possíveis arquiteturas. Na verdade serve como um roteiro de implementações fornecendo uma base na qual os sistemas podem ser avaliados e comparados seguindo os padrões OSI ou CASE.

Capitulo 12 – Arquitetura de sistemas distribuídos

No sistema distribuído as aplicações são distribuídas e processadas por vários computadores e não em apenas uma maquina.

Temos algumas vantagens ao usar sistemas distribuídos: compartilhamento de recursos de software e hardware,uso de arquiteturas de hardware e software de diferente fabricantes, vários processos podem operar em computadores diferentes, com a duplicação da informação o sistema se torna tolerante a algumas falhas de hardware e software, facilidade de adição 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 distribuídos são mais complexos, podem ser acessados por vários computadores diferentes, podendo sofrer interceptação na rede, defeito de uma maquina pode passar pra outra e dificultar a identificação do problema, a depender do trafego da rede (lan, wan, man) podemos ter um desempenho imprevisível podendo variar de forma imprevisível.

Os sistemas distribuídos possuem dois tipos de arquiteturas: 1. cliente-servidor. O servidor disponibiliza os serviços e estes são usados

pelos clientes, neste modelo clientes e servidores são tratados de formas distintas.

2. Arquiteturas de objetos distribuídos. Não a diferença entre cliente e servidor, todos interagem independente de sua localização e de sua importância.

12.1 Arquitetura de multiprocessadores

Nessa arquitetura os processos podem ser executados em vários processadores, aumentando assim o desempenho e a capacidade de recuperação do sistema, esse sistema é muito comum em sistemas de processamento de grande

11

porte e em tempo real.12.2 Arquitetura cliente-servidor

Como já vimos no capitulo anterior, basicamente é um conjunto de serviços fornecidos pelos servidores e acessados pelos clientes, que precisa apenas saber os serviços disponíveis.

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 são realizados no servidor e os resultados apresentado na tela do cliente.

Modelo cliente-gordo: o servidor apenas gerencia os dados, o cliente executa toda aplicação e interação 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 disponível e a apresentação ao cliente, porem o gerenciamento do sistema se torna mais complexo e quando há alteração no software, é necessário 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 três camadas, sendo necessário as vezes estender este modelo para uma variante com varias camadas.12.3 Arquiteturas de objetos distribuídos

Nesse modelo os clientes recebem serviços apenas dos servidores e nunca de outros clientes e os servidores podem ser clientes de outros servidores para receber serviços. Os componentes principais desse sistema são os objetos que fornecem uma interface para um conjunto de serviços, que por sua vez é chamado por outros objetos sem distinção lógica entre servidores e clientes.

Os objetos se comunicam através de um middleware( resquisitor de objetos), distribuído em vários computadores na rede, que fornece uma interface continua e transparente entre os objetos alem de um conjunto de serviços que permitem que objetos sejam removidos e adicionados do sistemas.12.3.1 CORBA

Os padrões CORBA abrangem em todos os aspectos os objetos definidos pela OMG( que define padrões para o desenvolvimento orientado a objetos), no qual podemos destacar quatro principais elementos desse padrão:

1. Modelo de objeto. Trata os objetos como um encapsulamento de serviços e atributos, com uma interface separada que define as operações publicas dos objetos e os seus atributos. Para um objeto usar os serviços oferecidos por outros objetos ele solicita uma através da interface IDL e cada objeto é identificado através de seu identificador de referencia, chamado de IOR.2. Requisitor de objetos. Cuida da comunicação entre os objetos, identifica os objetos que estão solicitando serviços e suas interfaces, sendo que os objetos não precisar saber a localização nem a implementação de outros objetos.

3. Conjunto de serviços. a probabilidade dos recursos serem solicitados por vários sistemas distribuídos.

4. Conjunto de componentes. Definição de interface para componentes horizontais( componentes de propósitos geral) e verticais( componentes específicos de um domínio de aplicação), que são usados por quem desenvolve aplicações distribuídas.

12

12.4 Computação interorganizacional distribuídaImplementada inicialmente em modelo organizacional por motivos de

interoperabilidade e seguranças. Geralmente tem vários servidores com distribuição de tarefas entre eles, pelo fato de estarem na mesma organização facilita a aplicação de padrões e operações locais.

12.4.1 Arquitetura ponto a pontoNo sistema ponto a ponto(p2p) os dados são descentralizados, não existe a

figura do cliente servidor. Os dados ficam distribuídos por vários computadores espalhados por uma grande rede, geralmente a internet, onde todo nó tem ciência do que o outro compartilhar e pode trocar dados simultaneamente com vários nós que disponibilizam os mesmos dados

12.4.2 Arquitetura de sistema orientado a serviçosCom a popularização da internet e a necessidade de acesso aos dados fora

da organização. Foi criado o web service tornando assim acessíveis programas e informações na internet.

CAPITULO 13 – Arquitetura de aplicações

Sistema de aplicações são criados para atender rotinas em comum em muitas organizações. Geral mente esses sistemas possuem arquiteturas similares, na verdade e um sistema genérico que pode ser adaptado e configurado para uma aplicação especifica.

13.1 Sistema de processamento de dadosSão sistemas de processamento(orientado a funções) que processam os

dados de entradas e saída em lotes, na forma de arquivo ou banco de dados sem intervenção do usuário durante este processo. Sistemas de processamento em lotes geralmente são usados quando as operações são 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 operações lógicas destes dados e a saída ao receber os dados já processados, gera as saída a serem gravadas no BD. 13.2 Sistemas de processamento de transações

O sistema de transações funciona com uma ponte entre o usuário e o BD. As operações de transações iteragem o tempo todo com o usuário e o banco de dados e só é gravada quando confirmada a consistência e a viabilidade dos dois lados. Como exemplo temos o caixa eletrônico, o usuário 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 transação for concluída e o valor a ser sacado for compatível menor ou igual ao saldo.

13.3 Sistemas de gerenciamento de informações e recursosControla o acesso a uma base de informações 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 informação e seus recursos.

13

Esse sistema é modelado em camadas de modo que a camada superior trabalha com a interface do usuário e a camada inferior com o banco de dados. A camada de comunicação do usuário registra as entradas e saídas da interface do usuário, que por sua vez interage com a camada de recuperação de informações que tem uma lógica para acesso e gravação no banco de dados.13.3 Sistemas de processamento de eventos

Os sistemas de eventos interagem com ambiente e interface de usuários, eventos estes imprevisíveis e o sistema só pode tomar uma decisão quando eles ocorrem. Temos vários exemplos destes eventos com: processadores de texto, editores de imagem, uso do mouse até exemplos mais complexo que ao invés de usar interface de usuário utiliza sensores e inteligência 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 representação de linguagem como saída. Temo como exemplo os compiladores que traduzem a linguagem de programação de alto nível 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 configurações

O gerenciamento de configurações é feito com uso de procedimento e padrões para gerenciar o sistema em desenvolvimento, é importante fazer esse gerenciamento porque o engenheiro pode ter dificuldade em saber quais mudanças foram incomporadas em que versão do sistema perdendo assim a rastreabilidade.

29.1 Planejamento de gerenciamento de configuraçõesDeve-se descrever os procedimentos e padrões usado para o gerenciamento.

Partindo do ponto do uso de um padrão de configuração, que pode ser adaptado para atender as restrições e requisitos de projetos específicos.

29.1.1 Identificação de item de configuraçãoUm software grande é criado por varias pessoas diferente e pode haver

milhares de códigos, scripts de teste etc. e podem ter nomes parecidos, para garantir a rastreabilidade é necessário um esquema de identificação consistente para todos itens no sistema de gerenciamento de configuração.

Durante o planejamento do gerenciamento você decide quais itens vão ser controlados. Normalmente por padrão projetos, programas, planos de projetos, massa de dados e testes e especificações, são itens de configuração, assim como todos os documentos que forem úteis para uma futura evolução do sistema.29.1.2 Banco de dados de configuração

Registra todas as informações importantes sobre os itens e as configurações de sistema. É usado também o banco de dados CM para auxiliar o impacto das mudanças no sistema e para gerar relatórios sobre o processo de CM para a gerência. O esquema do CM deve ser definido, os formulários para coletar para serem registrada e procedimentos para recuperação de informações e registro de projeto.

29.2 Gerenciamento de mudanças

14

Como tudo na vida os sistemas também tem sua vida útil e diante isso deve-se analisar as necessidade e a mudança de requisito organizacionais, o que significa que é necessário fazer mudanças no sistema.

Para que estas mudanças seja feita de maneira controlada você precisa adotar procedimentos de gerencia de mudanças com apoio de ferramentas. Tem que levar também em consideração o custo-benefício das mudanças, a viabilidade e a rastreabilidade dos componentes alterados.O primeiro processo de gerenciamento de configurações é fazer o CRF – change request form, que descreve as mudanças necessária no sistema. Eviado o CRF, ele deve ser registrado no banco de dados de configuração e a solicitação de mudança é então analisada para verificar se realmente é necessário realizar tal mudança.

Para mudanças realmente necessárias deve-se também avaliar os custos, o impacto dessa mudança no restante do sistema, envolvendo os componentes afetados pela mudança.

29.3 Gerenciamento de versões e releasesGerencia a manutenção da rastreabilidade e identificação das versões do

sistema, o gerente de versões idealiza procedimentos para que as versões do sistema sejam recuperadas quando solicitadas e que não 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 distribuídos pra implantação. O release é uma versão distribuída para os clientes e cada novo release deve incorporar funcionalidades novas ou ser planejado para hardware diferente.

29.3.1 Identificação de versões Em grandes sistemas existem centenas de componentes de software e para

criar uma versão especifica é necessário especificar as versões dos componentes que devem ser incluídas nesse sistema. Basicamente existem três técnicas para identificar versão de componentes: numeração de versões, onde o componente recebe um numero único de versão, identificação baseada em atributos, onde cada componente tem um nome do item de configuração associados por um grupo de atributos para cada versão e identificação orientada a mudanças, onde cada componente é denominada como na identificação anterior, porem também é associado com solicitações de mudanças.

29.3.2 Gerenciamento de releasesComo vimos anteriormente um release é uma versão do sistema distribuídos

para o clientes e os gerentes que devem decidir quando um release esta pronto pra ser liberado para os clientes, gerenciando o processo de criação e os meios de distribuição, documentado o release para garantir que ele possa ser recriado como foi distribuído originalmente caso haja necessidade.

A criação de release é um procedimento de criação de documentos e arquivos que devem conter todos os componentes do sistema, todos arquivos de dados associados e o código executável dos programas devem ser identificados e coletados. E todos manuais devem ser distribuído de todas as formas possíveis para se tornar acessível aos usuários e sua limitações. Após todo este procedimento o release já pode ser encaminhado para distribuição.

15

29.4 Construção de sistemasÉ um processo de compilação que faz a ligação de componentes de software

em um programa que executa uma configuração definida. Alguma ferramentas de gerenciamento de configuração ou de ambiente de programação podem ser usadas pra automatizar processo de construção de sistemas. Um script de construção é escrito pela CM com dependências bem definidas entre os componentes de sistemas, o script define as ferramentas para compilar e ligar os componentes e as ferramentas de construção de sistemas interpretam o script e chamam outros programas.29.5 Ferramentas CASE para gerenciamento de configurações

O uso de uma ferramenta CASE como apoio é de extrema importância para o gerenciamento de configuração, podendo ser combinadas para criar uma área de trabalho e apoiar as atividades de CM. No mercado temos diversas ferramentas, alguma inclusive de código aberto e outras com sistemas mais abrangentes integrados.29.5.1 Apoio para gerenciamento de mudanças

As tarefas são divididas e cada pessoa fica responsável por alguma atividade, quando completadas passam os itens de configuração e os formulários para os outros. Nesse modelo os documentos certos são direcionados para pessoa certa a todo momento.

16

3.1 PROGRAMAÇÃO PARA WEB II

3.1.1 Comparação de frameworks

Zend Framework: é de uma empresa em que os fundadores são

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 aplicações e

conta com grande numero de colaboradores, tendo uma documentação bem

completa e com uma vasta biblioteca.

CodeIgniter: é um framework de fácil desenvolvimento e muito

focado na questão do desempenho, traz com ele um MVC e algumas ferramentas

úteis, porem não trabalha muito com outras tecnologias, como exemplo de não ter

ferramentas para Java script e não trabalhar com OMR.

Symfony: é um dos frameworks mais antigos do mercado, trabalha

com geradores de códigos, com o YAML para especificações, configurações,

linguagem simples de marcação, alem de possuir uma grande quantidade de

funcionalidades e uma forte comunidade.

17

3.1.2 Relacione custo de frameworks

O uso de frameworks para desenvolvimento de aplicações web é praticamente imprescindível nos dias atuais no desenvolvimento de sistemas voltados pra internet e intranet( aplicações web).

Existem vários benefícios em adotar o uso de frameworks dentre os quais podemos destaca: ganho de produtividade, redução de erros, maior nível de abstração, integração e compatibilidade entre aplicações, alem de contar com apoio e suporte de comunidades.

3.1.3 Programação Java Web – plataforma de desenvolvimento

No mercado existem diversas IDEs que você pode utilizar para

desenvolver sistemas web em Java, tendo como diferença básica a integração dos

recursos e a facilidade de uso. Algumas dessa IDEs são gratuitas (opensource) e

outra pagas.

Primeiramente vamos ver algumas gratuitas:

Netbeans. Ela é bastante interessante e tem um ponto forte por ser

mantida pela própria 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 gráfica, 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 código e uma forte integração com padrões de projeto,

ferramentas Case, UML etc.

3.2 PROJETO ORIENTADO A OBJETOS

Para o desenvolvimento do sistema China Telecom, nós 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

18

desenvolvimento de grande aplicações, alem de possuir muitos recursos em sua

biblioteca como: ferramentas para WebService, formulários com validação php,

conexão com vários BD e muito mais. É um framework orientado a objetos e já vem

em MVC e a documentação é extensa e fácil de usar.

19

CONCLUSÃO

Este trabalho também me proporcionou um grande aprendizado e

aprimorou os conhecimentos adquiridos durante este semestre e possibilitou ainda

aliar o conhecimento teórico com a pratica, atuando assim com um profissional da

área .

20

REFERÊNCIAS

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 Edição. São Paulo: Pearson Addison Wesley, 2007."

http://lpriori.org/artigo/COMPARATIVO%20DE%20FRAMEWORK%20PHP.pdf

21