SUMRIO

INTRODUO 3

OBJETIVO

DESENVOLVIMENTO 5

3.1

ENGENHARIA E PROJETO DE SOFTWARE 5

3.2

PROGRAMAO PARA WEB II 19

3.2.1

Comparao de frameworks

3.2.2

Relacione custo de frameworks20

3.2.3

Java Hivernate

3.3

19

21

PROJETO ORIENTADO A OBJETOS

CONCLUSO

24

REFERNCIAS

25

21

OBS: Clique com o boto direito sobre o sumario, e selecione atualizar campo.
(Em caso de voc fazer alteraes).
E se perguntar clique atualizar somente numero das paginas.

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). Alem de
Primeiramente devemos entender o que PMBKO, um guia
Project Management Body of Knowledge ou simplesmente Guia PMBOK. Um
conjunto de prticas na gesto de projetos organizado pelo instituto PMI e
considerado a base do conhecimento sobre gesto de projetos por profissionais da
rea.
O livro Engenharia Software - Ian Sommerville 8 Edio um ramo
da engenharia com foco no desenvolvimento de softwares dentro de curtos, prazos
adequados e alta qualidade. Software abstrato, no h limitaes fsicas. Essa
falta de limitaes pode torn-lo extremamente complexo e de difcil compreenso.
Com isso podemos seguir com o contedo a seguir onde esta uma
resenha do PMBOK e do livro Engenharia de Software, de Ian Sommerville. Assim
poderemos entender porque a empresa decidiu contratar do que ela mesmo
desenvolver o software necessrio.

2 OBJETIVO
Com o intuito de elaborar este trabalho para a UNOPAR na EAD
(Ensino a Distncia) e os professores do 5 Semestre de 2015 para o Curso Superior
de Tecnologia em Anlise e Desenvolvimento de Sistemas. O

Aluno devera

aprofundar seus conhecimentos adquiridos ate o presente momento, e tambm

pesquisar um pouco alem para concluso do mesmo.
Tendo o eixo temtico sobre o " China Telecom" para compreender o
motivo da contratao de uma empresa de renome do que ela mesmo o fazer.
Assim, o aluno far suas pesquisas, (leitura dos Livros) para com o
trabalho e abortar os pontos mais importantes: Resenha, Analise, conhecimento,
Riscos, Escopo e Aquisies.

3 DESENVOLVIMENTO
O PMBOK Guide no uma metodologia, pois no distingue os
diferentes tipos de projeto (certamente gerenciar projetos administrativos
totalmente diferente de gerenciar projetos de construo pesada).
No utiliza peculiaridades de linguagem que respeitem a cultura de
diferentes tipos de empresas e no apresenta modelos especficos de documentos a
serem preenchidos.
Resumidamente podemos chamar de manual que descreve o
universo de conhecimentos para o Gerenciamento de Projetos. Transformou-se em
um padro fonte de inspirao para quase todas as metodologias existentes.
3.1 ENGENHARIA E PROJETO DE SOFTWARE
Vamos

entender

melhor

sobre

engenharia

projetos

de

desenvolvimento de um software. Para isso vamos ver o guia Project Management

Body of Knowledge ou simplesmente Guia PMBOK.
O Guia PMBOK um conjunto de prticas na gesto de projetos
organizados pelo instituto PMI e considerado a base do conhecimento sobre
gesto de projetos por profissionais da rea.
Devemos ter cuidado no escopo do projeto, mantendo foco no
projeto que foi passado. Para que assim no ocorra erros no projeto, analisando o
que ser feito, como vai funcionar, qual o tipo de usurio, deve-se verificar as
documentaes, preocupando-se em no acrescentar nada alem do que o projeto
esta pedindo.
Algumas expresses:
"Metodologia: Um sistema de prticas, tcnicas, procedimentos e
regras usado pelas pessoas que trabalham em uma disciplina."
"Metodologia de gerenciamento de projetos define um processo, que
auxilia uma equipe de gerenciamento de projetos no desenvolvimento e controle das
mudanas do plano de gerenciamento do projeto".
Esta expresso esta constantemente mencionada nos processos de
Integrao (captulo 4), cada organizao poder ter um prprio processo.

O PMBOK torna um projeto melhor estruturado e atende as

demandas de forma eficiente, tendo um conjunto de praticas na construo de um
software.
Riscos: O risco aqui de um projeto de conjuntos de condies
onde pode ocorrer em forma de oportunidades negativas ou positivas.
Escopo: O gerenciamento do escopo do projeto responsvel por
realizar o projeto com sucesso, tendo um planejamento criado de um processo plano
de gerenciamento de escopo.
.Aplicaes de conhecimento, habilidades, ferramentas e suas
tcnicas nas atividades de um projeto com finalidade de alcanar um objetivo
somente atingido atravs do uso de processos e fases.
Agora supondo que a empresa china telecom optasse em
desenvolvimento prprio, vamos ler uma resenha do livro Engenharia de Software, de
Ian Sommerville: Temos ento os Capitulos 11, 12, 13 e 29.

Capitulo 11 (Projeto de Arquitetura).

O projeto de arquitetura primeiro estagio 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 criticas dentro de subsistemas e usar componentes de alta granularidade
em detrimento dos de baixa granularidade para reduzir a comunicao entre eles.
Se a facilidade de manuteno for um requisito crtico, a arquitetura
de sistemas deve ser projetada usando componentes de baixa granularidade e auto
contidos que possam ser prontamente mudados.
Um projeto de subsistemas decomposio abstrata de um sistema
de componentes em alta granularidade. Os diagramas de blocos so usados para
representar um projeto de subsistemas.
Esses diagramas de blocos so bons para comunicao entre
stakeholders e para o planejamento do projeto pois no esto abarrotados de
detalhes, j para a arquitetura no so to bons, pois no mostram relacionamento
entre os componentes do sistema.
Um modelo esttico de estrutura que mostra os subsistemas ou
componentes desenvolvidos como unidades separadas.
Um modelo dinmico de processo que mostra como o sistema esta
organizado em processos em tempo de execuo.
A organizao de um sistema reflete a estratgia bsica usada para
estrutur-lo. Voc precisa tomar decises sobre o modelo geral organizacional de
um sistema com antecedncia no processo de projeto de arquitetura. A organizao
pode refletir diretamente na estrutura do subsistema.
Em um modelo de arquitetura cliente servidor um modelo em que

o sistema organizado como um conjunto de servios e servidores e clientes

associados que acessam e usam os servios. Os clientes talvez precisem saber os
nomes dos servidores disponveis e os servios que eles fornecem.
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 apia 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.
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 seqencialmente.
Cada etapa implementada como uma transformao.
Os dados de entrada fluem atravs dessas transaes ate serem
convertidos em dados se sada.
Vantagens: Apoiar o reuso de transformaes.
Ele intuitiva, pois muitas pessoas pensam em termos de
processamento de entrada e sada.

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 seqencialmente 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 seqenciais.
O modelo gerenciados, aplicados em modelos concorrentes.
Sistema concorrente projetado como um gerenciador de sistema e controla o inicio,
a parada e a coordenao de outros processos do sistema.
As arquiteturas de referencia no so geralmente consideradas um
roteiro de implementaes. Em vez disso, sua principal funo ser um meio de
discusso de arquiteturas de domnio especifico e de comparao de sistemas
diferentes em um domnio.
Uma proposta de modelo de referencia um modelo para ambientes
CASE que identifica cinco conjuntos de servios que um ambiente CASE deve
fornecer. Ele deve tambm fornecer recursos de plug-in para ferramentas CASE
individuais que usam esses servios.
A finalidade dessa arquitetura de referencia ser um meio de
classificao e comparao de ferramentas e ambientes CASE integrados.

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

10

um processador ou com um cluster de processadores podem ter algumas

desvantagens como: Complexidade, Proteo, Gerenciamento, Imprevisibilidade e
Defeitos que em uma maquina podem se propagar a outra maquinas com
conseqncias 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, intra-organizacional.
Arquitetura de multiprocessadores
O multiprocessador So processos que podem ser executados separados.
Esse modelo 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

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

11

os servios devem ser fornecidos.

uma arquitetura de sistema aberto que permite que novos recursos sejam
adicionados.
Uma arquitetura de objetos distribudos pode ser usada como um modelo
lgico, que permite estruturar e organizar o sistema.
Uma arquitetura de objetos distribudos em lugar de uma arquitetura clienteservidor 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
cliente-servidor.

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.

12

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 referencia de objeto
interoperavel. 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 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 padres Corba incluem definies de interface para uma grande variedade
de componentes horizontais e verticais. Os componentes verticais so componentes
especficos de um domnio de aplicao. Os componentes horizontais so
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 pratico.

13

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.
Todos estes padres baseados em XML.

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.

14

Eles tratam de uma grande variedade de funes administrativas, como folha

de pagamento, cobrana, contabilidade e publicidade. Essas aplicaes enfocam os
dados. Os bancos de dados so geralmente maiores que os sistemas de
informaes (SI).
Os sistemas de processamento de dados selecionam os dados de registros
de entrada e, dependendo do valor dos campos nos registros, tomam algumas
aes especificadas no programa. Eles podem, ento, enviar o resultado novamente
do processamento ao banco de dados e formatar 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 seqncia de
operaes tratada como uma unidade simples.
Todas as operaes tem que ser realizadas antes que as mudanas tornemse permanentes no banco de dados. Os sistemas de processamento de transaes
so geralmente sistemas interativos nos quais os usurios enviam solicitaes
assncronas de servio.
Primeiro um usurio faz uma solicitao para o sistema atravs de um
componente de processamento de entrada/sada. A solicitao processada por
alguma lgica especifica da aplicao.
Uma transao criada e passada para um gerenciador de transaes, que
em geral incorporado ao sistema de gerenciamento de banco de dados. Depois que
o

gerenciador

de

transaes

assegurar

que

transao

foi

concluda

adequadamente, ele sinalizara para a aplicao que o processamento foi finalizado.

A estrutura entrada-processo-sada se aplica aos muitos sistemas de
processamento de transaes. Alguns desses sistemas so verses interativas de
sistemas de processamento de lotes.
Em sistemas como os de contabilidade de clientes de um banco, pode haver
diferentes maneiras de interagir com o sistema. Muitos clientes interagiro por meio
de caixas eletrnicos, mas uma equipe do banco usara terminais de mesa para
acessar o sistema. Pode haver vrios tipos de caixas eletrnicos e terminais de
mesa, e alguns clientes e a equipe do banco podem acessar os dados de contas por
meio de navegadores WEB.

15

Os sistemas de processamento de linguagens aceitam uma linguagem natural

ou artificial como entrada e geram alguma outra representao dessa linguagem
como sada.
Em engenharia de software, os sistemas de processamento de linguagens
mais amplamente usados so os compiladores que traduzem uma linguagem
artificial de programao de alto nvel em cdigo de maquina. Mais outros sistemas
de processamento de linguagens traduzem uma descrio de dados XML em
comandos para consultar um banco de dados e sistemas de processamento de
linguagem natural que tentam traduzir uma linguagem em outra.
Os tradutores em um sistema de processamento de linguagens tem 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.

Capitulo 29 (Gerenciamento de Configuraes).

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

16

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.
Planos de projetos, especificaes, projetos, programas, e massa de dados
de teste so normalmente mantidos como itens de configurao para o processo de
planejamento de gerenciamento de configurao, voc decide exatamente quais
itens sero controlados.
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 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.

17

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

Para criar uma verso especifica de um sistema, voc precisa especificar as

verses dos componentes de sistema que devem ser includas nele. Voc no pode
usar o nome do item de configurao para identificar a verso, porque ele pode ter
muitas verses para cada item de configurao identificado.
Uma das trs tcnicas bsicas para identificao da verso de componentes
Numerao de verses. O componente recebe um numero 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."

18

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.
Conseqentemente, 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.

3.2 PROGRAMAO PARA WEB II

Frameworks, sejam elas escritas em PHP ou em qualquer outra
linguagem, oferecem ao programador um conjunto de cdigos prontos que permitem
realizar as tarefas mais bsicas no desenvolvimento de um aplicativo. Por oferecer
essa estrutura bsica, os frameworks tornam o desenvolvimento mais rpido e
reduzem o volume de cdigo repetitivo escrito pelo programador.
Os frameworks tambm ajudam aos programadores iniciantes a criar
aplicativos mais estveis, mesmo que eles ainda no dominem completamente a
linguagem de programao e todas as outras tecnologias necessrias para fazer o
aplicativo funcionar.

19

3.2.1 Comparao de frameworks

Zend Framework o framework mais famoso do momento. E
tambm no pra menos, pois a criadora do framework (a Zend) a mesma
empresa que mantm o desenvolvimento do PHP. rico em funcionalidades e
tambm o mais rpido. Infelizmente, todo esse poder faz com que esta ferramenta
torne-se muito grande, mas no funciona com o PHP 4.
um framework para quem deseja construir grandes aplicaes.
Alm de possuir uma documentao extensa e diversas publicaes relacionadas,
existem diversos programadores srios que testam exaustivamente todos os cdigos
que so desenvolvidos antes de liberar para produo.
Symfony um dos frameworks mais poderosos e muito bem
dividido. Todas as tarefas so modulares e o framework utiliza diferentes camadas
para manejar os dados. bastante til para projetos com necessidades de grandes
funcionalidades. Contudo, de todas as opes citadas, o mais lento de todos.

3.2.2 Relacione custo de frameworks

Melhora a modularizao encapsula mento 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.

20

esperado que o framework funcione como uma constituio, definindo, na

seara da regulao, os princpios gerais para o desenvolvimento de padres
contbeis e o contedo informacional dos relatrios, na seara dos usurios da
informao. Para alcanar esse propsito, o framework deve ser constante por longo
perodo e deve formular as regras gerais que constituem o cerne dos relatrios.
O framework tem como principal funo ser suporte e guia para a adoo e o
aprimoramento da informao de custos no setor pblico, incluindo novas definies
ainda no explicitadas que venham a ser demandadas pelos usurios. J no
momento do uso, a estrutura servir de apoio aos usurios (rgos de controle,
gestores, sociedade em geral etc.) das informaes de custos na interpretao de
informaes nelas contidas, preparadas em conformidade com os critrios bsicos
definidos pelo patrocinador do sistema (no caso o Ministrio da Fazenda).
Duas questes merecem destaque em termos de implantao da estrutura: o
aperfeioamento contnuo e a replicao do sistema (rollout). de se esperar que o
framework seja revisado num prazo razoavelmente curto (digamos, cinco anos) com
base na experincia decorrente de sua utilizao. Como o efeito do framework
efetivo apenas aps longo perodo de adoo da mesma (Christensen, 2009), as
contnuas revises podem levar a uma reduo da velocidade de institucionalizao
do sistema.

3.2.3 Java Hivernate

O Hibernate um framework open source de mapeamento objeto/relacional
desenvolvido em Java, ou seja, ele transforma objetos definidos pelo desenvolvedor
em dados tabulares de uma base de dados, portanto com ele o programador se livra
de escrever uma grande quantidade de cdigo de acesso ao banco de dados e de
SQL. Se comparado com a codificao manual e SQL, o Hibernate capaz de
diminuir 95% das tarefas relacionadas a persistncia.
A utilizao de cdigo SQL dentro de uma aplicao agrava o problema da
independncia de plataforma de banco de dados e complica, em muito, o trabalho
de mapeamento entre classes e banco de dados relacional. O Hibernate abstrai o
cdigo SQL da nossa aplicao e permite escolher o tipo de banco de dados
enquanto o programa est rodando, permitindo mudar sua base sem alterar nada no
seu cdigo Java.
Alm disso, ele permite criar suas tabelas do banco de dados de um jeito bem
simples, no se fazendo necessrio todo um design de tabelas antes de desenvolver

21

seu projeto que pode ser muito bem utilizado em projetos pequenos.
O Hibernate no apresenta apenas a funo de realizar o mapeamento objeto
relacional. Tambm disponibiliza um poderoso mecanismo de consulta de dados,
permitindo uma reduo considervel no tempo de desenvolvimento da aplicao.
3.3 PROJETO ORIENTADO A OBJETOS
Sendo assim para o problema da China Telecon, a melhor soluo para esta
empresa seria realmente adotar um software de uma empresa especializada e com
um bom suporte. Mas nos baseando na hiptese de a empresa querer desenvolver
seu prprio software, para reduzir os custos seria necessrio tambm reduzir o
tempo de desenvolvimento do mesmo e manter a qualidade e produtividade no
desenvolvimento.
Contando 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 a 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.
O MVC tem como principal objetivo: separar dados ou lgicos de negcios
(Model) da interface do usurio (View) e o fluxo da aplicao (Controller), a idia
permitir que uma mensagem da lgica de negcios possa ser acessada e
visualizada atravs de vrias interfaces. Na arquitetura MVC, lgica de negcios,
ou seja, nosso Model no sabe quantas nem quais as interfaces com o usurio esta

22

exibindo seu estado, a view no se importa de onde esta recebendo os dados, mas
ela tem que garantir que sua aparncia reflita o estado do modelo, ou seja, sempre
que os estados do modelo mudam, o modelo notifica as view para que as mesmas
atualizem-se.
MVC um conceito (paradigma) de desenvolvimento e design que tenta
separar uma aplicao em trs partes distintas. Uma parte, a Model, esta
relacionada ao trabalho atual que a aplicao administra outra parte a View esta
relacionada a exibir os dados ou informaes dessa uma aplicao e a terceira
parte, Controller, em coordenar os dois anteriores exibindo a interface correta ou
executando algum trabalho que a aplicao precisa completar. (GONALVES, 2007,
p. 141).
Embora o MVC s contenha trs camadas h outra camada fundamental para
o bom andamento da arquitetura, esta um mecanismo de eventos necessrio a
comunicao entre outros trs elementos, este elemento permite uma comunicao
assncrona que invocada quando algum evento interessante acontece, esta quarta
camada contm os beans de entidade onde se localizam os mtodos get e set das
classes
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 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.
Utilizando essa arquitetura, o tempo de desenvolvimento do software
diminuir sem perde a qualidade e sem aumento de custos. Framework Uma das

23

melhores opes seria o Hibernate como framework de persistncia de dados. O

Hibernate um framework para mapeamento objeto/relacional em Java, que abstrai
o cdigo SQL da aplicao, permitindo, entre outra coisas, modificar a base de
dados para outro SGBD (Sistema Gerenciador de Banco de Dados) sem modificar
uma linha de cdigo.

24

CONCLUSO
O maior problema...
Foi observado a necessidade...
Neste projeto "China Telecom" pode ...
Este trabalho tambm me proporcionou...
Aqui no tem jeito voc deve por com suas palavras.
s ler e reler o trabalho e falar algo aqui!

25

REFERNCIAS
BANCO DE DADOS. Disponvel em:
<https://intranet.ifs.ifsuldeminas.edu.br/~fatima.bueno/Banco%20de
%20Dados/Apostila%20Banco%20de%20Dados.pdf>. Acesso em: 08 Maio. 2015.
PHPPIT. Disponvel em: < http://www.phpit.com.br/artigos/frameworks-php-qual-e-omelhor-pra-voce.phpit>. Acesso em: 10 Maio. 2015.
SOMMERVILE, Ian. ENGENHARIA DE SOFTWARE. 8 Edio. So Paulo: Pearson
Addison Wesley, 2007."
SIELO - Frameworks. Disponvel em: <http://www.scielo.br/scielo.php?
script=sci_arttext&pid=S0034-76122011000500014>. Acesso em: 11 Outubro. 2015.
SEGURANA NO DESENVOLVIMENTO DE APLICAES. Disponvel em:
<http://www.cic.unb.br/~jhcf/MyBooks/cegsic/2009_2011/GSIC701_Seguranca_Dese
nvolvimento_Aplicacoes.pdf>. Acesso em: 09 Maio. 2015.
SEGURANA EM APLICAOES WEB. Disponvel em:
<http://www.cic.unb.br/~jhcf/MyBooks/cegsic/2009_2011/GSIC701_Seguranca_Dese
nvolvimento_Aplicacoes.pdf>. Acesso em: 10 Maio. 2015.

Obs: Sugiro voc pesquisar e colocar outras referencias

No usei anexos, mas sinta-se livre para colocar