Download - Trabalho Individual v Semestre
-
8/18/2019 Trabalho Individual v Semestre
1/28
-
8/18/2019 Trabalho Individual v Semestre
2/28
-
8/18/2019 Trabalho Individual v Semestre
3/28
SUMÁRIO
1 INTRODUÇÃO.......................................................................................................3
2 objetivo..................................................................................................................4
3 Engenharia e rojeto !e So"t#are......................................................................$
3.1 ri%&o%.....................................................................................................................$
3.2 e%&o'o...................................................................................................................(
3.3 "orne&e!ore%........................................................................................................)
3.4 'arte% intere%%a!a%.............................................................................................)
4 re%enha !o% &a'it*+o% 11, 12, 13 e 2- !o +ivro ian %oervi++e.....................-
4.1 'rojeto !e ar/*itet*ra..........................................................................................-4.2 De&i%0e% !e 'rojeto !e ar/*itet*ra..................................................................11
4.3 Organiao !e %i%tea....................................................................................12
4.3.1 Mo!e+o re'o%itrio.....................................................................................12
4.3.2 O o!e+o &+iente5%ervi!or.........................................................................13
4.3.3 O o!e+o e &aa!a%...............................................................................13
4.4 e%ti+o% !e !e&o'o%io o!*+ar...................................................................13
4.$ o!e+o% !e &ontro+e..........................................................................................144.$.1 6ontro+e &entra+ia!o.................................................................................14
4.$.2 Si%tea% orienta!o% a evento%.................................................................14
4.( ar/*itet*ra% !e re"eren&ia.................................................................................1$
4.) 7r/*itet*ra !e %i%tea% %*b!i%trib*i!o%........................................................1$
4.8 ar/*itet*ra% !e a'+i&a0e%................................................................................1(
4.- 9EREN6I7MENTO DE 6ON:I9UR7Ç;ES......................................................1)
4.-.1 +anejaento !e geren&iaento !e &on"ig*ra0e%...............................18
$ RO9R7M7ÇÃO 7R7 [email protected]
$.2 Re+a&ione o% &*%to%Abene"B&io% !e *%ar frameworks no !e%envo+viento
Web.............................................................................................................................2C
$.3 rograao ?ava Web >'+ata"ora !e !e%[email protected]
( RO?ETO 6IN7 TEE6OM.............................................................................24
(.1 7r/*itet*ra *%a!a e "rae#orF........................................................................24
(.2 a!r0e% !e 'rojeto% *ti+ia!o...........................................................................24
(.3 =an&o !e !a!o%.................................................................................................24
-
8/18/2019 Trabalho Individual v Semestre
4/28
) 6ON6USÃO......................................................................................................2(
RE:ERGN6I7S...........................................................................................................2)
-
8/18/2019 Trabalho Individual v Semestre
5/28
1 INTRODUÇÃO
Este trabalho é voltado as competências de riscos, escopo, fornecedores, e partes
interessadas, segundo o PMBoK.
O principal objetivo é deiar o leitor bem informado !uanto o uso das normas e
regras !ue na maioria das ve"es n#o aparece no final do produto, programas e
soft$are. %este caso abordaremos algumas fases da Engenharia de soft$are.
&nicialmente vamos falar sobre a engenharia e 'rojeto !e %o"t#are e também
rograao 'ara
-
8/18/2019 Trabalho Individual v Semestre
6/28
2 O=?ETIHO
-o final desta pes!uisa !uero deiar o leitor ou a !uem de alguma
forma tenha interesse no conhecimento de como normalmente s#o planejados e
documentados os programas, soft$are e tudo !ue envolvem a tecnologia do século
&, tendo acesso a um breve relato de como funciona.
/evo também salientar !ue a!ui é s0 uma pes!uisa superficial e depouca profundidade, levando em considera'#o de todo o conteto !ue envolve a
compleidade dos programadores, analistas e desenvolvedores modernos.
/efendendo a tese de !ue o bem maior da humanidade é a
informa'#o, é preciso ter dados bem normali"ados de boa !ualidade e acima de
tudo, bem protegidos.
1
-
8/18/2019 Trabalho Individual v Semestre
7/28
3 EN9EN7RI7 E RO?ETO DE SO:T
-
8/18/2019 Trabalho Individual v Semestre
8/28
de riscos vem se tornando cada ve" mais relevante neste conteto.
)abendo de todas estas possibilidades, preciso antes de !ual!uer in7cio de
um projeto, preciso levantar todas as informa'(es, para !ue meu projeto n#o
fracasse, embora n#o posso di"er >??@ !ue isto n#o v2 acontecer. Mas se eu posso
planejar atividades e responsabilidades, para o cumprimento de todas as metas,
preciso também prever riscos, !ue podem atrapalhar o desempenho na cria'#o do
meu projeto.
Entendo !ue posso dividir em três 2reas os riscos, sendoA
• iscos de projetosA onde posso identificar, problemas !ue podem ocorrer em
or'amento, cronograma, pessoal, recursos de clientes e re!uisito.
• iscos técnicosA problema com implementa'#o do projeto, interface
verifica'#o e manuten'#o.
• iscos do neg0cioA estes s#o os mais dif7ceis para serem detectados, por !ue
s0 ocorre !uando os produtos j2 est#o em fase de conclus#o do projeto ou
até mesmo j2 conclu7do.
Ca" parte das boas pr2ticas de cria'#o ou construtores de soft$are, a an2lise
de riscos. Der conhecimento das possibilidades de erros ou falhas antes das
mesmas surgirem ajuda na solu'#o das mesmas, com mais rapide" e menos custos.
3.2 ES6OO
O gerenciamento do escopo, tem o objetivo principal, definir e manter o
desenvolvimento do projeto dentro do !ue foi desenhado, controlando o !ue deve e
o !ue n#o deve estar inclu7do no projeto, tendo a seguran'a, !ue é realmente a
necessidade do cliente, e !ual!uer mudan'a !ue venha acontecer dever2 ter oconsentimento do cliente.
ealmente o escopo é de grande import;ncia e a mudan'a s0 tem !ue
acontecer se eistir uma situa'#o onde isto é realmente inevit2vel, por !ue além de
mudar todo o projeto inicial, gerando custos etras, onde talve" o cliente n#o !ueira
arcar.
/epois de definido todos os, re!uisitos e ferramentas necess2rias para um
determinado projeto, depois colocado tudo no papel e validado com seu cliente,
segue o escopo palavra de origem grega !ue significa 3a!uele !ue vigia, !ue
protege4, a meta !ue foi determinada ser2 registrada e seguida pelo escopo.
-
8/18/2019 Trabalho Individual v Semestre
9/28
3.3 :ORNE6EDORES
Est2 2rea também conhecida como 3-!uisi'(es4 tem como atribui'#o
descrever os processos de compras ou ad!uirir produtos, servi'os ou resultados
além de gerenciar projetos. %esta 2rea também tem o objetivo de determinar o !ue
se !uer ad!uirir, de !uem se !uer ad!uirir, receber as respostas dos fornecedores e
selecionar o fornecedor, como se dar2 o gerenciamento dos contratos, pagamentos,
se as entregas est#o de acordo com o !ue foi estabelecido, pagar o fornecedor, e
por 8ltimo formali"ar a finali"a'#o do contrato.
Os processos dessa 2rea s#oA planejar as a!uisi'(es, reali"ar as a!uisi'(es,
administrar as a!uisi'(es e encerrar as a!uisi'(es.Entende:se por fornecedores, todas as pessoas ou departamentos !ue de
alguma forma, fornece pe'as, matérias, substancias ou !ual!uer outro material
necess2rio para o desenvolvimento de um projeto.
.1 7RTES INTERESS7D7S
Ca"endo saber !ue 3partes interessadas4 do termo staFeholdes, s#o todas as
pessoas e organi"a'(es envolvidas no projeto, ou cujos interesse podem ser
positivas ou negativamente afetadas pela reali"a'#o ou pelos resultados do grupo.
Podendo estas eercer influência sobre o projeto e sobre os membros da
e!uipe do projeto.
Guando se inicia um projeto a e!uipe de gerenciamento, precisa identificar as
partes interessadas internas e eternas. -o longo do planejamento e da eecu'#o
do projeto, o gerente do projeto e sua e!uipe devem gerencia as diferentes
necessidades, preocupa'(es e epectativas das partes interessadas, bem como a
influência destas no projeto, para garantir um resultado bem:sucedido.
Podemos descrever alguns eemplos de poss7veis partes interessadasA
• PatrocinadorA pessoa ou grupo !ue fornece os recursos financeiros para a
reali"a'#o do projeto, e !ue também provê o aval estratégico e pol7tica !ue
viabili"a e promove o objeto e o defendeH
• - e!uipe do projeto, !ue inclui gerente do projeto, a e!uipe de gerenciamento
do projeto, e todo restante da e!uipe !ue eecutam o trabalho no projeto e
n#o est#o necessariamente envolvidas com gerenciamentoH
I
-
8/18/2019 Trabalho Individual v Semestre
10/28
• Jlientes e usu2riosH
• Presidentes, donos e eecutivosH
• -cionistas e investidoresH
• Cornecedores e parceiros comerciaisH
• JoncorrentesH
• overnos, em suas diferentes esferas e poderesH
• Etc.....
Outros elementos !ue influenciam projetos s#o culturas e estilos
organi"acionais, bem como os fatores ambientais da empresa do mercado, da
sociedade e da locali"a'#o geopol7tica onde o projeto acontece.
*
-
8/18/2019 Trabalho Individual v Semestre
11/28
4 RESEN7 DOS 67ITUOS 11, 12, 13 E 2- DO IHRO I7N SOMMERHIE
O livro usado para perceber estas informa'(es, é destinado aos estudantes
dos cursos de gradua'#o e p0s:gradua'#o e a engenheiros de soft$are !ue atuam
no comercio e na ind8stria.
Ele pode ser usado em cursos de engenharia de soft$are em geral ou em
outros cursos, como os de programa'#o avan'ada, especifica'#o de soft$are,
projeto ou gerenciamento de soft$are.
/esta forma faremos uma pe!uena men'#o em forma de resenha dos
cap7tulos citados, inclusive usando a sua estrutura.
1.> RO?ETO DE 7RUITETUR7
Objetivo%
O objetivo deste capitulo apresentar os conceitos de ar!uitetura de soft$are e
projeto de ar!uitetura. -p0s ler este cap7tulo, vocêA
Jompreendera por !ue o projeto de ar!uitetura de soft$are é importanteH )aber2 !uais decis(es devem ser tomadas sobre a ar!uitetura de sistema
durante o processo de projeto de ar!uiteturaH Der2 sido apresentado a três estilos complementares de ar!uitetura !ue
abrangem, a organi"a'#o geral, decomposi'#o modular e controle de
sistemasH Jompreender2 como as ar!uiteturas de referências s#o usadas para
comunicar conceitos ar!uiteturas e para avaliar ar!uiteturas de sistemas.
6onteJ!o
>>.> /ecis(es de projeto de ar!uitetura
>>.L Organi"a'#o de sistema
>>. Estilo de decomposi'#o modular
>>.1 Modelos de controle
>>.= -r!uiteturas de referencia
-
8/18/2019 Trabalho Individual v Semestre
12/28
Os sistemas chamados grandes s#o sempre decompostos ou divididos em
subsistemas !ue fornecem algum conjunto de servi'os relacionados, sendo !ue é da
fun'#o da ar!uitetura de soft$are identificar estes subsistemas e estabelecer um
frame$orF, para controlar a comunica'#o entre estes subsistemas.
O processo de projeto de ar!uitetura envolve o estabelecimento de um
frame$orF b2sico, com fun'#o especifica a identificar estas comunica'(es entre os
subsistemas.
Bass et al.L?? eplica três vantagens de projetar e documentar uma
ar!uitetura de soft$areA
>. Jomunica'#o de staFeholders. - ar!uitetura é uma vis#o de auto n7vel do
sistema, !ue pode ser usada em outras fases do sistema.L. -nalise do sistema. Dornar a ar!uitetura do sistema eplicita no in7cio do
desenvolvimento do sistema re!uer alguma an2lise. -s decis(es tomadas no
in7cio, ter2 um efeito na !ualidade final do sistema.. euso em grande escala. . /esempenho. )e o desempenho for um re!uisito critico, a ar!uitetura deve
ser j2 projetada, para locali"ar opera'(es cr7ticas dentro de alguns
subsistemas, com t#o pouca comunica'#o entre eles.L. Prote'#o. )e a prote'#o for o re!uisito critico, tem !ue usar uma estrutura
em camadas, onde estes itens ser#o protegidos, com alto n7vel de valida'#o.
>?
-
8/18/2019 Trabalho Individual v Semestre
13/28
. )eguran'a. )e a seguran'a for um re!uisito critico, precisa colocar as
opera'(es voltadas a elas em um 8nico ou pe!ueno n8mero de subsistemas.
Evitando problemas de valida'#o e custos.
1. /isponibilidade. )e a disponibilidade for um re!uisito critico, precisa ter componentes redundantes e assim !ue poss7vel substituir e atuali"ar, sem
parar o sistema.=. Cacilidade de manuten'#o. )e a facilidade de manuten'#o for o item critico,
deve projetar com baia granularidade.
Podemos di"er !ue a decomposi'#o de ar!uitetura é necess2ria para
estruturar, organi"ar e especificar, os sistemas maiores, onde cada diagrama de
bloco representaria um subsistema substancial ou independente.%aturalmente, n#o é uma decis#o f2cil, em decompor um sistema em
subsistemas, pois tem !ue ficar atento aos re!uisitos, se eles mudam provavelmente
ser2 locali"ada a mudan'a e n#o distribu7da entre os subsistemas.
4.2 DE6IS;ES DE RO?ETO DE 7RUITETUR7
O projeto de ar!uitetura é um processo !ue re!uer além de muito
conhecimento do ar!uiteto, precisa !ue o mesmo eer'a seu senso criativo, pois
durante o processo eistem muitas perguntas !ue precisam ser respondidas, com
uma resposta satisfat0ria, pois s#o vitais para o funcionamento ou n#o do projeto.
E s#o elasA
>. Eiste uma ar!uitetura genérica de aplica'#o !ue possa funcionar como
modelo para o sistema !ue est2 sendo projetadoL. Jomo o sistema ser2 distribu7do ao longo de v2rios processadores. Gual ou !uais os modelos de ar!uitetura s#o apropriados para o sistema1. Gual ser2 a abordagem fundamental usada para estruturar o sistema=. Jomo as unidades estruturais de um sistema ser#o decompostas em
m0dulos. Gual estratégia ser2 usada para controlar a opera'#o das unidades no
sistemaI. Jomo o projeto de ar!uitetura ser2 avaliado
*. Jomo a ar!uitetura do sistema deve ser documentadaEmbora cada sistema de soft$are seja 7mpar, eles na maioria das ve"es, tem
>>
-
8/18/2019 Trabalho Individual v Semestre
14/28
suas ar!uiteturas parecidas.
Ent#o ao projetar você deve escolher !uanto do conhecimento das ar!uiteturas
você poder2 reusar.
- ar!uitetura pode ser do tipo, um cliente:servidor ou em camadas.
O processo de projeto de ar!uitetura é um documento, onde também pode se
incluir representa'(es gr2ficas e tetos descritivos associados, como est2
estruturado o sistema em seus subsistemas, !ual foi a abordagem adotada e como
est2 estruturado os subsistemas nos m0dulos. -ssim sendo os modelos de
ar!uitetura a ser desenvolvidos podem incluir.
>.
-
8/18/2019 Trabalho Individual v Semestre
15/28
4.3.2 O o!e+o &+iente5%ervi!or
Este modelo de ar!uitetura é um modelo em !ue o sistema é organi"ado
como um conjunto de servi'os e servidores e clientes associados !ue acessam e
usam os servi'os. %este modelo tem os seguintes componentesA
>. Os servidores !ue guardam os servi'os dados, para os clientes.L.
-
8/18/2019 Trabalho Individual v Semestre
16/28
decomposto em subsistemas. Para !ue os subsistemas entreguem seus servi'os no
lugar e tempo certo é utili"ado os modelos de controle !ue lidam com o fluo de
controle entre subsistemas.
Eistem dois estilos genéricos de controles usados em sistemas de soft$areA
>. Jontrole centrali"ado. Onde um subsistema gerencia os outros, iniciando e
parando os outros.L. Jontrole baseado em eventos. %este caso ao invés de um subsistema
gerenciar, cada subsistema pode responder a eventos gerados eternamente.
Estes modelos de controles s#o usados em conjunto de estruturas.
1.=.> 6ontro+e &entra+ia!o
Jomo disse antes este modelo um subsistema é designado como controlador
e tem a responsabilidade de gerenciar a eecu'#o dos outros. Este tipo ainda é
dividido em duas classes.
>. Modelo chamada:retorno. Este é o conhecido modelo top:do$n de sub:rotina
onde este controle come'a no topo.L. O modelo gerenciador. Este modelo é aplic2vel a sistemas concorrentes.
4.$.2 Si%tea% orienta!o% a evento%
Em modelos de controles centrali"ados as decis(es de controle s#o
geralmente determinadas pelos valores de algumas vari2veis de estado do
sistema.
Estes s#o regidos pelos eventos eternos, n#o precisar ser um sinal bin2rio,
neste caso um sinal pode assumir uma série de eventos ou entrada, baseada em
menu.
- diferen'a entre um evento e uma entrada simples é !ue o evento est2 fora
de controle do processo !ue o manipula.
4.( 7RUITETUR7S DE RE:EREN6I7
Os modelos ar!uiteturais anteriores s#o modelos gerais, podendo ser aplicados em muitas classes e aplica'(es. Jomo estes modelos gerais podem
>1
-
8/18/2019 Trabalho Individual v Semestre
17/28
ser aplicados os espec7ficos também podem ser usados, embora sejam
diferentes em suas instancias, suas estruturas comuns podem ser reutili"adas.
- finalidade principal da ar!uitetura referenciada é ser um meio de
classifica'#o e compara'#o de ferramentas case integrados. -lém disso, ela
pode ser usada para ensinar, destacando as caracter7sticas principais desses
ambientes, e para discuti:los de maneira genérica.
1.I 7RUITETUR7 DE SISTEM7S SU=DISTRI=UIDOS
Guase todos os sistemas baseados em grandes computadores s#o sistemas
distribu7dos. )endo a!ueles !ue as informa'(es em fase de processamento s#odistribu7das em v2rias ma!uinas, em ve" de ficar s0 em um local.
- engenharia de sistema distribu7do e soft$are tem muito em comum, mas
eistem !uest(es especificas !ue devem ser levadas em conta ao projetar esse tipo
de sistema.
)#o vantagens de se usar umas abordagens de desenvolvimento de
sistemas distribu7dosA
>. )#o sistemas !ue permite o compartilhamento de recursos de
hard$are e soft$are, como discos, impressoras, ar!uivos e compiladores !ue
podem estar em diferentes computadores na rede.L. )#o sistemas !ue geralmente permite a combina'#o de e!uipamentos
e soft$ares de fabricantes diferentes.. Em termos de concorrência no sistema distribu7do, v2rios processos
podem operar ao mesmo tempo e em computadores diferentes.1. )#o sistemas escalon2veis, permitindo a implementa'#o de novos
recursos a atende 9 demanda futura.
=. )#o mais tolerantes a defeitos.Os sistemas distribu7dos podem suportar compartilhamentos de recursos,
abertura, concorrência, escalabilidade, toler;ncia a defeitos e transparência.
Os sistemas cliente:servidor s#o sistemas distribu7dos nos !uais o sistema é
modelado como um conjunto de servi'os fornecidos por servidores para processos
clientes.
Em um sistema cliente:servidor, a interface com o usu2rio sempre funciona
em um cliente, e o gerenciamento de dados é fornecido pelo servidor compartilhado.Em uma ar!uitetura de objetos distribu7dos n#o h2 distin'#o entre cliente e
>=
-
8/18/2019 Trabalho Individual v Semestre
18/28
servidores. Os objetos fornecem servi'os gerais !ue podem ser chamados a partir
de outros objetos.
Os sistemas de objetos distribu7dos re!uerem um middle$are para cuidar
das comunica'(es entre os objetos e permitir !ue os objetos sejam adicionados e
removidos do sistema.
Os padr(es JOB- s#o um conjunto de padr(es para middle$are !ue
suporta ar!uitetura de objetos distribu7dos.
-s ar!uiteturas ponto a ponto s#o ar!uiteturas descentrali"adas nas !uais
n#o h2 clientes e servidores distintos. -s computa'(es podem ser distribu7das em
muitos sistemas e organi"a'(es diferentes.
)istemas orientados a servi'os s#o criados pela liga'#o de servi'os desoft$are fornecidos por v2rios fornecedores de servi'os. . Jomo um ponto de partida para o processo de projeto de ar!uitetura.L. Jomo um checFlist do projeto. )e você desenvolveu um projeto de
ar!uitetura de sistema, é poss7vel par2:lo com a ar!uitetura genérica de aplica'(es,
para checar se falta considerar algum componente importante de projeto.. Jomo uma maneira de organi"a'#o do trabalho da e!uipe de
desenvolvimento.1. Jomo meio de avalia'#o de componentes para reuso.
=. Jomo vocabul2rio para conversar sobre tipos de aplica'(es.
>
-
8/18/2019 Trabalho Individual v Semestre
19/28
4.- 9EREN6I7MENTO DE 6ON:I9UR7Ç;ES
O gerenciamento de configura'#o é o desenvolvimento e o uso de padr(es e
procedimento para o gerenciamento de sistemas de soft$are em desenvolvimento.
Estes procedimentos de gerenciar as configura'(es definem como registrar
e processar mudan'as de sistema, como relaciona:los aos componentes do sistema
e os métodos usados para identificar diferentes vers(es dele. Estas ferramentas s#o
usadas para arma"enar vers(es de componentes do sistema. )istemas constru7dos
com base nesses componentes e rastrear os releases da vers#o do sistema para
clientes.Este gerenciamento muitas das ve"es s#o considerados parte do
gerenciamento de !ualidade do soft$are, onde o mesmo gerente fica respons2vel
pelas duas facetas do gerenciamento.
Pensando na situa'#o real, onde eistem diversas configura'(es diferentes,
para computadores diferentes, clientes diferentes, setores diferentes, o gerente de
configura'(es tem as responsabilidades de manter a rastreabilidade, assegurando
!ue as novas vers(es sejam derivadas de maneira controlada e liberar novasvers(es para clientes certos no momento certo.
O gerenciamento de configura'(es nos projetos 2geis e r2pido n#o pode
estar baseado em procedimentos burocr2ticos pois desacelera o processo do
desenvolvimento. -ntes seja usado nos projetos mais compleo e grandes.
Preferencialmente para os processos 2geis usam ferramentas simples de JM.
4.-.1 +anejaento !e geren&iaento !e &on"ig*ra0e%
Este gerenciamento é onde descrevemos os padr(es e procedimentos !ue
devem ser usados para o gerenciamento, o conjunto de padr(es de configura'#o é o
ponto de partida para o desenvolvimento do plano.
%este plano j2 deve ser definido as responsabilidades tem !ue ser definidos
!uem ir2 entregar a cada documento ou componentes do soft$are, enfim, todos os
respons2veis, tem !ue ser definidos a!ui.
>I
-
8/18/2019 Trabalho Individual v Semestre
20/28
>*
-
8/18/2019 Trabalho Individual v Semestre
21/28
$ RO9R7M7ÇÃO 7R7
-
8/18/2019 Trabalho Individual v Semestre
22/28
estendidos pelo -isL e !ue implementam padr(es de Seb service, tais comoA
-pache )andechaL !ue implementa o padr#o S):eliableMessaging, -pache
KandulaL !ue implementa os padr(es S):Joordination e S):-tomicDransaction e
-pache ampart !ue implementa o padr#o S):)ecurit.
-P-JNE JC -pache JC é um frame$orF open:source para a linguagem
Tava amplamente utili"ado pelo mercado !ue provê suporte na cria'#o e consumo
de Seb services utili"ando as especifica'(es T-:S) e T-:). -inda oferece
suporte a v2rios protocolos de mensagem e transporte.
Balani e Nathi 5L??, p. L? X Dradu'#o nossa6 afirmam !ue o JC 3é
desenvolvido com a miss#o de prover uma infraestrutura robusta para o
desenvolvimento de Seb services e facilitar o processo de desenvolvimento4. -pache JC surgiu a partir de dois projetosA Jelti e Cire e, por isso, o nome
JC. Jelti é um projeto open:source E)BL= baseado na linguagem Tava
desenvolvido pela ObjectSeb, uma empresa !ue desenvolve solu'(es open:source
de middle$are. T2 o Cire é um frame$orF open:source baseado em Tava para
desenvolvimento de Seb services baseados no protocolo )O-P desenvolvido pela
Jodehaus.
/urante as vers(es iniciais de ambos os projetos, foi constatado !ue haviamuitas caracter7sticas em comum entre eles e !ue era poss7vel transform2:los em
um 8nico projeto. - partir dessa constata'#o, foi desenvolvido com a ajuda da
-pache )oft$are Coundation, o -pache JC L.?
Outra caracter7stica importante do JC é a sua integra'#o com o )pring
frame$orF. Essa integra'#o permite utili"ar ar!uivos de configura'#o do )pring
frame$orF para !ue a publica'#o de endpoints seja feita de forma mais simples.
-pache JC conta ainda com v2rias ferramentas de apoio para odesenvolvimento de servi'os eYou consumidores. )egundo -pache JC 5L?>6,
eistem ferramentas para gera'#o de c0digo, gera'#o de documentos S)/R,
adi'#o de endpoints, gera'#o de ar!uivos de suporte e valida'#o de ar!uivos.
=.L RE76IONE OS 6USTOSA=ENE:L6IOS DE US7R FRAMEWORKS NO
DESENHOHIMENTO WEB.
L?
-
8/18/2019 Trabalho Individual v Semestre
23/28
)e o frame$orF estiver pronto, os benef7cios s#o claros em termos deA
• edu'#o de custos
•
edu'#o de time:to:marFet
Motivo%
• Maimi"a'#o de reuso 5an2lise, design, c0digo, testes6
• /esenvolvedores se concentram em adicionar valor em ve" de reinventar a
roda
• Menos manuten'#o
• Catora'#o de aspectos comuns a v2rias aplica'(es•
-
8/18/2019 Trabalho Individual v Semestre
24/28
• Guem pode pensar em longo pra"o !uando se est2 competindo ZOn &nternet
timeZ
•
-
8/18/2019 Trabalho Individual v Semestre
25/28
aplica'#o 5visual6 !ue dever#o ocorrer ap0s dois anos a partir da conclus#o do
sistema é um eemploH
• estri'(es X -ssim como visto no cap7tulo anterior, as restri'(es s#o
condi'(es n#o negoci2veis !ue afetam o projeto, tais como or'amento e
cronograma.
$.4 7RUITETUR7 US7D7 E :R7ME
-
8/18/2019 Trabalho Individual v Semestre
26/28
Entendo !ue nos sgdbsA
• /ados !ue re!uerem atuali"a'#o com n7veis finos de granularidade por
m8ltiplos usu2riosH
• /ados !ue devem ser acessados por v2rias aplica'(es
• randes !uantidades de dados !ue devem ser eficientemente manipulados
• /ados de longa dura'#o e muito valiosos a uma organi"a'#o
• /ados !ue devem ser acessados com sofisticado controle de seguran'a
• /ados sujeitos a an2lise sofisticada para o apoio 9 decis#o
Bom, como vou est2 usando a metodologia Dropos, a mesma n#o fala nada sobre a
fase de implementa'#o. %o entanto esta metodologia tem um alto refinamento do
sistema na sua fase final, teremos algumas feramentas J-)E, !ue d#o suporte a
metologia, cobrindo a fase de implementa'#o e montando o es!ueleto de c0digo
para frame$orF, como TacF, Tade, Tade, etc.
L1
-
8/18/2019 Trabalho Individual v Semestre
27/28
( 6ON6USÃO
Este trabalho foi proveitoso no sentido de conhecer mais as
ferramentas para desenvolvimento de soft$are, projetos e ar!uiteturas, bem como o
uso de frame$orFs, e persistência de dados.
Enfim, foi um apanhado de como é criterioso e anal7tico a confec'#o
de um bom soft$are onde entendi !ue um bom soft$are tem !ue ser bem planejado
e estruturado para se tornar efica".
L=
-
8/18/2019 Trabalho Individual v Semestre
28/28