1

SISTEMA DE ENSINO PRESENCIAL CONECTADO

ANALISE E DESENVOLVIMENTO DE SISTEMAS
ROSSENY FERREIRA LACERDA FILHO

GESTO DO PROCESSO DE DESENVOLVIMENTO I

VITRIA DA CONQUISTA-BA
2015

ROSSENY FERREIRA LACERDA FILHO

GESTO DO PROCESSO DE DESENVOLVIMENTO I

Trabalho apresentado ao Analise e Desenvolvimento de

Sistemas da UNOPAR - Universidade Norte do Paran,
para a disciplina Porijeto Orientado a Objetos,Egenharia
e Projeto de Software Porgramao para WebII.
Prof. Mrcio Roberto Chiaveli
Luis Claudio Perini
Marcos Ikuri Hisatomi
Veronice de Freitas

VITRIA DA CONQUISTA-BA
2015

Contedo
1.

INTRODUO...................................................................................................4

2.

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

3.

ENGENHARIA DE SOFTWARE.....................................................................5
3.1

REAS DE COMPETNCIA PMBoK.........................................................5

3.1.1 RISCO..........................................................................................................5
3.1.2 ESCOPO......................................................................................................5
3.1.3 PARTES INTERESSADAS.........................................................................6
3.1.4 FORNECEDORES......................................................................................6
3.2

RESENHA LIVRO ENGENHARIA DE SOFTWARE...............................6

3.3

12 ARQUITETURA DE SISTEMAS DISTRIBUIDOS.............................13

3.4

13 Arquitetura de aplicaes........................................................................18

3.5

29 Gerenciamento de configuraes............................................................23

4.

PROGRAMAO PARA WEB II..................................................................29

5.

CONCLUSO...................................................................................................34

6.

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

1. INTRODUO

A engenharia de Software tem se tornado uma ferramenta cada vez mais importante
para os profissionais envolvidos com tecnologia da informao. No escopo deste trabalho
estarei abordando questes fundamentais referente engenharia de software bem como os
principais frameworks Java para desenvolvimento web.

2. DESENVOLVIMENTO.
3. ENGENHARIA DE SOFTWARE

3.1 REAS DE COMPETNCIA PMBOK

3.1.1 RISCO
Esta rea descreve os processos relativos realizao do gerenciamento de riscos em
um projeto. Temos cinco processos de planejamento e um de controle. Os processos desta rea
de conhecimento tem como objetivo determinar como os riscos sero identificados, analisados
e como as respostas sero planejadas e como risco ser planejado, criam uma lista de riscos
identificados no projeto com diversas tcnicas que ajudam a gerar essa lista de riscos, buscam
priorizar os riscos com base no grau de criticidade, permitem atribuir probabilidade numrica
aos riscos, definem estratgias e aes para lidar com os riscos negativos e positivos,
monitoram os risco com novos risco sendo identificados, reviso das anlises de riscos,
definio de outras prioridades de riscos, etc.
Os processos dessa rea so:

Planejar o Gerenciamento dos Riscos.

Identificar os Riscos.

Realizar a Anlise Qualitativa de Riscos.

Realizar a Anlise Quantitativa dos Riscos.

Planejar as Respostas aos Riscos.

Monitorar e Controlar os Riscos.

3.1.2 ESCOPO
Esta rea descreve os processos envolvidos na verificao de que o projeto inclui todo
o trabalho necessrio e apenas o trabalho necessrio, para que seja concludo com sucesso.
Existem trs processos de planejamento (trs primeiros) e dois processos de controle e
monitoramento (dois ltimos). Os processos de planejamento criam um plano para o
gerenciamento de escopo. Os processos de controle e monitoramento controlam se que o
escopo est sendo cumprido conforme foi definido nos processos de planejamento e a
verificao confirma com o cliente que est tudo correto.

3.1.3 PARTES INTERESSADAS

Esta rea descreve os processos relativos gerao, coleta, disseminao,
armazenamento e destinao final das informaes do projeto de forma oportuna e adequada.
Os processos desta rea de conhecimento determinam quem est envolvido no projeto,
definem como as comunicaes vo ocorrer quando o projeto iniciar e determina o tipo de
informaes gerada, quem o responsvel, qual o meio, quem receber as informaes
geradas, qual a periodicidade, determinam como sero distribudas as informaes, como
podemos gerenciar as expectativas dos interessados medindo o grau de satisfao ou
insatisfao das pessoas interessadas, e geram relatrios que permitam o acompanhamento e
controle do que est acontecendo com o tempo, custo, escopo, etc.
Os processos dessa rea so:

Identificar as Partes Interessadas.

Planejar as Comunicaes.
Distribuio das Informaes.
Gerenciar as Expectativas das Partes Interessadas.
Reportar Desempenho

3.1.4 FORNECEDORES

3.2 RESENHA LIVRO ENGENHARIA DE SOFTWARE

3.2.1 11 PROJETO DE ARQUITETURA

O projeto de arquitetura primeiro estagio no processo de projetos. Diz o livro que ele
idntifica subsistemas e estabelece um framework para controlar a comunicao dos
subsistemas, subsistemas so sistemas grandes decompostos em subsistemas e que fornece
algum conjunto de servios relacionados. Ele 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: uma apresentao em alto nvel do sistema

que enfoca a discusso entre diferentes stakeholders.

Analise de sistemas: Tem profundo efeito sobre o sistema, mostra se o sistema
pode atender aos requisitos crticos como, confiabilidade, desempenho e

facilidade de manuteno.
Reuso em larga escala: Apoia o reuso em larga escala de sistemas que possuem
arquiteturas de sistemas familiares.

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. O estilo e estrutura da aplicao dependem dos requisitos no funcionais do sistema,
por exemplo: 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 requisto crtico, a arquitetura de sistemas deve
ser projetada usando componentes de baixa granularidade e autocontidos que possam ser
prontamente mudados.

H conflitos potenciais entre algumas dessas arquiteturas, por exemplo se o

desempenho que necessita de alta granularidade e a facilidade de manuteno que necessita de
baixa granularidade forem ambos requisitos crticos ter que ser encontrada alguma soluo
eficaz.
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 comunio 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.

3.2.2 11.1 DECISES DE PROJETO DE ARQUITETURA

O projeto de arquitetura tenta estabelecer uma organizao de sistemas que satisfao

os requisitos funcionais e os no funcionais do sistema. Durante o processo de projeto de
arquitetura

os

arquitetos

de

sistemas

devem

responder

algumas

perguntas:

Existe uma arquitetura genrica de aplicao que possa funcionar como um modelo para o
sistema que est sendo projetado? Como o sistema ser distribudo ao longo de vrios
processadores? Qual ou quais estilos de arquitetura so apropriados para o sistema? Qual ser
a abordagem fundamental usada para estruturar o sistema? Como as unidades estruturais de
um sistema sero decompostas em mdulos? Qual estratgia ser utilizada para controlar a
operao das unidades do sistema? Como o projeto de arquitetura ser avaliado? Como a
arquitetura do sistema deve ser documentada?
Ao Projetar uma arquitetura de sistemas, voc precisa decidir o que seu sistema e
classes mais amplas de aplicao tem em comum, e decidir quanto conhecimento dessas
arquiteturas de aplicao voc pode reusar. A arquitetura de um sistema de software pode ser
baseada em um modelo ou estilo de arquitetura especifico, Em alguns casos a arquitetura
geral de um sistema pode ser uma arquitetura composta. Os modelos de arquitetura que
podem ser desenvolvidos podem incluir: 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.

3.2.3 11.2 ORGANIZAO DE SISTEMA

A organizao de um sistema reflete a estratgia bsica usada para estrutura-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
subsistema.
Exite trs estilos de organizacionais amplamente usados:

3.2.4 11.2.1 MODELO DE REPOSITRIO

Os subsistemas que constituem um sistema devem trocar informaes de mofo que

possam trabalhar juntos eficientemente. Esse modelo , portanto, adequado para aplicaes
em que os dados so gerados por um subsistema e usados por outro. O repositrio passivo e
o controle de responsabilidade dos subsistemas que o usam.

3.2.5 11.2..2 MODELO CLIENTE SERVIDOR

O modelo de arquitetura cliente servidor um modelo em que o sistem 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. No entanto os servidores no precisam saber a identidade do cliente ou
quantos so. So acessados os servios por meio de chamadas remotas de procedimento
usando um protocolo requesteply, o cliente faz um pedido a um servidor e espera ate receber
uma resposta. 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 integra-lo ao restante do sistema

10

3.2.6 11.2.3 O MODELO EM CAMADAS

O modelo em camadas organiza um sistema em camadas, cada uma das quais

fornecendo um conjunto de servios. A abordagem em camadas apoia o desenvolvimento
incremental de sistemas. A medida que uma camada desenvolvida alguns servios
fornecidos por essa camada podem ser disponibilizados para os usurios. Essa arquitetura
tambm modificvel e portvel. Desde que sua interface permanea inalterada, uma camada
poder ser substituda por outra equivalente. 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.
O desempenho tambm pode ser um problema devido aos vrios nveis de interpretao de
comandos algumas vezes exigidos.

3.2.7 11.3 ESTILOS DE DECOMPOSIO MODULAR

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

orientada

objetos

pipelining

orientado

funes.

Voc deve evitar tomar decises prematuras sobre a simultaneidade de um sistema.

3.2.8 11.3.1 DECOMPOSIO ORIENTADA A OBJETO

Um modelo de arquitetura orientado a objetos estrutura o sistema em um conjunto de

objetos no firmemente acoplados com interfaces bem definidas. Os objetos chamam servios
oferecidos por outros objetos. Uma decomposio orientada a objetos esta relacionada a
classes de objetos, seus atributos e suas operaes. Quando implementados os objetos so

11

criados a partir dessas classes e algum modelo de controle usado para coordenar as
operaes de objetos. A vantagem que implementao de objetos pode ser modificada sem
afetar outros objetos. A desvantagem que para usar servios os objetos devem fazer
referencia explicita ao nome e a interface de outros objetos.

3.2.9 11.3.2 PIPELINING ORIENTADO A FUNES

No pipelining orientado a funes ou modelo de fluxo de dados, as transformaes

processam suas entradas e produzem sadas. Os dados fluem de uma para outra funo e so
transformados ao moverem se sequencialmente. Cada etapa implementada como uma
transformao.Os dados de entrada fluem atravs dessas transaes ate serem convertidos em
dados se sada. As vantagens dessa arquitetura so: Apoiar o reuso de transformaes. Ele
intuitiva, muitas pessoas pensam em seu trabalho em termos de processamento de entrada e
sada. A evoluo do sistema pela adio de novas transformaes geralmente direta.
Ela simples de ser implementada tanto quanto um sistema concorrente ou sequencial. O
principal problema que ele necessita ser um formato comum para transferir dados que possa
ser reconhecido por todas as transformaes. Sistemas interativos so difceis de escrever
usando esse modelo por causa da necessidade de uma sequencia de dados ser processada.

3.2.10 11.4 MODELOS DE CONTROLE

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.

12

3.2.11 11.4.1 CONTROLE CENTRALIZADO.

Em modelo de controle centralizado, um subsistema designado como controlado de

sistema e tem a responsabilidade pelo gerenciamento da execuo de outros subsistemas.
Modelos de controle centralizados Dividem se em duas classes, dependendo se forem
executados sequencialmente ou paralelamente. O modelo chamado retorno. O controle
comea no topo da hierarquia de sub rotina e , atravs de chamadas de sub-rotinas, passa
para os nveis mais baixos na arvore, so aplicados em modelos sequenciais. O modelo
gerenciados. Aplicados em modelos concorrentes. Um sistema concorrente projetado como
um gerenciador de sistema e controla o inicio, a parada e a coordenao de outros processos
do sistema. Sistemas orientados a eventos. As decises dos modelos orientados a eventos so
regidos pelos eventos gerados externamente. O termo evento pode ser um sinal que pode
assumir uma gama de valores ou uma entrada de comando baseados em um menu. Possuem
dois modelos de controle orientados a eventos. Modelos de broadcast. Nesse modelo, um
evento transmitido a todos os subsistemas. Qualquer subsistema programado para manipular
o evento pode responder a ele. A vantagem dessa abordagem que a evoluo relativamente
simples, um novo subsistema para tratar classes especificas de eventos pode ser integrado por
meio do registro de seus eventos no tratador de eventos. A desvantagem que os sbsistemas
no sabem se ou quando os eventos sero manipulados. Modelos orientados a interrupes.
So usados em sistemas de tempo real como requisitos rigorosos de tempo, nos quais as
interrupes externas so detectadas por um trator de interrupes.A vantagem dessa
abordagem que ela permite respostas muito rpidas aos eventos a serem implementados. Sua
desvantagem a complexidade da programao e a dificuldade de validao.

3.2.12 11.5 ARQUITETURA DE REFERNCIA

As arquiteturas de referncia 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.
Um modelo de referencia forenece um vocabulrio para comparao. Ele atua como uma

13

base, em relao a qual os sistemas podem ser avaliados. 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. Os cincos nveis de referencias so:
Servios de repositrio de dados, estes servios fornecem recursos para o armazenamento e o
gerenciamento de itens de dados e seus relacionamentos. Servios de integrao de dados,
estes servios fornecem recursos para o gerenciamento de grupos ou para definio de
relacionamentos entre eles. Servios de gerenciamento de tarefas, estes servios fornecem
recursos para a definio e aprovao de modelos de processo. Servios de mensagem.
Comunica ferramenta Ferramenta, ambiente-ferramenta e ambiente ambiente. Servios de
interface com o usurio. Este servio fornecem recursos para o desenvolvimento de interface
com o usurio. A finalidade dessa arquitetura de referencia ser um meio de classificao e
comparao de ferramentas e ambientes CASE integrados.

3.3 12 ARQUITETURA DE SISTEMAS DISTRIBUIDOS

Um sistema 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 Um sistema distribudo permite o

compartilhamento de recursos de hardware e software, como discos,
impressoras, arquivos e computadores que esto associados aos diferentes

computadores de uma rede.

Abertura - permitem a equipamentos e software de diferentes fabricantes serem

combinados, pois so projetados com base em protocolos padres.

Concorrncia vrios processos podem operar ao mesmo tempo em diferentes

computadores, e podem (mais no precisam) conversar uns com os outros.

Escalabilidade so escalonveis a maneira que a capacidade de um sistema
pode ser ampliada pela adio de novos recursos para atender as demandas dos

sistemas.
Tolerncia a defeitos pela disponibilidade de vrios computadores e o
potencial de duplicao de informao significa que os sistemas distribudos
possam ser tolerantes a algumas falhas de hardware e software. Esses sistemas

14

de distribuio comparados aos sistemas que operam com um processador ou

com um cluster de processadores podem ter algumas desvantagens como:
Complexidade - os sistemas distribudos so mais complexos que os
sistemas centralizados.
Proteo o sistema pode ser acessado de vrios computadores
diferentes, e o trafego na rede pode estar sujeita a interceptaes.
Gerenciamento os computadores do sistema podem ser de tipos
diferentes e podem operar em verses diferentes de sistemas operacionais. Defeitos em uma
mquina podem se propagar a outra maquinas com consequncias inesperadas.
Imprevisibilidade Como todos os usurios da web sabem, os sistemas
distribudos so imprevisveis em suas respostas. A resposta depende da carga total do
sistema, sua organizao e a carga da rede. Como tudo isso pode mudar em um curto perodo
de tempo, o tempo de resposta para uma solicitao do usurio pode variar drasticamente de
uma solicitao para outra.
Possuem dois 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.

3.3.1 12.1 ARQUITETURA DE MULTPROCESSADORES

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

15

3.3.2 12.2 ARQUITETURA CLIENTE-SERVIDOR

Em um arquitetura cliente-servidor, uma aplicao modelada como um conjunto de

clientes que usam esses servios. Os clientes precisam estar informados sobre os servios
disponveis, mas geralmente no sabem da existncia de outros clientes. Vrios processos de
servios podem ser executados em um nico processador de servio portanto no h
mapeamento entre processos e processadores de um sistema.
O projeto de sistemas cliente-servidor deve refletir a estrutura lgica da aplicao que
esta sendo desenvolvida. Um exemplo uma aplicao q esta dividida em 3 camadas: a
camada de apresentao, que se encarrega da apresentao de informaes para o usurio e
toda a interao com o usurio. A camada de processos de aplicaes se encarrega da
implementao da lgica da aplicao e a camada de gerenciamento de dados se encarrega de
todas as operaes de banco de dados.
A arquitetura cliente-servidor mais simples denomina-se arquitetura cliente-servidor
de duas camadas, podem ter duas formas:

Modelo cliente-magro. O processamento e o gerenciamento de dados so

realizados no servidor. O cliente apenas executa o software de apresentao.

Modelo cliente-gordo. 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.

Uma desvantagem do modelo cliente-magro que ele impe uma grande carga de
processamento sobre o servidor e a rede.
O modelo cliente-gordo faz uso dessa capacidade de processamento disponvel e
distribui o processamento lgico de aplicao e a apresentao do cliente. O servidor
essencialmente um servidor de transaes que gerencia todas as transaes do banco de
dados.
Enquanto o modelo cliente-gordo distribui o processamento mais eficientemente do que um
modelo cliente-magro, o gerenciamento do sistema mais complexo. A funcionalidade da
aplicao dividida entre vrios computadores. Quando o software precisa ser alterado, isso
envolve reinstalao em cada computador cliente, o que pode resultar em um custo
significativo se houver centenas de clientes no sistema.

16

O Problema com a abordagem cliente-servidor de duas camadas que as trs camadas

lgicas, devem ser mapeadas sobre dois sistemas de computador o cliente e o servidor. Pode
haver problemas de escalabilidade e desempenho, se o modelo cliente-magro for
escolhido, ou problemas de gerenciamento de sistemas, se o modelo cliente-gordo for usado.
Para evitar esses problemas uma alternativa usar o modelo cliente-servidor de trs camadas.
Em alguns casos melhor estender o modelo cliente-servidor de trs camadas para uma
variante com varias camadas, na qual servidores adicionais so incorporados ao sistema.

3.3.3 12.3 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 inteface transparente continua entre os objetos. Ele fornece um
conjunto de servios que permitem que os objetos se comuniquem e sejam adicionados e
removidos do sistema. As vantagens so:

Permite que o projetista do sistema postergue decises sobre onde e como os

servios devem ser fornecidos.

uma arquitetura de 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 cliente-

servidor adequada para esse tipo de aplicao por trs razes:

O modelo lgico do sistema no um dos fornecimentos de servios em que

existem servios distintos de gerenciamento de dados.

Pode adicionar bancos de dados ao sistema sem grande interrupes.

A maior Desvantagem que elas so mais complexas do que sistemas cliente-servidor.

3.3.4 12.3.1 CORBA

Existem quatro elementos principais desse padro:

17

Um modelo de objeto para objetos de aplicaes em que um objeto corba um

encapsulamento de estado com uma interface bem definida em linguagem

neutra descrita em um linguagem de definio de interface.

Um requisitor de objetos que gerencia solicitaes para servios de objetos.
Um conjunto de servios de objetos que so servios gerais com probabilidade

de serem solicitados por muitas aplicaes distribudas.

Um conjunto de componentes comuns construdos sobre esses servios bsicos
que podem ser solicitados pelas aplicaes.

O Corba considera um objeto como se fosse um encapsulamento de atributos e

servios, como normal em objetos.o Corba deve ter uma definio de interface separada que
define atributos e operaes publicas do objeto. as interfaces so definidas por uma linguagem
de definio de interface padronizada independe de linguagem.
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.
O corba foi desenvolvido desde 1980 e as verses recentes de corba foram
simplesmente dedicadas ao apoio aos objetos distribudos.
Os padres Corba incluem definies de interfacepara 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.

3.3.5 12.4

COMPUTAO

INTERORGANIZACIONL

DISTRIBUIDA
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

18

localizados dentro da mesma organizao, podem ser aplicados padres e processos

operacionais locais.

3.3.6 12.4.1 ARQUITETURAS PONTO A PONTO

So sistemas descentralizados em que as computaes podem ser realizadas por

qualquer n da rede, nenhuma distino feita entre clientes e servidores. O sistema global
projetado para beneficiar-se da capacidade computacional e armazenamento disponveis em
uma rede de computadores potencialmente grande. Em principio, em sistemas ponto a ponto,
todo n de rede pode estar ciente a respeito de qualquer outro n, pode fazer conexes com
ele e pode trocar dados com ele. Em uma arquitetura descentralizada, os nos de rede no so
simplesmente elementos funcionais, mais tambm chaves de comunicao que podem guiar
os sinais de dados e de controle de um n para o outro. No entanto quando se recupera um
documento, o n que esta recuperando se torna visvel para outros.

3.3.7 12.4.2 ARQUITETURA DE SISTEMA ORIENTADO A

SERVIOS

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

19

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 esses padres so baseados em XML

3.4 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. 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).

3.4.1 13.1 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 processamento de dados possuem 3 componentes principais:

Entrada. A entrada coleta as entradas de uma ou mais fontes.

Processamento. O processamento realiza a computao usando essas entradas.
Sada. A sada gera Sadas a serem escritas novamente no banco de dados e ou
impressas.

Os componentes de entrada , processamento e de sada podem ser decompostos ainda

em uma estrutura entrada-processamento-sada. Exemplo: Um componente de entrada pode

20

ler algum dado de um arquivo ou banco de dados(entrada) e corrigir alguns erros (processo) e,
depois enfileirar os dados validos para processamento (sada).So sistemas orientados a
funes, pois os registros e as transaes so processados em serie, sem necessidade de
manter o estado entre as transaes.

3.4.2 13.2

SISTEMAS

DE

PROCESSAMENTO

DE

TRANSAES

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 a
transao foi concluda adequadamente, ele sinalizara para a aplicao que o processamento
foi finalizado.
Os sistemas de transaes so projetados para processar solicitaes de informaes
por usurios de um banco de dados. Tecnicamente uma sequencia de operaes tratada
como uma unidade simples (uma unidade atmica). Todas as operaes tem que ser realizadas
antes que as mudanas tornem-se permanentes no banco de dados.
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.
Um exemplo de sistema de processamento de transaes um sistema bancrio que
permite aos clientes consultarem suas contas e retirarem dinheiro de um caixa eletrnico. O
sistema composto de dois subsistemas de software que cooperam entre si o software de
caixa eletrnico e o software de processamento de contas localizadas no servidor de banco de
dados. Os subsistemas de entrada e de sada so implementados como softwares no caixa
eletrnico, uma vez que o subsistema de processamento est no servidor de banco de dados
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

21

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.
Para simplificar o gerenciamento de diferentes protocolos de comunicao entre
terminais, sistemas de processamento de transaes de larga escala podem incluir middleware
para comunicao com todos os tipos de terminal, organizao e ordenao em serie dos
dados dos terminais e envio dos dados para processamento.

3.4.3 13.2.1

SISTEMAS

DE

GERENCIAMENTO

DE

INFORMAES E RECURSOS

Um sistema de informaes permite acesso controlado de uma grande base de

informaes, tais como catalogo de bibliotecas, tabela de horrios de voos ou registros de
pacientes em um hospital. O desenvolvimento da WEB fez com que um grande numero de
sistemas de informaes migrasse de sistemas organizacionais especializados para sistemas de
propsito geral acessveis universalmente.
O sistema de informao modelado com o uso de uma abordagem de camadas ou de
maquina abstrata na qual a camada superior apoia a interface com o usurio e a camada
inferior, o banco de dados de sistema. A camada de comunicaes inclui uma lgica especifica
de aplicao para acesso e atualizao do banco de dados.
Sistemas de alocao de recursos so uma classe de aplicao amplamente usada. Sua
arquitetura esta alinhada com o modelo de sistema de informaes. Os componentes de um
sistema de alocao de recursos inclui:

Um banco de dados de recursos que mantm detalhes de recursos que so

alocados. Os recursos podem ser adicionados ou removidos do banco de dados.

Um conjunto de regras que descreve as regras de alocao de recursos.
Um componente de gerenciamento de recursos que permite que o provedor de

recursos adicione, edite ou elimine recursos do sistema.

Um componente de alocao de recursos que atualiza o banco de dados de
recursos quando eles so designados e que associa esse recursos a detalhes do
solicitante do recurso.

22

Um modulo de autenticao de usurios que permite ao sistema verificar se os

recursos esto sendo alocados para um usurio reconhecido.

Um modulo de gerenciamento de consultas que permite ao usurio descobrir

quais recursos esto disponveis.

Um componente de entrega de recursos que prepara os recursos a serem
entregues ao solicitante. Em um sistema de emisso de ingressos, isso pode
envolver a preparao de uma confirmao por e-mail, o envio de uma
solicitao para uma impressora que imprime os ingressos e os detalhes de para

onde os ingressos devem ser enviados.

Um componente de interface com o usurio que esta fora do sistema e permite
ao solicitante do recurso enviar consultas e solicitaes para o recurso a ser
alocado.

3.4.4 13.3 SISTEMAS DE PROCESSAMENTO DE EVENTOS

O sistemas de processamento de eventos respondem aos eventos do ambiente ou da

interface com o usurio do sistema. A principal caracterstica dos sistemas de processamento
de eventos que a sequencia de eventos imprevisvel e o sistema deve ser capaz de trabalhar
com esses eventos quando eles ocorrerem.
Sistemas de tempo real, so tambm sistemas de processamento baseados em eventos,
porem ao invs de ter eventos de interface com o usurio, tem eventos associados a sensores e
atuadores do sistema.

3.4.5 13.4

SISTEMAS

DE

PROCESSAMENTO

DE

LINGUAGENS

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

23

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, que obtm elementos da linguagem de entrada e os

converte em um formato interno.

Uma tabela de smbolos que mantm informaes sobre os nomes de entidades

(variveis, nomes de classes.) usadas no texto que esta sendo traduzido.

Um analisador sinttico, que verifica a sintaxe da linguagem que est sendo
traduzida. Ele usa uma gramtica definida de linguagem e constri uma arvore

de sintaxe.
Ume rvore de sintaxe, que uma estrutura interna que representa o programa

que esta sendo compilado.

Um analisador semntico, que usa informaes da rvore de sintaxe e da tabela
de smbolos para verificar a correo sinttica do texto da linguagem de

entrada.
Um gerador de cdigo que caminha pela rvore de sintaxe e gera o cdigo de
maquina abstrata.

3.5 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
razespor que os sistemas existem em diferentes configuraes. Configuraes podem ser
produzidas para diferentes computadores, para diferentes sistemas operacionais, incorporando
funes especificas de clientes.
Os gerentes de configuraes so responsveis por manter a rastreabilidade das
diferenas entre verses de software, para assegurar que as novas verses sejam derivadas de
maneira controlada e liberar novas verses para clientes certos no momento certo.

24

3.5.1

29.1 PLANEJAMENTO DE GERENCIAMENTO DE

CONFIGURAES

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.

3.5.2

29.1.1

IDENTIFICAO

DE

ITEM

DE

CONFIGURAO

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.
Durante o processo de planejamento de gerenciamento de configurao, voc decide
exatamente quais itens sero controlados. Planos de projetos, especificaes, projetos,
programas, e massa de dados de teste so normalmente mantidos como itens de configurao.
Todos os documentos que podem seruteis para a evoluo futura do sistema devem ser
controlados pelo sistema de gerenciamento de configurao.
O esquema de identificao de itens de configurao deve atribuir um nico nome
para todos os documentos sob controle de configurao. Esse nome pode refletir o tipo do
item, uma parte do sistema ao qual ele se aplica, o criador do item. 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. Portanto, voc pode
definir um esquema de hierarquia com nome.
Esquemas de nomes hierarquizados so simples e de fcil compreenso: algumas
vezes, podem mapear uma estrutura de diretrios usada para armazenar arquivos de projeto.

25

No entanto, refletem a estrutura de projeto na qual o software foi desenvolvido. Os nomes de

itens de configurao associam componentes com um projeto especifico e, dessa maneira,
reduzem as oportunidades para o reuso. Pode ser muito difcil encontrar componentes
relacionados.

3.5.3

29.1.2 BANCO DE DADOS DE CONFIGURAO

O banco de dados de configurao utilizado para registrar todas as informaes

relevantes sobre as configuraes de sistema e os itens de configurao. Voc usa o banco de
dados CM para auxiliar a avaliao do impacto das mudanas de sistema e para gerar
relatrios para a gerencia sobre o processo de CM. 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.
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.
Um banco de dados de configurao armazena informaes sobre itens de
configurao e referencia seus nomes num sistema de gerenciamento de verso ou depsito de
arquivos.

3.5.4

29.2 GERENCIAMENTO DE MUDANAS

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,

26

voc precisa de um conjunto de procedimentos de gerenciamento de mudanas apoiado por

ferramentas.
Procedimentos de gerenciamento de mudana dizem respeito a analise de custo e
beneficio das mudanas propostas, a aprovao das mudanas viveis e a rastreabilidade de
quais componentes do sistema foram alterados. O processo de gerenciamento de mudana
deve surtir efeito quando o software ou a documentao associada so colocados em baseline
pela equipe de gerenciamento de configuraes.
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. O
impacto da mudana no restante do sistema deve ser verificado. Isso envolve todos os
componentes afetados pela mudana. 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.

3.5.5

29.3 GERENCIAMENTO DE VERSES E RELEASES

Os processos envolvidos no gerenciamento de verses e relases preocupam-se com a

identificao e a manuteno da rastreabilidade das verses de um sistema. Gerentes de
verses idealizam procedimentos para assegurar que as verses de um sistema possam ser
recuperadas quando solicitadas e no sejam alteradas acidentalmente pela equipe de
desenvolvimento. Para produtos, os gerentes trabalham com a equipe de marketing, e , para
sistemas feitos sob encomenda, com os clientes, para planejar quando novos releases de um
sistema devem ser criados e distribudos para implantao.

27

Um release do sistema uma verso distribuda aos clientes. Cada release deve
incorporar novas funcionalidades ou ser planejado para uma plataforma diferente de
hardware.

3.5.6

29.3.1 IDENTIFICAO DE VERSES

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

Identificao baseada em atributos. Cada componente tem um nome (como o
nome do item de configurao, que no nico para diferentes verses) e um
grupo de atributos associados para cada verso, componentes so portanto,

identificados pela especificao de seus nomes e valores de atributos.

Identificao orientada a mudanas. Cada componente denominado como na
identificao baseada em atributos, mas tambm associado com uma ou mais
solicitaes de mudanas. Ou seja, considera se que cada verso de
componente foi criada em resposta a uma ou mais solicitaes de mudanas. A
verso de componente identificada pelo conjunto de solicitaes de
mudanas que se aplicam ao componente.

3.5.7

29.3.2 GERENCIAMENTO DE RELEASES

Um release de sistema uma verso do sistema distribudo para os clientes. Os

gerentes de release de sistemas so responsveis por decidir quando um sistema pode ser

28

liberado para os clientes, gerenciar o processo de criao do release e de meios de distribuio

e documentar o release para assegurar que ele pode ser recriado exatamente como foi
distribudo, se for necessrio.
A criao de um release um processo de criao de arquivos e documentos que inclui
todos os componentes do release do sistema. O cdigo executvel de programas e todos os
arquivos de dados associados devem ser coletados e identificados. Se os manuais a serem
lidos em computadores so distribudos, copias eletrnicas devem ser armazenadas com o
software. Finalmente, quando todas as informaes estiverem disponiveis, o diretrio do
release manipulado para a distribuio.
Quando um release de sistema produzido, ele deve ser documentado para assegurar
que possa ser recriado ipsis literis no futuro. Isso importante para sistemas embutidos de
ciclo de vida longo e feitos para os clientes, como aqueles que controlam maquinas
complexas.
Para documentar um release voc deve registrar as verses especificas dos
componentes de cdigo fonte usados para criar o cdigo executvel. Voc deve manter cpias
dos cdigos fonte e cdigo executvel, e de todos os arquivos de dados e de configurao.
Voc deve tambm registrar as verses do sistema operacional, as bibliotecas, os
compiladores e outras ferramentas usadas para construir o software. Elas podem ser
necessrias para construir exatamente o mesmo sistema em alguma data posterior.

3.5.8

29.4 CONSTRUO DE SISTEMAS

A construo de sistemas um processo de compilao e ligao de componentes de

software num programa que executa determinada configurao definida. Quando voc esta
construindo um sistema com base em seus componentes, voc deve pensar nas seguintes
questes:

Todos os componentes que compem um sistema foram includos nas

instrues de construo?
A verso apropriada de cada componente necessrio foi includa nas instrues

de construo ?
todos os arquivos de dados necessrios esto disponveis?

29

Se os arquivos de dados esto referenciados dentro de um componente, o nome

usado o mesmo que o do arquivo de dados na maquina alvo?

A verso apropriada do compilador e de outras ferramentas requeridas esta
disponvel? As verses atuais das ferramentas de software podem ser
incompatveis com as verses antigas usadas para desenvolver o sistema.

3.5.9

29.5

FERRAMENTAS

CASE

PARA

GERENCIAMENTO DE CONFIGURAES

Processos de gerenciamento de configuraes so normalmente padronizados e

envolvem aplicaes de procedimentos predefinidos. Eles requerem o gerenciamento
cuidadoso de grande quantidade de dados e essencial a ateno aos detalhes. Quando um
sistema est sendo construdo com base em verses de componentes, um nico erro de
gerenciamento de configurao pode significar que o software no ir operar adequadamente.
Consequentemente, o apoio de um ferramenta CASE essencial para o gerenciamento
de configurao. Essas ferramentas podem ser combinadas para criar uma rea de trabalho
para apoiar todas as atividades de CM.

4. PROGRAMAO PARA WEB II

4.1 FRAMEWORK
Vrias definies sobre framework so descritas na literatura, segundo Gamma et al.
(2002, p.42), um framework um conjunto de classes que cooperam entre si provendo assim
um projeto reutilizvel para uma especfica classe de software.

30

Os frameworks esto se tornando cada vez mais comuns e importantes. Eles so a

maneira pela qual os sistemas Orientados a Objetos conseguem a maior reutilizao
(GAMMA et al, 2002). Segundo o mesmo autor, o framework dita a arquitetura de sua
aplicao. Ele ir definir a estrutura geral, sua diviso em classes e objetos e em consequncia
as responsabilidades-chave das classes de objetos, como elas colaboram, e o fluxo de
controle.
Um framework pode incluir programas de suporte, bibliotecas de cdigo, linguagens
descript e outros softwares para ajudar a desenvolver e juntar diferentes componentes de um
projeto de software.
Os frameworks so projetados com o propsito de facilitar o desenvolvimento
desoftware, habilitando projetistas e programadores a gastarem mais tempo detalhando as
exigncias de negcio do software do que com detalhes tediosos de baixo nvel do sistema.

4.2 TIPOS DE FRAMEWORKS

Classifica-se um framework de acordo com duas dimenses: como ele utilizado e

onde utilizado. No tratamento de como um framework pode ser utilizado, ser analisado o
ponto de como introduzir as particularidades de uma aplicao. Neste sentido Willemann e
Ibarra (2007) os classificam em:
Caixa branca: so baseados na especializao por herana e sobrescrita de mtodos,
modificando assim as funcionalidades bsicas do framework.
Caixa preta: so os frameworks focados na composio, devendo utilizar as
funcionalidades

j presentes

no framework, ou

seja,

neste

tipo

de framework as

funcionalidades internas no podem ser vistas nem modificadas e devem-se utilizar as

interfaces fornecidas pelo framework. Neste framework as instanciaes e composies feitas
o que determinam as particularidades da aplicao.
Caixa cinza: so frameworks hbridos, misturam os dois focos, herana e composio,
ou seja, so frameworks baseados em herana (caixa branca) com algumas funcionalidades
prontas.
A seguir so apresentadas as formas de utilizao de um framework.

31

Frameworks de suporte ou de integrao midleware: oferecem servios de sistema de

baixo nvel, tais como dispositivos de interface para perifricos (drivers) e de acesso a
arquivos, sendo normalmente usados para integrar aplicaes e componentes distribudos,
como frameworks BORBA ORB, DCOM, implementaes do padro ODMG, entre outros
(MATOS, 2008).
Frameworks de

aplicao

ou

de

infraestrutura:

so frameworks que

cobrem

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

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

4.3 VANTAGENS E DESVANTAGENS

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

32

4.4 ESPECIFICAES DE PERSISTNCIA

De acordo com Campos (2010), so regras feitas para serem utilizadas no
desenvolvimento de aplicaes ORM em Java, essas especificaes so divididas em
JDO (Java Data Object), que mantida pela Apache e JPA (Java Persistence API),
que mantida pela Sun. Devido a seus desenvolvedores serem diferentes o cdigo dos
mtodos utilizados na persistncia ficou bem diferenciado, assim para explicar
devidamente as maneiras como pode ser feito as especificaes esto mais detalhadas
a seguir:

4.4.1

ESPECIFICAO JDO

De acordo com Campos (2010, p.27), o controle da persistncia dos objetos feito
utilizando a PersistenceManagerFactory e a PersistenceManager, ambas so encontradas no
pacote javax.jdo.

Persistence Manager Factory

De acordo com Datanucleus (2011) tipicamente usado para criao do banco, ela
prov o acesso a PersistenceManagers com objetos a serem persistidos, para ser utilizado com
a especificao JDO.

Persistence Manager

De acordo com Campos (2010, p.27), ela fornece mtodos para gerenciar a
persistncia de objetos, alterando o ciclo de vida deles. Para Datanucleus (2011), a criao da
persistncia realizada da seguinte maneira: depois de instanciado um Persistence Manager
Factory, isso lhe d a possibilidade da criao de PersistenceManager de acordo com Quadro
1, onde esses so usados para chamadas dos mtodos de persistncia.
Declarao
PersistenceManager pm = pmf.getPersistenceManager();
Quadro 1 Criao de PersistenceManager

Os mtodos usados para persistir dados usando esta especificao so demonstrados

no Quadro 2.

33

Operao

Mtodo

Persistir ou atualizar um objeto

pm.makePersistent(obj);
Object id = pm.getObjectId(obj); ou

Encontrando um objeto

Object obj = pm.getObjectById(id);

Excluir um objeto

pm.deletePersistent(obj);

Para atualizar no banco

em.refresh(obj);

Quadro 2 Mtodos de persistncia com especificao JDO

Fonte DATANUCLEUS (2011)

4.4.2

ESPECIFICAO JPA

De acordo com Datanucleus (2011), cria-se uma unidade de persistncia por ser um
componente requerido para comunicao com o banco de dados. Para realizar a persistncia
de dados utilizando essa especificao utilizam-se duas classes que de acordo com Campos
(2010), fazem o controle da persistncia, elas so Entity Manager Factory eEntity
Manager.

Entity Manager Factory

Para Campos (2010), seria a EntityManagerFactory que permite a utilizao do

banco de dados por via de EntityManager, para outros bancos de dados atribuda
uma instncia diferente dela.

Entity Manager

De acordo com Datanucleus (2011), EntityManager faz as operaes de persistncia

com o banco de dados para seus objetos. Para obter um EntityManager pode fazer conforme
apresentado na Quadro 3:
Declarao
EntityManager em = emf.createEntityManager();
Quadro 3 Obtendo EntityManager

34

Para persistir os dados por meio desta especificao podem-se usar os mtodos que
esto no Quadro 4.
Operao

Mtodo

Persistir objetos

em.persist(obj);

Encontrando um objeto

Object obj = em.find(cls, id);

Atualizar objetos

Object updatedObj = em.merge(obj);

Atualizar no banco

em.refresh(obj);
Objec obj = em.find(cls, id); e aps

Excluindo um objeto

em.remove(obj);
Quadro 4 Mtodos de persistncia especificao JPA
Fonte DATANUCLEUS (2011)

Quando for necessrio excluir um objeto dentro do banco de dados os passos seguintes
deve ser adotado:

Primeiramente deve-se ach-lo no banco atravs do comando: Object obj =

em.find(cls, id);
E em seguida com o objeto encontrado, deve-se executar o comando para
exclu-lo: em.remove(obj);

5. CONCLUSO
Um bom gerenciamento de projeto de software e fundamental para que os projetos os
projetos de engenharia de software sejam desenvolvido dentro do cronograma e do
oramento. Neste trabalho foi possvel ver que o gerenciamento de software diferente de
outras reas da engenharia ,pois o software intangvel, e existe um conjunto de experincias
que podem guiar o gerenciamento.

35

Foi possvel observar que os gerentes de software so responsveis por diversas

atividades, entre as quais o planejamento, a elaborao de estimativas e o desenvolvimento de
cronogramas do projeto. Tendo principalmente que estar atento aos riscos do projeto.

6. REFERNCIAS

HELDMAN, Kim. Gerncia de projetos, Guia para o exame official do PMI. 5 edio, PMI.
Campus, 2009.
SOMMERVILE, Ian. ENGENHARIA DE SOFTWARE. 8 Edio. So Paulo: Pearson
Addison Wesley, 2007.