SUMRIO

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

DESENVOLVIMENTO....................................................................................4

2.1

DESAFIO I RESENHA DAS AREAS DE CONHECIMENTO RISCO,

ESCOPO, FORNECEDORES E PARTES INTERESSADAS DO PMBOK.................4

2.1.1

Riscos.............................................................................................................4

2.1.2

Escopo............................................................................................................5

2.1.3

Fornecedores..................................................................................................6

2.1.4

Partes Interessadas........................................................................................7

2.2

DESAFIO II ENGENHARIA DE SOFTWARE, RESENHAS DOS

CAPTULOS 11,12,13 E 29..........................................................................................9

2.2.1

PROJETO DE ARQUITETURA (CAP. 11).....................................................9

2.2.1.1 Decises de projeto de arquitetura (Cap. 11.1)..............................................9

2.2.1.2 Organizao de sistema (Cap. 11.2)............................................................10
2.2.1.2.1 O modelo Repositrio (Cap. 11.2.1).............................................................10
2.2.1.2.2 Modelo cliente-servidor (Cap. 11.2.2)...........................................................11
2.2.1.2.3 O modelo em camadas (Cap. 11.2.3)...........................................................11
2.2.1.3 Estilos de decomposio modular (Cap. 11.3).............................................12
2.2.1.3.1 Decomposio orientada a objetos (Cap. 11.3.1)........................................12
2.2.1.3.2 Pipeline orientado a funes (Cap. 11.3.2)..................................................13
2.2.1.4 Modelos de controle (Cap. 11.4)...................................................................13
2.2.1.4.1 Controle centralizado (Cap. 11.4.1)..............................................................13
2.2.1.4.2 Sistemas orientados a eventos (Cap. 14.4.2)..............................................14
2.2.1.5 Arquiteturas de referncia (Cap. 11.5).........................................................15
2.2.2

ARQUITETURA DE SISTEMAS DISTRIBUIDOS (Cap. 12).......................16

2.2.2.1 Arquitetura de multiprocessadores (Cap. 12.1)............................................16

2.2.2.2 Arquiteturas cliente servidor (Cap. 12.2)......................................................17
2.2.2.3 Arquiteturas de objetos distribudos (Cap. 12.3)..........................................19
2.2.2.3.1 CORBA (Cap. 12.3.1)...................................................................................20
2.2.2.4 Computao Interorganizacional distribuda (Cap. 12.4).............................21
2.2.2.4.1 Arquiteturas Ponto a ponto (Cap. 12.4.1).....................................................21
2.2.2.4.2 Arquitetura de sistema orientada a servios (Cap. 12.4.2)..........................21
2.2.3

ARQUITETURA DE APLICAES (Cap.13)..............................................23

2.2.3.1 Sistemas de processamento de dados (Cap. 13.1).....................................23

2.2.3.2 Sistemas de processamento de transaes (Cap. 13.2).............................24
2.2.3.2.1 Sistemas de gerenciamento de informaes e recursos (Cap. 13.2.1).......24
2.2.3.3 Sistema de processamento de eventos (Cap. 13.3)....................................25
2.2.3.4 Sistemas de processamento de linguagem (Cap. 13.4)..............................26
2.2.4

GERENCIAMENTO DE CONFIGURAO (Cap 29).................................26

2.2.4.1 Planejamento de gerenciamento de configurao (Cap. 29.1)....................26

2.2.4.1.1 Identificao de item de configurao (Cap. 29.1.1)....................................26
2.2.4.1.2 Banco de dados (Cap. 29.1.2)......................................................................26
2.2.4.2 Gerenciamento de mudanas (Cap. 29.2)...................................................27
2.2.4.3 Gerenciamento de verses e releases (Cap. 29.3)......................................27
2.2.4.3.1 Identificao de verso (Cap.29.3.1)............................................................27
2.2.4.3.2 Gerenciamento de releases (Cap. 29.3.2)...................................................28
2.2.4.4 Construo de sistemas (Cap. 29.4)............................................................28
2.2.4.5 Ferramentas CASE para gerenciamento de configurao (Cap. 29.5).......28
2.2.4.5.1 Apoio para gerenciamento de mudanas (Cap. 29.5.2)..............................28
2.2.4.5.2 Apoio para gerenciamento de sistemas (Cap. 29.5.3).................................29
2.3

DESAFIO III FRAMEWORKS DE DESENVOLVIMENTO JAVA..............29

2.3.1

Pesquisa bibliogrfica sobre frameworks.....................................................29

2.3.1.1 Interface........................................................................................................29
2.3.1.2 Persistncia de dados..................................................................................31
2.3.2

Benefcios de uso de frameworks................................................................31

2.3.3

Plataforma de desenvolvimento JAVA Web.................................................31

2.4

DESAFIO IV ANLISE CHINA TELECOM...............................................32

CONCLUSO...............................................................................................33

REFERNCIAS...........................................................................................................34

1 INTRODUO
Em um ambiente de crescente demanda para o desenvolvimento de
software cresce tambm a responsabilidade por quem os fabrica, pensando nisso
aumentou a preocupao das empresas em estabelecer e seguir padres de
projetos

de

desenvolvimentos,

durante

transcorrer

deste

trabalho

apresentaremos alguns aspectos do gerenciamento de projetos baseados no guia

PMBOK, apresentaremos tambm o livro Engenharia de Software de Ian
Sommerville alm de fazermos um comparativo de utilizao de frameworks de
desenvolvimento java, por ltimo, apresentaremos uma soluo com base no estudo
de caso da empresa China telecom.

2 DESENVOLVIMENTO

2.1 DESAFIO I RESENHA DAS AREAS DE CONHECIMENTO RISCO, ESCOPO,

FORNECEDORES E PARTES INTERESSADAS DO PMBOK.

2.1.1 Riscos
A gerncia de riscos do projeto inclui os processos referentes ao
planejamento da gerncia de riscos, identificao, anlise, ao planejamento das
respostas e ao controle e monitorao dos riscos em um projeto. Esses processos
interagem entre si e com os processos das outras reas do conhecimento. Os
objetivos da gerncia de risco so aumentar a probabilidade de ocorrncia e os
impactos de eventos positivos e diminuir a probabilidade e os impactos dos eventos
adversos aos objetivos do projeto. Os processos da gerncia de risco so [PMBOK,
2000]:

Planejamento da gerncia de riscos: planejar as atividades de

gerncia de risco a serem realizadas para o projeto.

Identificao dos riscos: identificar os riscos que podem afetar o

projeto, documentando suas caractersticas.

Anlise qualitativa dos riscos: analisar qualitativamente os riscos,

priorizando seus efeitos no projeto.

Anlise quantitativa dos riscos: mensurar a probabilidade de

ocorrncia dos riscos e suas consequncias e estimar as
implicaes no projeto.

Planejamento da resposta aos riscos: gerar procedimentos e

tcnicas para avaliar oportunidades, objetivando mitigar as
ameaas no projeto.

Monitorao e controle dos riscos: monitorar os riscos residuais,

identificar novos riscos, executar os planos de mitigao de
riscos e avaliar sua efetividade durante todo o ciclo de vida do
projeto.

2.1.2 Escopo
O gerenciamento do escopo o processo de definir qual trabalho
necessrio e garantir que todo este trabalho, e apenas este trabalho, seja
executado. O escopo do projeto o trabalho que ser feito para entregar o produto
do projeto, e engloba o escopo do produto.
Segundo o PMI, o gerenciamento de escopo esta subdivididos nos
seguintes processos:

Iniciao: o reconhecimento formal da necessidade de um

novo projeto ou continuidade de um projeto j existente, para
atender uma determinada necessidade da organizao (novo
produto, exigncia legal, atualizao tecnolgica, necessidade
social, etc.). Sero utilizadas neste processo as descries do
produto, o plano estratgico da organizao, critrios de
seleo de projeto e informaes histricas pertinentes ao
trabalho a ser realizado. Desta forma, mtodos de seleo de
projeto e avaliao especializada podero gerar o Project
Charter

(Carta

do

Projeto),

documento

que

autoriza

formalmente o projeto, alm de identificar o gerente de

projeto, premissas e restries;

Planejamento do escopo: Utilizando-se as descries do

produto, Project Charter, premissas e restries, possvel
elaborar e documentar o trabalho do projeto, de forma a
produzir o produto do projeto. Ser feita uma anlise do
produto, bem como do custo/benefcio, identificao de
alternativas,

podendo

exigir

avaliao

especializada,

produzindo a declarao de escopo e plano de gerenciamento

de escopo;

Detalhamento do escopo: A partir dos subprodutos do projeto,

definidos

anteriormente,

possvel

subdividi-los

em

componentes menores e mais gerenciveis, melhorando a

preciso das estimativas de custo, tempo e recursos,
controlar o desempenho e atribuir responsabilidades. Nesta
fase ser criado o WBS (Work Breakdown Structure) ou EAP

(Estrutura Analtica de Projeto), um documento reutilizvel

entre

projetos

similares

que

decompe

os

principais

subprodutos do projeto em componentes menores, chegando

ao nvel de atividades;

Verificao do escopo: Formalizao do aceite do escopo do

projeto pelos Stakeholders, de forma a garantir que o trabalho
est sendo contemplado correta e satisfatoriamente. Nesta
fase importante tanto a exatido como a aceitao do
escopo. A documentao gerada anteriormente ser utilizada
para inspeo e aceitao formal;

Controle de mudanas do escopo: As mudanas devero ser

identificadas,

discutidas

combinadas,

gerenciadas de forma efetiva

devendo

ser

e com aprovao dos

Stakeholders. Devem ser utilizados sistemas de controle de

mudanas

de

escopo,

medies

de

desempenho

planejamento adicional, de forma a documentar as mudanas,

tomar aes corretivas e registras as lies aprendidas em
uma base histrica.
O escopo o corao do projeto, onde colocamos o objetivo do
servio ou produto proposto pelo projeto. Quanto maior os detalhes do escopo
menor o risco de o projeto ter um desvio. O Gerente do Projeto deve fazer um
monitoramento minucioso do escopo durante a execuo verificando assim se nada
est saindo do que foi planejado e gerenciando as mudanas do escopo aprovando
ou reprovando conforme a necessidade do projeto, para que se obtenha um
resultado positivo ao final do projeto.

2.1.3 Fornecedores
A gesto de fornecedores feita na rea de conhecimento referente
a gerenciamento de aquisies do projeto, captulo que trata dos processos
necessrios para comprar ou adquirir produtos, servios ou resultados externos
equipe do projeto. O gerenciamento de aquisies uma das reas de

conhecimento do Guia PMBOK frequentemente empregada no gerenciamento de

projetos, seja o projeto de pequeno, mdio ou grande porte. A prtica da
terceirizao, verificada de modo especial nas ltimas duas dcadas, tem, de uma
forma geral, tornado cada vez mais presente a figura do fornecedor como um
personagem importante para a realizao do projeto, seja este fornecedor de
recursos ou servios. Em muitos casos o fracasso de fornecedores de materiais,
equipamentos ou servios durante o andamento do projeto poder trazer impactos
significativos ao cumprimento do projeto, ou mesmo comprometer a sua realizao.
Para poder alcanar os objetivos do projeto, o gerente de projeto deve conhecer e
estar alinhado s boas prticas da gesto de aquisies.
O objetivo bsico do gerenciamento de aquisies em projetos
propiciar a construo e a manuteno de relaes comerciais slidas e equilibradas
entre cliente e fornecedor, de forma que o projeto possa ser finalizado a contento.
Segundo o Guia PMBOK, existem um total de 6 (seis) processos includos na rea
de conhecimentos do gerenciamento de aquisies em projetos, so eles:

Planejar compras e aquisies;

Planejar contrataes;

Solicitar respostas de fornecedores;

Selecionar fornecedores;

Administrao do contrato;

Encerramento do contrato.

Dentre os elementos presentes nestas prticas, merece destaque a

elaborao da documentao que detalhar o escopo do fornecimento (SOW) dos
produtos e servios a serem contratados. o momento em que todo o know-how da
equipe de projetos deve ser explorado, j que os eventuais erros ou omisses que
possam estar presentes no SOW certamente se tornaro riscos de ameaa para o
projeto e riscos de oportunidade para o fornecedor.
2.1.4 Partes Interessadas
As partes interessadas so compostas por todas as entidades que
possuem algum interesse, sejam estas internas ou externas, bem como toda a
equipe de gerenciamento de projetos. Cabe ao gerente de projetos garantir que, na

iniciao do projeto, o maior nmero possvel de partes interessadas seja

identificado, com o objetivo de garantir que os requisitos do projeto e as expectativas
das partes interessadas sejam devidamente identificados e registrados. Alm disto,
cabe ao gerente de projetos assegurar o correto gerenciamento da influncia das
partes interessadas, visando assegurar o sucesso do projeto.
As partes interessadas podem influenciar os objetivos do projeto de
maneira negativa ou positiva, bem como podem entender que os objetivos do projeto
afetam, de maneira negativa ou positiva, os seus interesses.
Basicamente, pode-se definir que as partes interessadas de um
projeto so compostas por:

Patrocinador: pessoa ou Grupo que fornece suporte e

recursos, financeiros ou no, para o projeto. O patrocinador
responsvel pelo sucesso do projeto. O patrocinador promove
o projeto desde a concepo inicial at seu encerramento,
serve como porta-voz para o Board da organizao.
responsabilidade do patrocinador conduzir o projeto atravs
dos processos iniciais at a autorizao formal para execuo
do

projeto.

patrocinador

desempenha

um

papel

fundamental na definio do escopo inicial e do termo de

abertura do projeto.

Clientes e Usurios: os clientes so pessoas ou organizaes

que iro aprovar e gerenciar o resultado, produto ou servio
criado pelo projeto. Os usurios so definidos como
organizaes ou pessoas que usaro o produto, resultado ou
servio criado pelo projeto.

Fornecedores: Empresas externas, terceiros, que prestam o

fornecimento de servios ou insumos necessrios para a
execuo do projeto.

Parceiros de Negcio: empresas externas que possuem uma

relao que vai alm da relao de um fornecedor. Possuem
uma importncia maior, para a execuo do projeto, do que
os simples fornecedores.

Grupos

Organizacionais:

so

definidos

como

partes

interessadas internas organizao, que podem ser afetadas

pelas

atividades

do

projeto.

Resumidamente,

so

os

departamentos internos da organizao.

Gerentes Funcionais: so profissionais que desempenham a

funo gerencial dentro da organizao. Este profissional
pode fornecer consultoria sobre o assunto de especialidade
atribuda a ele.

Outras Partes Interessadas: so outras partes interessadas

que podem ter um interesse no projeto, por exemplo:
instituies financeiras, sindicatos, rgos reguladores entre
outros.

2.2 DESAFIO II ENGENHARIA DE SOFTWARE, RESENHAS DOS CAPTULOS

11,12,13 E 29.

2.2.1 PROJETO DE ARQUITETURA (CAP. 11)

Objetivo de apresentao dos conceitos de arquitetura de software e
projeto de arquitetura.
2.2.1.1 Decises de projeto de arquitetura (Cap. 11.1)
Capitulo que trata da dificuldade enfrentada pelo arquiteto de
softwares na definio de uma arquitetura, apresenta de uma forma geral os estilos
de arquitetura conhecidos como as estruturas cliente-servidor e camadas e destaca
que o verdadeiro teste da arquitetura recai sob o quo bem ela atende os requisitos
funcionais e no funcionais. Ao concluir as decises do projeto de arquitetura,
gerado um documento de projeto de arquitetura que pode incluir vrias
representaes grficas do sistema juntamente com texto descritivo aonde dever
conter informaes de como os subsistemas esto estruturados, a abordagem
adotada e como cada subsistema est estruturado em mdulos. Os modelos de
arquitetura que podem ser desenvolvidos podem incluir:

Um modelo esttico de estrutura de mostra os subsistemas

10

ou componentes desenvolvidos como unidades separadas.

Um modelo dinmico de processo de mostra como o sistema

est organizado em processos em tempo de execuo.

Um modelo de interface de define os servios oferecidos por

cada subsistema por meio de suas interfaces pblicas.

Modelos

de

relacionamentos,

relacionamentos

que

tal

de

como

fluxo

mostram
dados,

entre

os
os

subsistemas.

Um modelo de distribuio que mostra como os subsistemas

podem ser distribudos pelos computadores.

2.2.1.2 Organizao de sistema (Cap. 11.2)

Captulo que trata dos modelos de organizao dos sistemas e
apresenta trs estilos organizacionais amplamente usados, estes estilos podem ser
usados separadamente ou juntos.
2.2.1.2.1 O modelo Repositrio (Cap. 11.2.1)
Sistemas cujas partes precisam trocar dados com frequncia aonde
dados compartilhados podem ser mantidos em um banco de dados central e
acessados por todos os subsistemas, cada subsistema mantm seu prprio banco
de dados e passa dados para outros subsistemas, podem usar uma abstrao de
repositrio centralizado possui Implementao distribuda.

11

2.2.1.2.2 Modelo cliente-servidor (Cap. 11.2.2)

Modelo subdividido em trs principais componentes, um conjunto de
servidores onde os servios so disponibilizados, conjunto de clientes que solicita os
servios aos servidores e uma estrutura de rede que permite a comunicao entre
os servidores e os clientes. A figura abaixo demostra um sistema multiusurio que
oferece um acervo de filmes e fotografias. A principal vantagem deste modelo a
caracterstica de ser uma arquitetura distribuda, que permite a separao do
processamento em muitos processadores, alm disso, quando houver necessidade
de se adicionar um novo servidor e integr-lo ao restante isso pode ser feito
facilmente e de maneira transparente s outras partes do sistema.

12

2.2.1.2.3 O modelo em camadas (Cap. 11.2.3)

Modelo arquitetural que organiza o sistema em camadas onde cada
camada fornece um conjunto de servios, essa abordagem apoia o desenvolvimento
incremental de sistemas, aonde a medida que a camada desenvolvida alguns
servios fornecidos por essa camada j podem ser disponibilizados, podemos dizer
tambm que esta arquitetura modificvel e portvel

2.2.1.3 Estilos de decomposio modular (Cap. 11.3)

Captulo que aborda os modelos de decomposio dos subsistemas
em mdulos, como no h uma distino rgida entre organizao do sistema e
decomposio modular os estilos apresentados no capitulo anterior podem ser
utilizados neste nvel tambm, apesar de no haver distino interessante pensar
que os mdulos normalmente so compostos de outros sistemas mais simples do
sistema.
Existem duas estratgias principais que podem ser usadas para
decompor um subsistema em mdulos:

Decomposio orientada a objetos Compem conjuntos de

objetos que se comunicam.

13

Pipelining orientado a funo Decomposio orientado a

funo aonde os mdulos aceitam dados de entrada e
transforma-os em dados de sada.

2.2.1.3.1 Decomposio orientada a objetos (Cap. 11.3.1)

Esta forma decomposio baseada na premissa que os dados e no
as funes so a parte mais importante do sistema. Este tipo de decomposio
interpreta um software como sendo uma quantidade de estruturas de dados isoladas
que formam no seu todo a estrutura base do sistema. No nvel arquitetural,
frequentemente empregado na construo de sistemas distribudos onde uma
implementao orientada a objetos no implica em uma arquitetura orientada a
objetos.
2.2.1.3.2 Pipeline orientado a funes (Cap. 11.3.2)
Modelo de decomposio onde as transformaes funcionais
processam suas entradas para produzir sadas. O estilo tambm pode ser chamado
de duto e filtro, suas principais vantagens so o apoio ao reuso de transformaes,
uma arquitetura intuitiva, de fcil evoluo e simples e ser implementada.
Um problema comum no estilo de arquitetura a necessidade de
utilizao de um formato comum para transferncia de dados que possa res
reconhecido por todas as transformaes.
No indicado para uso em sistemas interativos pela necessidade
de haver uma sequencia de dados a ser processada aonde as entradas baseadas
em eventos como cliques ou seleo de menus so difceis de serem traduzidas de
forma compatvel com o modelo pipelining.
2.2.1.4 Modelos de controle (Cap. 11.4)
Capitulo trata da forma que os subsistemas so controlados para
funcionar como um sistema de maneira que seus servios sejam entregues no lugar
certo e no tempo certo. Existem dois estilos genricos de controle que so usados:

Centralizado Um subsistema controla todo o sistema.

14

Baseado em eventos Cada subsistema autnomo para

responder a eventos esternos.

Modelos de controle so usados em conjunto com estilos de

estrutura.
2.2.1.4.1 Controle centralizado (Cap. 11.4.1)
Modelo de controle centralizado onde um subsistema designado
para controlar os demais, est incorporado em linguagens como C, Ada e Pascal e
dividem-se em duas formas de controle de acordo com a forma que os subsistemas
so executados. Sequencial, aonde o modelo executado conhecido como
chamada-retorno aonde o modelo inicia a execuo pelo topo e passa para os nveis
mais baixos da rvore (top-down) e paralelos, aplicado em sistemas concorrentes,
conhecido como modelo gerenciado, os processos so executados (ou podem ser
executados) paralelamente.
O processo controlador decide quando os processos devem ser
iniciados ou interrompidos, geralmente est em loop contnuo sempre verificando
mudanas de estado dos sensores por isso conhecido tambm por modelo eventoloop.
2.2.1.4.2 Sistemas orientados a eventos (Cap. 14.4.2)
Enquanto nos sistemas com controle centralizado as decises so
tomadas a partir de dados de variveis, nos sistemas orientados a eventos o que
determina as decises so os eventos gerados externamente aonde evento neste
contexto significa sinal binrio. Dois modelos so abordados pelo autor:

Modelos de broadcast Onde o evento transmitido a todos

os

subsistemas,

eficazes

na

integrao

de

sistemas

distribudos na rede.

Modelo orientado a interrupo Usado em sistemas que

trabalham em tempo real aonde um tratador de interrupes
trata os eventos.

15

2.2.1.5 Arquiteturas de referncia (Cap. 11.5)

Este captulo aborda os modelos arquiteturais de referncia, os
modelos que foram citados anteriormente so modelos gerais, os tratados neste
captulo se referem a um domnio especfico, geralmente os modelos genricos so
bottom-up e os de referncia so top-down.
Dentre os modelos de referncia temos o modelo OSI, um modelo
de sete camadas onde as camadas inferiores esto relacionadas a interconexo
fsica; as camadas intermediarias, transferncia de dados e as superiores a
transferncia de informaes, a figura 11.11 a seguir demonstra o modelo.

16

Outro modelo de referncia o modelo para ambientes CASE, onde

identificado cinco nveis de servio que ambientes CASE devem fornecer.
Repositrio de dados - onde os dados so armazenados, Integrao de dados - que
fornece recursos para gerenciamento, Gerenciamento de tarefas fornecem recurso
para definio e aprovao de modelos de processos, Mensagem fornece
comunicao entre as ferramentas e Interface de Usurio recursos para
desenvolvimento de interfaces de usurio. A figura 11.12 a seguir demonstra o
modelo.

2.2.2 ARQUITETURA DE SISTEMAS DISTRIBUIDOS (Cap. 12)

Sistema distribudo todo o sistema onde o processamento de
informaes distribudo em vrios computadores ao invs de confinado em uma
nica

mquina,

existem

duas

formas

de

compartilhamento/distribuio

de

processamento em arquitetura de software so elas as arquiteturas cliente-servidor

onde as maquinas clientes fazem uso dos servios disponibilizados pelos servidores

17

e as arquiteturas de objetos distribudos onde no h distino de o que cliente e o

que servidos, os objetos so distribudos e interagem entre si onde a localizao
irrelevante. So desenvolvidos com uma abordagem orientada a objetos que
refletem suas caractersticas, portanto so abstraes naturais para os componentes
do sistema distribudo.
2.2.2.1 Arquitetura de multiprocessadores (Cap. 12.1)
Sistema composto de mltiplos processos que podem (mas no
precisam) executar em processadores diferentes, a distribuio de processo para o
processador pode ser predeterminada ou pode estar sob o controle de um
escalonador.

2.2.2.2 Arquiteturas cliente servidor (Cap. 12.2)

A aplicao modelada como um conjunto de servios que so
fornecidos pelos servidores e um conjunto de clientes que usam estes servios, os
clientes sabem da existncia dos servidores, mas os servidores no sabem dos
clientes.

18

Dentro da mesma ideia de cliente-servidor tambm temos os clienteservidor em camadas onde temos:
Camada de apresentao Est relacionada apresentao dos
resultados de um processamento para os usurios do sistema, e coleta de
entradas do usurio.
Camada de processamento de aplicao Est relacionada ao
fornecimento de funcionalidade especfica da aplicao, por exemplo, em um
sistema de banco, funes bancrias, tais como abrir conta, fechar conta, etc.
Camada de gerenciamento de dados Est relacionada ao
gerenciamento do banco de dados do sistema.

19

Modelo de cliente-magro Em um modelo cliente-magro, todo

o processamento de aplicao e o gerenciamento de dados realizado no servidor.
O cliente responsvel, simplesmente por executar o software de apresentao.
Modelo de cliente-gordo Nesse modelo, o servidor responsvel
somente pelo gerenciamento de dados. O software do cliente implementa a lgica
da aplicao e as interaes com o usurio do sistema.

Arquiteturas em trs camadas, podem ser executadas em maquinas

separadas proporcionando escalabilidade e interoperabilidade.

20

2.2.2.3 Arquiteturas de objetos distribudos (Cap. 12.3)

Nestes modelos de arquitetura, no existem distines entre clientes
e servidores, cada entidade distribuvel um objeto que fornece servios para outros
objetos e recebe servios de outros objetos, se comunicam atravs de um sistema
de middleware chamado requisitor de objetos que tem o papel de fornecer uma
interface transparente e contnua entre os objetos, as principais vantagens deste
modelo so a possibilidade do projetista decidir posteriormente como e onde os
servios devem ser fornecidos, uma arquitetura aberta que permite adio de
novos recursos, novos recursos podem ser adicionados quando a carga do sistema
aumentas sem interromper outros objetos do sistema e a possibilidade de
reconfigurar o sistema dinamicamente com objetos que migram atravs da rede
conforme necessrio.

2.2.2.3.1 CORBA (Cap. 12.3.1)

Da sigla Common Object Request Broker Architecture, tem por
objetivo a interoperabilidade entre diferentes sistemas computacionais e linguagens
de programao atravs de ORBs, que so estruturas que permitem que os
programadores faam chamadas de um computador a outro atravs de uma rede. O
CORBA definido e padronizado pela OMG.

21

ORBs so um conjunto de objetos em uma biblioteca que so

ligadas a uma aplicao quando ela desenvolvida ele manipula comunicaes e
conhece todos os objetos no sistema e suas interfaces. Usando um ORB, o objeto
chamador liga um stub IDL que define a interface do objeto chamado, O chamado
desse stub resulta em chamadas para o ORB, que ento chama um objeto
requisitado por meio de um esqueleto IDL publicado que liga a interface
implementao de servios.

2.2.2.4 Computao Interorganizacional distribuda (Cap. 12.4)

2.2.2.4.1 Arquiteturas Ponto a ponto (Cap. 12.4.1)

Sistemas descentralizados onde a computao pode ser realizada
em qualquer n da rede, o sistema global desenvolvido para se beneficiar da
capacidade computacional. As principais vantagens so redundncia, tolerncia a
defeitos, maior eficincia. As desvantagens so overhead de comunicao,

22

mensagens replicadas, proteo dos dados e confiana.

2.2.2.4.2 Arquitetura de sistema orientada a servios (Cap. 12.4.2)

O desenvolvimento da web promoveu o acesso distribudo a
informaes, porm a princpio o acesso era somente atravs de navegadores,
pensando em aumentar a disponibilidade de informaes clientes remotos surgiu o
webservice que garante a publicao da informao para ser acessada por um
software cliente, esta arquitetura conhecida com semiscentralizada.

O fornecimento dos servios , portanto, independente da

aplicao que usa o servio, um web service uma abordagem padronizada para
tornar-se um componente reusvel disponvel e acessvel atravs da rede.

23

Um sistema de informaes de um automvel fornece aos

motoristas informaes sobre o clima, condies de trfego, Informaes locais, etc.
O sistema ligado ao aparelho de rdio do automvel que apresenta as informaes
como um sinal de emissora de rdio especfica. O automvel equipado com um
receptor GPS para informar sua posio e, baseado nessa posio, o sistema
acessa uma gama de servios de informaes. A informao pode ser fornecida no
idioma especificado pelo motorista.

24

2.2.3 ARQUITETURA DE APLICAES (Cap.13)

2.2.3.1 Sistemas de processamento de dados (Cap. 13.1)

As empresas possuem um sistema de concentrao de dados, estes
sistemas so muitas vezes maiores que as aplicaes em si, estes sistemas de
processamento de dados so sistemas de processamento em lotes nos quais os
dados so entradas e sadas em lote de um arquivo ou banco de dados em vez de
entradas ou sadas para um terminal de usurio. A arquitetura de sistemas de
processamento em lotes tem trs componentes principais entrada, processo e sada
conforme figura.

2.2.3.2 Sistemas de processamento de transaes (Cap. 13.2)

Os sistemas de processamento de transao so projetados para
executar atualizaes informaes em banco de dados.

25

2.2.3.2.1 Sistemas de gerenciamento de informaes e recursos (Cap. 13.2.1)

Todo o sistema que possui interao com banco de dados pode ser
considerado um sistema baseado em transaes, para entendermos melhor o
sistema de gerenciamento de informaes e recursos observe as figuras a seguir.

O componente LIBSYS autentica os usurios

O componente gerenciador de formulrios gerencia os

formulrios que podem ser apresentados aos usurios

26

O componente gerenciador de impressoras controla o

gerenciamento de impresses que pode ter restries
conforme requisitos.

A camada de recuperao e modificao do LIBSYS possui os

seguintes componentes especficos

Busca distribuda que procura os documentos em resposta s

consultas.

Recuperao de documentos que recupera os documentos

solicitados pelo usurio.

Gerenciador de direitos que gerencia as alteraes e direitos

autorais, mantm registro de quem requisitou o documento e
assegura que no sejam feitas vrias requisies para o
mesmo documento pela mesma pessoa.

Contabilidade que registra as solicitaes e cuida de

quaisquer encargos criados pelas bibliotecas.

2.2.3.3

Sistema de processamento de eventos (Cap. 13.3)

Os sistemas de processamento de eventos respondem aos eventos

do ambiente ou da interface com o usurio do sistema, sistemas com funcionamento

em tempo real so sistemas de processamento de eventos, porm os eventos so
associados a sensores e atuadores do sistema. Podemos utilizar como exemplo os
sistemas de processamento de texto e jogos.
2.2.3.4 Sistemas de processamento de linguagem (Cap. 13.4)
Os sistemas de processamento de linguagens aceitam uma
linguagem natural ou artificial como entrada e geram alguma outra representao
dessa linguagem como sada. Ex. Compiladores e descrio de dados XML em
comandos.
2.2.4 GERENCIAMENTO DE CONFIGURAO (Cap 29)
Envolve o desenvolvimento e a aplicao de procedimentos e

27

padres para gerenciar um produto de software em evoluo, o GC pode ser visto

como parte de um processo mais geral de gerenciamento do projeto, os artefatos
que esto sob gerenciamento de configurao so chamados de itens de
configurao.
2.2.4.1 Planejamento de gerenciamento de configurao (Cap. 29.1)
Processo que define o que ser gerenciado, quem o responsvel
pelo gerenciamento, as polticas de gerenciamento, especifica as ferramentas que
sero usadas e descreve a estrutura do banco de dados de configurao.
2.2.4.1.1 Identificao de item de configurao (Cap. 29.1.1)
Processo onde feito a deciso de quais itens (ou classe de itens)
sero controlados.
2.2.4.1.2 Banco de dados (Cap. 29.1.2)
Utilizado

para

registrar

todas

as

informaes

referente

as

configuraes do sistema e os itens de configurao e alm disso, informaes

tpicas como quais clientes pegaram a verso, configurao de HW necessria,
quantas verses do sistema foram criadas, quais verses podem ser impactadas por
uma alterao, quantas solicitaes de mudana surgiram e quantos defeitos foram
reportados.
2.2.4.2 Gerenciamento de mudanas (Cap. 29.2)
Sistemas de software so sujeitos a solicitaes contnuas de
mudana, mudanas essas que podem partir de usurios, desenvolvedores ou
foras do mercado. O gerenciamento de mudanas est relacionado manuteno
da rastreabilidade dessas mudanas de modo que reparos realmente corrijam
falhas, novas falhas produzidas por reparos possam ser identificadas rapidamente e
seja fcil descobrir quais mudanas foram implementadas e quando.
O

maior

problema

no

gerenciamento

de

mudanas

acompanhamento de seu status por isso ferramentas de gesto de mudanas

28

fornecem meios para se acompanhar a situao de cada solicitao, as mudanas

devem ser analisadas por um grupo que analise se elas so adequadas ou no em
termos de custo, tempo, risco e tambm de um ponto de vista estratgico ou
organizacional ao invs de somente o ponto de vista tcnico.
2.2.4.3 Gerenciamento de verses e releases (Cap. 29.3)
Usado para elaborar um esquema de identificao para verses do
sistema, planejar quando uma nova verso do sistema ser produzida, asseguras de
procedimentos e ferramentas de gerenciamento das verses sejam adequadamente
aplicas alm de planejar a distribuio de novas releases ou verses do sistema.
2.2.4.3.1 Identificao de verso (Cap.29.3.1)
uma instncia de um sistema que funcionalmente distinta, de
alguma maneira, de outras instncias de um sistema, existem 3 tcnicas bsicas
para identificao de verso:

Numerao de veres Nmero explcito e nico da verso

Identificao baseada em atributos Identificao pelo nome

ou valores de atributos

Identificao orientada a mudanas Identificada pelo

conjunto de solicitaes que se aplicaram ao componente.

2.2.4.3.2 Gerenciamento de releases (Cap. 29.3.2)

uma instncia de um sistema distribuda para os usurios fora da
equipe de desenvolvimento, somente liberada aps a anlise de fatores
estratgicos.
2.2.4.4 Construo de sistemas (Cap. 29.4)
A construo de sistema a compilao e ligao e ligao de
componentes de software que executa determinada configurao questes como.
Todos os componentes foram includos? As verses so as necessrias para

29

construo? Todos os arquivos esto disponveis? A verso do compilador requerido

est disponvel?
Hoje em dia, os gerenciadores de configurao auxiliam no processo
de construo do sistema onde todas as dependncias so especificadas no script
de configurao.
2.2.4.5 Ferramentas CASE para gerenciamento de configurao (Cap. 29.5)
A responsabilidade no gerenciamento de configuraes exige rigor
ao gerar uma nova verso, por isso foi necessrio o desenvolvimento do uso de
ferramentas CASE para facilitar e melhorar este controle. Muitos sistemas de grande
porte so produzidos em lugares diferentes e por isso necessitam de um sistema de
SCM que apoie esta forma de trabalho como a CVS que conta com este recurso.
2.2.4.5.1 Apoio para gerenciamento de mudanas (Cap. 29.5.2)
Existem ferramentas CASE para auxlio no gerenciamento de
mudanas, desde as mais simples e OpenSource como o BugZila at as mais
abrangentes e integradas com a ClearQuest da Rational, estas ferramentas
fornecem uma srie de funcionalidades que facilitam o controle de mudanas como
editor de formulrios, sistemas de workflow, compilao distribuda e gerenciamento
de objetos derivados.
2.2.4.5.2 Apoio para gerenciamento de sistemas (Cap. 29.5.3)
O processo de construo do sistema dependendo do tamanho do
projeto pode envolver diversos arquivos, a gesto destes arquivos para compilao
se depender de mo humana pode ser crtica para o sistema por isso,
aconselhado o uso de fermentas case que fazem o gerenciamento dos arquivos e
ligaes de forma automtica evitando possveis erros humanos. Caractersticas
como uma linguagem de especificao de dependncia e um interpretador
associado, seleo de ferramenta de apoio a instalao, compilao distribuda e
gerenciamento de objetos derivados normalmente esto presentes nestas
ferramentas.

30

2.3 DESAFIO III FRAMEWORKS DE DESENVOLVIMENTO JAVA

Framework uma abstrao que une cdigos comuns entre vrios
projetos de software provendo uma funcionalidade genrica. Um framework pode
atingir uma funcionalidade especfica, por configurao, durante a programao de
uma aplicao. Ao contrrio das bibliotecas, o framework quem dita o fluxo de
controle da aplicao, chamado de Inverso de Controle.
No desenvolvimento, utilizar um framework til quando se utiliza
aquela funcionalidade com frequncia. Atualmente podemos encontrar diversos
frameworks disponveis para uso, faremos um comparativo dos principais.
2.3.1 Pesquisa bibliogrfica sobre frameworks

2.3.1.1 Interface

Struts Framework desenvolvido por Craig McClanahan e

doado a apache foundation, O objetivo do Struts separar o
model (modelo - lgica de aplicativo que interage com um
banco de dados) do view (visualizao - pginas HTML
apresentadas para o cliente) e do controller (controlador instncia que transmite informaes entre a exibio e o
modelo). Struts fornece o controlador/controller (um servlet
conhecido como ActionServlet) e facilita a escrita de moldes
padronizados

para

camada

de

visualizao/view

(normalmente em JSP, mas XML/XSLT e Velocity tambm so

suportados). O programador de aplicativo da web
responsvel por escrever o cdigo do modelo/model, e por
criar um arquivo de configurao centralizador (strutsconfig.XML) que une modelo, visualizao e controlador. As
principais funes so a facilitao de populao de beans
(Action

Forms),

simplificao

do

uso

de

servlets,

necessitando apenas a criao de classes Action e possibilita

a dispensa do uso de scriptlets em 98% dos casos.

31

JSF - um framework para a construo de interfaces de

usurio baseadas em componentes para aplicaes web.
Possui um modelo de programao dirigido a eventos,
abstraindo os detalhes da manipulao dos eventos e
organizao dos componentes, permitindo que o programador
se concentre na lgica da aplicao. Suas principais
caractersticas so:

Permite que o desenvolvedor crie UIs atravs de

um conjunto de componentes UIs pr-definidos;

Fornece um conjunto de tags JSP para acessar

os componentes;

Reutiliza componentes da pgina;

Associa os eventos do lado cliente com os

manipuladores dos eventos do lado do servidor
(os componentes de entrada possuem um valor
local representando o estado no lado servidor);

Fornece separao de funes que envolvem a

construo de aplicaes Web.

Utiliza Ajax em alguns de seus componentes

tornando alguns processos mais rpidos e
eficientes.

2.3.1.2 Persistncia de dados

Hibernate - Framework para o mapeamento objeto-relacional

escrito na linguagem Java, Este framework facilita o
mapeamento dos atributos entre uma base tradicional de
dados relacionais e o modelo objeto de uma aplicao, o
objetivo do Hibernate diminuir a complexidade entre os
programas

Java

sendo

sua

principal

caracterstica

transformao das classes em tabelas de dados alm dos

tipos de dados do JAVA para SQL.

JDO - Plataforma para persistncia de objetos, uma das suas

32

funcionalidades o servio de persistncia para o modelo de

domnio. Ela disponibiliza uma interface bem definida que
prov uma camada de abstrao entre as aplicaes e
armazenadores de dados de vrios tipos. Os objetos
persistentes na especificao JDO so objetos de classes
simples escritas em Java (POJOs); no existe necessidade
de implementar certas interfaces ou estender classes
especiais.
2.3.2 Benefcios de uso de frameworks
As

principais

vantagens

do

uso

de

frameworks

para

desenvolvimento java a reduo de custos e a reduo do tempo de entrega pela

maximizao do reuso, menor manuteno.

2.3.3 Plataforma de desenvolvimento JAVA Web

Para execuo e implementao de um sistema web desenvolvido
em java necessrio a instalao de alguns componentes que so pr-requisitos:

Instalao da ltima verso do Java

Instalao do JDK que possui todo o ambiente necessrio

para desenvolver e executar aplicativos em Java

Se o objetivo for desenvolvimento deve instalar um ambiente

RAD para facilitar na implementao.

2.4 DESAFIO IV ANLISE CHINA TELECOM

Para suprir necessidade da China Telecom for escolhido o modelo
cliente servidor por proporcionar uma centralizao do processamento e permitir que
as informaes sejam acessadas nas unidades descentralizadas da empresa, os
aplicativos devero utilizar a arquitetura SOA onde devero acessar os servios e
dados disponveis nos servidores de Hewlett-Packard adquiridos para este mesmo
projeto. Dever ser adotado um framework MVC para desenvolvimento e deve-se

33

prezar pelo reaproveitamento de cdigo.

Para persistncia dos dados ser utilizado banco de dados Oracle,
por sua confiabilidade e robustez tendo em vista o crescimento rpido que aempresa
tem tido nos ltimos anos.

34

3 CONCLUSO
Aps a ampla pesquisa feita para cumprimentos dos desafios
apresentados conclui-se a implementao de padres para projetos e construo de
softwares so muito importantes devido aos compromissos que so assumidos
pelos desenvolvedores serem cada vez maiores, com requisitos de qualidade mais
aprimorados e tambm com prazo cada vez mais curto. Vimos tambm alguns
frameworks JAVA e podemos conhecer melhor suas vantagens e caractersticas
assim como o ambiente necessrio para utilizao destas ferramentas. Com a
anlise do caso da China Telecom foi possvel o exerccio dos ensinamentos
adquiridos na pesquisa e durante as aulas ministradas no semestre.

35

REFERNCIAS
PROJECT MANAGEMENT INSTITUTE. A Guide to the Project Management Body
of Knowledge (PMBOK Guide) - Fifth Edition. Pennsylvania: PMI, 2013.
HISATOMI, Marco Ikuro. Projeto de sistemas. So Paulo: Pearson Education do
Brasil, 2010.
SOMMERVILLE, Ian. Engenharia de Software. So Paulo: Pearson Education do
Brasil, 2009.
THE APACHE SOFTWARE FOUNDATION. Apache Struts. Disponvel em:
<<https://struts.apache.org/>>Acesso em: 13 de maio de 2015
REDHAT. Hibernate ORM. Disponvel em: <<http://www.hibernate.org/orm>>Acesso
em: 13 de maio de 2015.
SOUV, Jacques Philippe. Vantagens e desvantagens no uso de Frameworks.
Disponvel em:
<<http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/frame/porque.htm >>
Acesso em: 13 de maio de 2015.