CAPITULO11 – Projetode Arquitetura
O projetode arquiteturaé primeiroestágionoprocessode projetos.Dizolivroque ele
idêntifi...
Comoas unidadesestruturaisde umsistemaserãodecompostasemmódulos?
Qual estratégiaseráutilizadaparacontrolara operaçãodas un...
4 O ModeloemCamadas
O modeloemcamadasorganizaum sistemaemcamadas,cada uma das quaisfornecendoum
conjuntode serviços.
A abo...
7 Pipeliningorientadoafunções
No pipeliningorientadoafunçõesoumodelode fluxode dados,astransformaçõesprocessam
suas entrad...
projetadocomoum gerenciadorde sistemae controlao inicio,aparada e a coordenaçãode
outrosprocessosdosistema.
Sistemasorient...
CAPITULO12 – Arquiteturade sistemasdistribuídos
Um sistemadistribuídoé aquele emque asinformaçõesemfase de processamentosã...
O multiprocessadorSãoprocessosque podemserexecutadosseparados.Esse modelotomam
decisõesusandoessasinformaçõese enviamsinai...
3 Arquiteturasde objetosdistribuídos
Nesse modeloosobjetospodemserdistribuídosentre umaserie de computadoresnarede e
se co...
O objetoque fornece oserviçotemumesqueletode IDLassociadoque ligaa interface a
implementaçãodosserviços.
O corba foi desen...
TodosessespadrõessãobaseadosemXML
CAPITULO13 – Arquiteturade aplicações
1 sISTEMASDE PROCESSAMENTODE DADOS
Aplicaçõesde pr...
entrada/saída.A solicitaçãoé processadaporalgumalógicaespecificadaaplicação.Uma
transação é criada e passadapara um gerenc...
5- um modulode autenticaçãode usuáriosque permite aosistemaverificarse osrecursos
estãosendoalocadospara umusuárioreconhec...
capitulo29 – gerenciamentode configurações
Gerenciamentode configuraçõesé odesenvolvimentoe ousode padrõese procedimentos
...
2 BANCODE DADOSDE CONFIGURAÇÃO
O banco de dadosde configuraçãoé utilizadopararegistrartodasas informaçõesrelevantes
sobre ...
recuperadasquandosolicitadase nãosejamalteradasacidentalmentepelaequipede
desenvolvimento.Paraprodutos,osgerentestrabalham...
tambémregistraras versõesdosistemaoperacional,asbibliotecas,oscompiladorese outras
ferramentasusadasparaconstruiro softwar...
Próximos SlideShares
Carregando em…5
×

RESENHA DOS CAP. 11,12, 13, e 29 do livro Engenharia de software

268 visualizações

Publicada em

Resenha do livro engenharia de software

Publicada em: Tecnologia
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
268
No SlideShare
0
A partir de incorporações
0
Número de incorporações
3
Ações
Compartilhamentos
0
Downloads
7
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

RESENHA DOS CAP. 11,12, 13, e 29 do livro Engenharia de software

  1. 1. CAPITULO11 – Projetode Arquitetura O projetode arquiteturaé primeiroestágionoprocessode projetos.Dizolivroque ele idêntificasubsistemase estabelece umframeworkparacontrolaracomunicaçãodos subsistemas. Subsistemassãosistemasgrandes decompostos e que fornece algumconjunto de serviçosrelacionados oque representaumaligaçãocriticaentre processosde engenharia de projetoe requisitos. Três vantagensde projetare documentarexplicitamente umaarquiteturade software: Comunicação destakeholders:é uma apresentaçãoemaltonível dosistemaque enfocaa discussãoentre diferentesstakeholders. Analisede sistemas:tem um profundoefeitosobre osistema,mostrase osistemapara atenderaosrequisitoscríticosbem como: confiabilidade,desempenhoe facilidade de manutenção. Reuso em larga escala:apoiao reusoem largaescalade sistemasque possuemarquiteturas de sistemasfamiliares. A arquiteturade software serve paranegociarrequisitosde sistemae estruturardiscussões com os clientes,desenvolvedorese gerentes.Éumaferramentaessencialparagerenciamento de complexidade,ocultandodetalhese focandoasabstraçõesprincipaisdosistema.Oestiloe estruturada aplicaçãodependemdosrequisitosnãofuncionaisdosistema,porexemplo: Se o desempenhoforumrequisitocríticoa aplicaçãodeve localizaroperaçõescríticasdentro de subsistemase usarcomponentesde altagranularidadeemdetrimentodosde baixa granularidade parareduziracomunicaçãoentre eles. Se a facilidade de manutençãoforumrequisitocrítico,aarquiteturade sistemasdeve ser projetadausandocomponentesde baixagranularidade e autocontidosque possamser prontamente mudados. Parou aqui.......Háconflitospotenciaisentre algumasdessasarquiteturas,porexemplose o desempenhoque necessitade altagranularidadee afacilidade de manutençãoque necessita de baixagranularidade foremambosrequisitoscríticosteráque ser encontradaalguma soluçãoeficaz. Um projetode subsistemasé decomposiçãoabstratade umsistemade componentesemalta granularidade.Osdiagramasde blocossãousadospara representarumprojetode subsistemas. Essesdiagramasde blocossão bonspara comunicaçãoentre stakeholderse parao planejamentodoprojetopoisnãoestãoabarrotadosde detalhes,jáparaa arquiteturanãosão tão bons,poisnão mostramrelacionamentoentre oscomponentesdosistema. O projetode arquiteturatentaestabelecerumaorganizaçãode sistemasque satisfaçãoos requisitosfuncionaise osnão funcionaisdosistema.Durante oprocessode projetode arquiteturaosarquitetosde sistemasdevemresponderaalgumasperguntas: Existe umaarquiteturagenéricade aplicaçãoque possafuncionarcomoummodeloparao sistemaque estásendoprojetado? Comoo sistemaserádistribuídoaolongode váriosprocessadores? Qual ou quaisestilosde arquiteturasãoapropriadosparaosistema? Qual será a abordagemfundamental usadaparaestruturarosistema?
  2. 2. Comoas unidadesestruturaisde umsistemaserãodecompostasemmódulos? Qual estratégiaseráutilizadaparacontrolara operaçãodas unidadesdosistema? Comoo projetode arquiteturaseráavaliado? Comoa arquiteturadosistemadeve serdocumentada? Ao Projetarumaarquiteturade sistemas,você precisadecidiroque seusistemae classesmais amplasde aplicaçãotemem comum,e decidirquantoconhecimentodessasarquiteturasde aplicaçãovocê pode reusar.A arquiteturade umsistemade software pode serbaseadaemum modeloouestilode arquiteturaespecifico,Emalguns casosa arquiteturageral de um sistema pode seruma arquiteturacomposta. Os modelosde arquiteturaque podemserdesenvolvidospodemincluir: Um modeloestáticode estruturaque mostraossubsistemasoucomponentesdesenvolvidos como unidadesseparadas. Um modelodinâmicode processoque mostracomoo sistemaestaorganizadoemprocessos emtempode execução. A organizaçãode um sistemareflete aestratégiabásicausadapara estruturá-lo.Você precisa tomar decisõessobre omodelogeral organizacional de umsistemacomantecedênciano processode projetode arquitetura.A organizaçãopode refletirdiretamente naestrutura subsistema. possuemtrêsestilosde organizacionaisamplamenteusados: Modelode repositório Os subsistemasque constituemumsistemadevemtrocarinformaçõesde mofoque possam trabalharjuntoseficientemente. Esse modeloé,portanto,adequadoparaaplicaçõesemque osdadossão geradospor um subsistemae usadosporoutro. O repositórioé passivoe ocontrole é de responsabilidade dossubsistemasque ousam. 3 ModeloCliente –Servidor O modelode arquiteturacliente –servidoré ummodeloemque osistemaé organizadocomo um conjuntode serviçose servidorese clientesassociadosque acessame usamosserviços.Os clientestalvezprecisemsaberosnomesdosservidoresdisponíveise osserviçosque eles fornecem.Noentantoosservidoresnãoprecisamsaberaidentidade doclienteouquantos são. Sãoacessadosos serviçospormeiode chamadasremotasde procedimentousandoum protocolorequest–eply,oclientefazumpedidoaum servidore esperaate receberuma resposta. A vantagemde ummodelocliente servidoré que ele é umaarquiteturadistribuída.Ouso efetivode sistemasemrede pode serfeitocommuitosprocessadoresdistribuídos.Éfácil adicionarumnovoservidore integrá-loaorestante dosistema
  3. 3. 4 O ModeloemCamadas O modeloemcamadasorganizaum sistemaemcamadas,cada uma das quaisfornecendoum conjuntode serviços. A abordagememcamadas apoiao desenvolvimentoincremental de sistemas.A medidaque uma camada é desenvolvidaalgunsserviçosfornecidosporessacamadapodemser disponibilizadosparaosusuários.Essa arquiteturatambémé modificávele portável.Desde que sua interface permaneçainalterada,umacamadapoderásersubstituídaporoutra equivalente.Umadesvantagemdaabordagememcamadasé que a estruturaçãode sistemas dessamaneirapode serdifícil.Ascamadasmaisinternaspodemfornecerrecursosbásicos, como gerenciamentode arquivos,necessáriosemtodososníveis. O desempenhotambémpode serumproblemadevidoaosváriosníveisde interpretaçãode comandosalgumasvezesexigidos. 5 Estilosde decomposiçãomodular Depoisque a organizaçãogeral dosistemafoi escolhida,precisa-se tomarumadecisãosobre a abordagema serusada na decomposiçãode subsistemasemmódulos. Um moduloé normalmente umcomponentede sistemaque fornece umoumaisserviçospara outrosmódulos.Ele fazusode serviçosfornecidosporoutrosmódulos.existemduas estratégiasprincipaisque você pode usaraodecomporum subsistemaemmódulos. Decomposiçãoorientadaaobjetose pipeliningorientadoafunções. Você deve evitartomardecisõesprematurassobre asimultaneidadede umsistema. 6 DECOMPOSIÇÃOORIENTADA A OBJETOS. Um modelode arquiteturaorientadoaobjetosestruturaosistemaemumconjuntode objetos não firmemente acopladoscominterfacesbemdefinidas.Osobjetoschamamserviços oferecidosporoutrosobjetos. Uma decomposiçãoorientadaaobjetosesta relacionadaaclassesde objetos,seusatributose suas operações.Quandoimplementados,osobjetossãocriadosapartir dessasclassese algum modelode controle é usadopara coordenaras operaçõesde objetos.A vantagemé que implementaçãode objetospode sermodificadasemafetaroutrosobjetos. A desvantagemé que parausar serviçososobjetosdevemfazerreferenciaexplicitaaonome e a interface de outrosobjetos.
  4. 4. 7 Pipeliningorientadoafunções No pipeliningorientadoafunçõesoumodelode fluxode dados,astransformaçõesprocessam suas entradase produzemsaídas.Os dadosfluemde umapara outra funçãoe são transformadosaomoverem – se sequencialmente.Cadaetapaé implementadacomouma transformação.Osdadosde entradafluematravésdessastransaçõesate seremconvertidos emdados se saída. As vantagensdessaarquiteturasão: Apoiaro reusode transformações. Ele é intuitiva,muitaspessoaspensamemseutrabalhoemtermosde processamentode entradae saída. A evoluçãodosistemapelaadiçãode novastransformaçõesé geralmente direta. Ela é simplesde serimplementadatantoquantoumsistemaconcorrente ousequencial. O principal problemaé que ele necessitaserumformatocomumpara transferirdadosque possaser reconhecidoportodasas transformações. Sistemasinterativossãodifíceisde escreverusandoessemodeloporcausada necessidade de uma sequenciade dadosserprocessada. 8 Modelosde controle Os modelosde controle temcomoobjetivocontrolarsubsistemasde maneiraque seus serviçossejamentreguesnolugarcertoe notempocerto. Modelosde controle sãousadosemconjuntocom estilosde estrutura.Todososestilosde estruturaque foi explicadopodemserimplementadospormeiode controle centralizadoou baseadoemeventos. 9 Controle centralizado. Em modelode controle centralizado,umsubsistemaé designadocomocontroladode sistema e tema responsabilidadepelogerenciamentodaexecuçãode outrossubsistemas.Modelosde controle centralizadosDividem –se em duas classes,dependendose foremexecutados sequencialmente ouparalelamente. O modelochamado – retorno.O controle começanotopo da hierarquiade sub – rotinae , atravésde chamadas de sub-rotinas,passaparaos níveismaisbaixosnaarvore,são aplicados emmodelossequenciais. O modelogerenciados.Aplicadosemmodelosconcorrentes.Umsistemaconcorrenteé
  5. 5. projetadocomoum gerenciadorde sistemae controlao inicio,aparada e a coordenaçãode outrosprocessosdosistema. Sistemasorientadosaeventos. As decisõesdosmodelosorientadosaeventossãoregidospeloseventosgerados externamente.Otermoeventopode serumsinal que pode assumirumagama de valoresou uma entradade comandobaseadosemum menu. Possuemdoismodelosde controle orientadosa eventos. Modelosde broadcast.Nesse modelo,umeventoé transmitidoatodosos subsistemas. Qualquersubsistemaprogramadoparamanipularoeventopode responderaele.A vantagem dessaabordagemé que a evoluçãoé relativamente simples,umnovosubsistemaparatratar classesespecificasde eventospode serintegradopormeiodoregistrode seuseventosno tratador de eventos.A desvantagemé que os subsistemas nãosabemse ouquandoos eventos serãomanipulados. Modelosorientadosainterrupções.Sãousadosemsistemasde temporeal comorequisitos rigorososde tempo,nosquaisas interrupçõesexternassãodetectadasporumtratorde interrupções.Avantagemdessaabordagemé que elapermite respostasmuitorápidasaos eventosaseremimplementados.Suadesvantagemé acomplexidade daprogramaçãoe a dificuldadede validação. 10 Arquiteturade referencia As arquiteturasde referencianãosãogeralmente consideradasumroteirode implementações.Emvezdisso,suaprincipal funçãoé serummeiode discussãode arquiteturasde domínioespecificoe de comparaçãode sistemasdiferentesemumdomínio. Um modelode referenciafornece umvocabulárioparacomparação.Ele atua comouma base, emrelaçãoa qual os sistemaspodemseravaliados. Uma propostade modelo de referenciaé ummodeloparaambientesCASEque identificacinco conjuntosde serviçosque umambiente CASEdeve fornecer.Ele deve tambémfornecer recursosde plugin para ferramentasCASEindividuaisque usamessesserviços.Oscincos níveisde referenciassão: Serviçosde repositóriode dados.Estesserviçosfornecemrecursosparaoarmazenamentoe o gerenciamentode itensde dadose seusrelacionamentos. Serviçosde integraçãode dados.Estesserviçosfornecemrecursosparaogerenciamentode grupos ou para definiçãode relacionamentosentre eles. Serviçosde gerenciamentode tarefas,estesserviçosfornecemrecursosparaa definiçãoe aprovação de modelosde processo. Serviçosde mensagem.Comunicaferramenta –Ferramenta,ambiente-ferramentae ambiente – ambiente. Serviçosde interface comousuário.Este serviçofornecemrecursosparao desenvolvimento de interface como usuário. A finalidadedessaarquiteturade referenciaé serum meiode classificaçãoe comparaçãode ferramentase ambientesCASEintegrados.
  6. 6. CAPITULO12 – Arquiteturade sistemasdistribuídos Um sistemadistribuídoé aquele emque asinformaçõesemfase de processamentosão distribuídasavárioscomputadores. Vantagensde usaruma abordagemdistribuídaparadesenvolvimentode sistemas. 1. Compartilhamentode recursos –Um sistemadistribuídopermite ocompartilhamentode recursosde hardware e software,comodiscos,impressoras,arquivose computadoresque estãoassociadosaosdiferentescomputadoresde umarede. 2. Abertura- permitemaequipamentose software de diferentesfabricantesserem combinados,poissãoprojetadoscombase emprotocolospadrões. 3. Concorrência– váriosprocessospodemoperarao mesmotempoemdiferentes computadores,e podem(maisnãoprecisam) conversar unscomosoutros. 4. Escalabilidade –sãoescalonáveisamaneiraque acapacidade de um sistemapode ser ampliadapelaadiçãode novosrecursospara atenderasdemandasdossistemas. 5. Tolerânciaa defeitos –peladisponibilidade de várioscomputadorese opotencial de duplicaçãode informaçãosignificaque ossistemasdistribuídospossamsertolerantesa algumasfalhasde hardware e software. Essessistemasde distribuiçãocomparadosaossistemasque operamcomumprocessadorou com um clusterde processadorespodemteralgumasdesvantagenscomo: 1. Complexidade - ossistemasdistribuídossãomaiscomplexosque ossistemascentralizados. 2. Proteção – o sistemapode seracessadode várioscomputadoresdiferentes,e otrafegona rede pode estarsujeitaainterceptações. 3. Gerenciamento –os computadoresdosistemapodemserde tiposdiferentese podem operarem versõesdiferentesde sistemasoperacionais.Defeitosemumamaquinapodemse propagar a outra maquinascomconsequênciasinesperadas. 4. Imprevisibilidade –Comotodosos usuáriosdawebsabem, os sistemasdistribuídossão imprevisíveisemsuasrespostas.A respostadepende dacarga total do sistema,sua organizaçãoe a carga da rede.Comotudoissopode mudaremum curto períodode tempo,o tempode respostapara uma solicitaçãodousuáriopode variardrasticamente de uma solicitaçãoparaoutra. Possuemdoistiposdiferentesde arquiteturasde sistemasdistribuídos: 1. Arquiteturacliente-servidor.Éo sistemacomoum conjuntode serviçosfornecidos aos clientesque fazemusodessesserviços.Osservidorese clientessãotratadosde maneiras diferentesnessessistemas. 2. Arquiteturasde objetosdistribuídos.Podemospensarnosistemacomoumconjuntode objetosque interageme cujaalocalizaçãoé irrelevante.Nãohádistinçãoentre clientee servidor. Tanto a arquiteturacliente-servidore aarquiteturade objetosdistribuídossãoamplamente usadasno setor,maisa aplicaçãoocorre geralmente dentrode umaúnicaorganização.A organizaçãoé,portanto,intra-organizacional. 1 Arquiteturade multiprocessadores
  7. 7. O multiprocessadorSãoprocessosque podemserexecutadosseparados.Esse modelotomam decisõesusandoessasinformaçõese enviamsinaisaosatuadores,que modificamoambiente do sistema.O usode váriosprocessadoresaprimoraodesempenhoe acapacidade de recuperaçãodo sistema 2 Arquiteturacliente-servidor Em um arquiteturacliente-servidor,umaaplicaçãoé modeladacomoumconjuntode clientes que usam essesserviços.Osclientesprecisamestarinformadossobre osserviçosdisponíveis, mas geralmente nãosabemdaexistênciade outrosclientes.Váriosprocessosde serviços podemserexecutadosemumúnicoprocessadorde serviçoportantonãohá mapeamento entre processose processadores de umsistema O projetode sistemascliente-servidordeve refletiraestruturalógicada aplicaçãoque esta sendodesenvolvida.Umexemploé umaaplicaçãoqesta divididaem3camadas: a camada de apresentação,que se encarregadaapresentaçãode informaçõesparaousuárioe toda a interaçãocom o usuário.A camada de processosde aplicaçõesse encarregada implementaçãodalógicadaaplicaçãoe a camada de gerenciamentode dadosse encarregade todasas operaçõesde bancode dados. A arquiteturacliente-servidormaissimplesdenomina-searquiteturacliente-servidorde duas camadas,podemter duasformas: Modelocliente-magro.Oprocessamentoe ogerenciamentode dadossãorealizadosno servidor.Ocliente apenasexecutaosoftware de apresentação. Modelocliente-gordo.Oservidoré responsável somente pelogerenciamentode dados.O software docliente implementaalógicada aplicaçãoe as interaçõescomo usuáriodo sistema. Uma desvantagemdomodelocliente-magroé que ele impõe umagrande carga de processamentosobre oservidore arede. O modelocliente-gordofazusodessacapacidade de processamentodisponívele distribui o processamentológicode aplicaçãoe aapresentaçãodocliente.Oservidoré essencialmente um servidorde transaçõesque gerenciatodasastransaçõesdobanco de dados. Enquantoo modelocliente-gordodistribuioprocessamentomaiseficientementedoque um modelocliente-magro,ogerenciamentodosistemaé maiscomplexo.A funcionalidadeda aplicaçãoé divididaentre várioscomputadores.Quandoosoftware precisaseralterado,isso envolve reinstalaçãoemcadacomputadorcliente,oque pode resultaremumcusto significativose houvercentenasde clientesnosistema. O Problemacoma abordagemcliente-servidorde duascamadasé que as trêscamadas lógicas, devemsermapeadassobre doissistemasde computador –o cliente e oservidor.Pode haver problemasde escalabilidade e desempenho,se omodelocliente-magrofor escolhido,ouproblemasde gerenciamentode sistemas,se omodelocliente-gordoforusado. Para evitaressesproblemasumaalternativaé usaro modelocliente-servidorde trêscamadas. Em algunscasos é melhorestenderomodelocliente-servidorde trêscamadaspara uma variante comvarias camadas,na qual servidoresadicionais sãoincorporadosaosistema.
  8. 8. 3 Arquiteturasde objetosdistribuídos Nesse modeloosobjetospodemserdistribuídosentre umaserie de computadoresnarede e se comunicamatravésde um middleware,que é chamadode requisitorde objetos.O Middleware forneceumainteface transparente continuaentre osobjetos.Ele fornece um conjuntode serviçosque permitemque osobjetosse comuniqueme sejamadicionadose removidosdosistema.Asvantagenssão: Permite que oprojetistadosistemapostergue decisõessobre onde e comoosserviçosdevem serfornecidos. È uma arquiteturade sistemaabertoque permite que novosrecursossejamadicionados. Uma arquiteturade objetosdistribuídospode serusadacomoum modelológico,que permite estruturare organizaro sistema. Uma arquiteturade objetosdistribuídosemlugarde umaarquiteturacliente-servidoré adequadapara esse tipode aplicaçãoportrês razões: O modelológicodosistemanãoé um dosfornecimentosde serviçosemque existemserviços distintosde gerenciamentode dados. Pode adicionarbancosde dadosao sistemasemgrande interrupções. A maiorDesvantagemé que elassãomaiscomplexasdoque sistemascliente-servidor. 4 CORBA Existemquatroelementosprincipaisdesse padrão: 1. um modelode objetoparaobjetosde aplicaçõesemque umobjetocorbaé um encapsulamentode estadocomumainterface bemdefinidaemlinguagemneutradescritaem um linguagemde definiçãode interface. 2. Um requisitorde objetosque gerenciasolicitaçõesparaserviçosde objetos. 3. Um conjuntode serviçosde objetosque sãoserviçosgeraiscomprobabilidadede serem solicitadospormuitasaplicaçõesdistribuídas. 4. Um conjuntode componentescomunsconstruídossobre essesserviçosbásicosque podem sersolicitadospelasaplicações. O Corba consideraumobjetocomose fosse umencapsulamentode atributose serviços,como é normal emobjetos.oCorbadeve terumadefiniçãode interface separadaque define atributose operaçõespublicasdoobjeto.asinterfacessãodefinidasporumalinguagemde definiçãode interface padronizadaindepende de linguagem. Os objetoscorbatemum únicoidentificadorchamadode referenciade objetointeroperavel. Esse IOR é usadoquandoumobjetosolicitaserviçosde umoutroobjeto. O requisitorde objetosconhece osobjetosque estãosolicitandoserviçose suasinterfaces.O ORB cuidada comunicaçãoentre os objetos.osobjetosque se comunicamnãoprecisam conhecera localizaçãode outrosobjetosnemsobre suaimplementação.
  9. 9. O objetoque fornece oserviçotemumesqueletode IDLassociadoque ligaa interface a implementaçãodosserviços. O corba foi desenvolvidodesde1980 e as versõesrecentesde corbaforamsimplesmente dedicadasaoapoioaos objetosdistribuídos. Os padrõesCorbaincluemdefinições de interface para uma grande variedade de componenteshorizontaise verticais.Oscomponentesverticais são componentesespecíficosde umdomíniode aplicação.Oscomponenteshorizontaissão componentesde propósitogeral,comocomponentesde interface comousuário. 5 COMPUTAÇÃOINTERORGANIZACIONLDISTRIBUIDA Por motivode segurançae interoperabilidade,acomputaçãodistribuídafoi implementada inicialmente emnível organizacional.Umaorganizaçãotemumaserie de servidorese distribui sua carga computacional entre eles.Devidoaofatode elesestaremtodoslocalizadosdentro da mesmaorganização,podemseraplicadospadrõese processosoperacionaislocais. 6 ARQUITETURAS PONTOA PONTO São sistemasdescentralizadosemque ascomputaçõespodemserrealizadasporqualquernó da rede,nenhumadistinçãoé feitaentre clientese servidores.Osistemaglobal é projetado para beneficiar-se dacapacidade computacional e armazenamentodisponíveisemumarede de computadorespotencialmente grande. Em principio, emsistemaspontoaponto,todonóde rede pode estarciente a respeitode qualqueroutronó,pode fazerconexõescomele e pode trocardadoscom ele. Em uma arquiteturadescentralizada,osnosde rede nãosão simplesmente elementos funcionais,maistambémchavesde comunicaçãoque podemguiarossinaisde dadose de controle de umnó para o outro. No entantoquandose recuperaumdocumento,onó que estarecuperandose tornavisível para outros. 7 ARQUITETURA DE SISTEMA ORIENTADOA SERVIÇOS A essênciade umserviço,é que ofornecimentodosserviçosé independentedaaplicaçãoque usa o serviço.Os provedoresde serviçospodemdesenvolverserviçosespecializadose oferecê-losaumagama de usuáriosde serviçosde organizaçõesdiferentes. A propostoWEB Service foi lançadapoisoacessode servidoresweb,erasomente pormeiode navegarweb,e o acessodiretoaos repositóriosde informaçõesporoutrosprogramasnão era pratico. Os trêspadrõesfundamentaisque possibilitamcomunicaçãoentre WEBSERVICESsão: SOP.Define umaorganizaçãopara troca estruturadade dadosentre WEB SERVICES. WSDL. Define comoasinterfacesdosWEB servicespodemserrepresentadas. UDDI. Este é um padrão de descobrimentoque define comoasinformaçõesde descriçãodo serviçousadaspelossolicitantesdoserviçosparadescobrirserviços,pode serorganizada.
  10. 10. TodosessespadrõessãobaseadosemXML CAPITULO13 – Arquiteturade aplicações 1 sISTEMASDE PROCESSAMENTODE DADOS Aplicaçõesde processamentode dados. São Aplicaçõesvoltadosadados.ElasProcessamdadosemlotessemintervençõesexplicitas do usuáriodurante oprocessamento.AsAçõesexplicitastomadaspelaaplicaçãodependem dos dadosque são processados.Ossistemasde processamentoemlotessãonormalmente usadosemaplicaçõesde negóciosnasquaisasoperaçõessimilaressãorealizadassobre uma grande quantidade de dados.Elestratamde uma grande variedade de funções administrativas,comofolhade pagamento,cobrança,contabilidadee publicidade.Essas aplicações enfocamosdados.Osbancosde dadossão geralmente maioresque ossistemasde informações(SI). Os sistemasde processamentode dados selecionamosdadosde registrosde entradae,dependendodovalordoscamposnos registros,tomamalgumasaçõesespecificadasnoprograma.Elespodem, então,enviaro resultadonovamentedoprocessamentoaobancode dados e formatar a entradae a saída processadapara impressão. Os sistemasde processamentode dadospossuem3componentesprincipais: 1 Entrada.A entradacoletaas entradasde umaou maisfontes. 2 processamento.Oprocessamentorealizaacomputaçãousandoessasentradas. 3 saída. A saída geraSaídas a seremescritasnovamentenobancode dadose ou impressas. Os componentesde entrada,processamentoe de saídapodemserdecompostosaindaem uma estruturaentrada-processamento-saída.Exemplo: Um componente de entradapode leralgumdadode um arquivooubanco de dados(entrada) e corrigiralgunserros(processo) e,depoisenfileirarosdadosvalidosparaprocessamento (saída) São sistemasorientadosafunções,poisosregistrose astransaçõessão processadosemserie, semnecessidade de manteroestadoentre astransações. 2 sistemasde processamente de transações Os sistemasde transaçõessãoprojetadosparaprocessarsolicitaçõesde informaçõespor usuáriosde um bancode dados.Tecnicamente umasequenciade operaçõesé tratadacomo uma unidade simples(umaunidade atômica).Todasasoperaçõestemque serrealizadasantes que as mudançastornem-se permanentesnobancode dados. Os sistemasde processamentode transaçõessãogeralmentesistemasinterativosnosquaisos usuáriosenviamsolicitaçõesassíncronasde serviço.Primeiroumusuáriofaz uma solicitaçãoparao sistemaatravésde umcomponente de processamentode
  11. 11. entrada/saída.A solicitaçãoé processadaporalgumalógicaespecificadaaplicação.Uma transação é criada e passadapara um gerenciadorde transações,que é emgeral incorporado ao sistemade gerenciamentode bancode dados.Depoisque ogerenciadorde transações assegurarque a transação foi concluídaadequadamente,ele sinalizaraparaa aplicaçãoque o processamentofoi finalizado. A estruturaentrada-processo-saídase aplicaaosmuitossistemasde processamentode transações.Algunsdesses sistemassãoversõesinterativasde sistemasde processamentode lotes. Um exemplode sistemade processamentode transaçõesé umsistemabancárioque permite aos clientesconsultaremsuascontase retiraremdinheirode umcaixaeletrônico.Osistemaé compostode doissubsistemasde software que cooperamentre si –o software de caixa eletrônicoe osoftware de processamentode contaslocalizadasnoservidorde bancode dados.Os subsistemasde entradae de saídasão implementadoscomosoftwaresnocaixa eletrônico,umavezque osubsistemade processamentoestánoservidorde bancode dadso. Em sistemascomoos de contabilidadede clientesde umbanco,pode haverdiferentes maneirasde interagircomo sistema.Muitosclientesinteragirãopormeiode caixas eletrônicos,masumaequipe dobancousara terminaisde mesaparaacessar o sistema.Pode haverváriostiposde caixaseletrônicose terminaisde mesa,e algunsclientese aequipe do banco podemacessarosdados de contas por meiode navegadoresWEB. Para simplificarogerenciamentode diferentesprotocolosde comunicaçãoentre terminais, sistemasde processamentode transaçõesde largaescalapodemincluirmiddleware para comunicaçãocom todosos tiposde terminal,organizaçãoe ordenaçãoemserie dosdadosdos terminaise enviodosdadosparaprocessamento. 3 Sistemasde gerenciamentode informaçõese recursos Um sistemade informaçõespermiteacessocontroladode umagrande base de informações, taiscomo catalogode bibliotecas,tabelade horáriosde voosouregistrosde pacientesemum hospital.OdesenvolvimentodaWEBfezcom que um grande numerode sistemasde informaçõesmigrasse de sistemasorganizacionaisespecializadosparasistemasde propósito geral acessíveisuniversalmente. O sistemade informaçãoé modeladocomouso de uma abordagemde camadas oude maquinaabstratana qual a camada superiorapóiaa interface comousuárioe a camada inferior,obancode dados de sistema.A camada de comunicaçõesinclui umalógicaespecifica de aplicação para acessoe atualizaçãodo bancode dados. Sistemasde alocaçãode recursossão uma classe de aplicaçãoamplamente usada.Sua arquiteturaestaalinhadacomo modelode sistemade informações.Oscomponentesde um sistemade alocaçãode recursosinclui: 1- um banco de dadosde recursosque mantémdetalhesde recursosque sãoalocados.Os recursospodemseradicionadosouremovidosdobancode dados. 2- Um conjuntode regrasque descreve asregrasde alocaçãode recursos. 3- um componente de gerenciamentode recursosque permiteque oprovedorde recursos adicione,editeouelimine recursosdosistema. 4- um componente de alocaçãode recursosque atualizaobanco de dados de recursosquando elessãodesignadose que associaesse recursosadetalhesdosolicitante dorecurso.
  12. 12. 5- um modulode autenticaçãode usuáriosque permite aosistemaverificarse osrecursos estãosendoalocadospara umusuárioreconhecido. 6- um modulode gerenciamentode consultasque permite aousuáriodescobrirquaisrecursos estãodisponíveis. 7- um componente de entregade recursosque preparaosrecursosa serementreguesao solicitante.Emumsistemade emissãode ingressos,issopodeenvolverapreparaçãode uma confirmaçãopor e-mail,oenviode umasolicitaçãoparaumaimpressoraque imprime os ingressose osdetalhesde paraonde os ingressosdevemserenviados. 8- um componente de interfacecomousuárioque esta forado sistemae permite ao solicitante dorecursoenviarconsultase solicitaçõesparaorecursoa ser alocado. 4 Sistemasde processamentode eventos O sistemasde processamentode eventosrespondemaoseventosdoambienteoudainterface com o usuáriodo sistema.A principal característicadossistemasde processamentode eventosé que a sequenciade eventosé imprevisível e osistemadeve sercapazde trabalhar com esseseventosquandoelesocorrerem. Sistemasde temporeal,sãotambémsistemasde processamentobaseadosemeventos, poremao invésde tereventosde interface comousuário,temeventosassociadosa sensores e atuadoresdosistema. 5 Sistemasde processamentode linguagens Os sistemasde processamentode linguagensaceitamumalinguagemnatural ouartificial como entradae geram algumaoutra representação dessalinguagemcomosaída.Em engenhariade software,ossistemasde processamentode linguagensmaisamplamenteusadossãooscompiladoresque traduzemumalinguagem artificial de programaçãode altonível emcódigode maquina.Maisoutrossistemasde processamentode linguagenstraduzemumadescriçãode dadosXML emcomandospara consultarum bancode dadose sistemasde processamentode linguagemnatural que tentam traduziruma linguagememoutra. Os tradutoresemumsistemade processamentode linguagenstemumaarquiteturagenérica que inclui osseguintescomponentes: 1. Um analisadorléxico,que obtémelementosdalinguagemde entradae osconverte emum formatointerno. 2. uma tabelade símbolosque mantéminformaçõessobre osnomesde entidades(variáveis, nomesde classes.) usadasnotextoque estasendotraduzido. 3. um analisadorsintático,que verificaasintaxe dalinguagemque estásendotraduzida.Ele usa uma gramáticadefinidade linguageme constrói umaarvore de sintaxe. 4. ume árvore de sintaxe,que é umaestruturainternaque representaoprograma que esta sendocompilado. 5. um analisadorsemântico,que usainformaçõesdaárvore de sintaxe e databelade símbolos para verificaracorreção sintáticado textodalinguagemde entrada. 6. um geradorde códigoque ‘caminha’pelaárvore de sintaxe e gerao códigode maquina abstrata.
  13. 13. capitulo29 – gerenciamentode configurações Gerenciamentode configuraçõesé odesenvolvimentoe ousode padrõese procedimentos para o gerenciamentode sistemasde software emdesenvolvimento.HamuitasrazõesPorque os sistemasexistememdiferentesconfigurações.Configuraçõespodemserproduzidaspara diferentescomputadores,paradiferentessistemasoperacionais,incorporandofunções especificasde clientes. Os gerentesde configuraçõessãoresponsáveispormantera rastreabilidade dasdiferenças entre versõesde software,paraassegurarque asnovasversõessejamderivadasde maneira controladae liberarnovasversõesparaclientescertosnomomentocerto. 1 Planejamentode gerenciamentode configurações O planode gerenciamentode configuraçõesdescreveospadrõese procedimentosque devem serusadospara o gerenciamento.Opontode partidapara o desenvolvimentodoplanodeve serum conjuntode padrõesde configuração,que devemseradaptadospara se atenderaos requisitose asrestriçõesde cadaprojetoespecífico. 1 IDENTIFICAÇÃODEITEMDE CONFIGURAÇÃO Em um grande sistemade software,pode havermódulosde milharesde códigosfonte,scripts de testes,documentosde projetoetc.Elessãoproduzidosporpessoasdiferentese,quando criados,podemserdenominadoscomnomessimilaresouidênticos.Paramantera rastreabilidadede todasessasinformaçõesde maneiraque oarquivocertopossaser encontradoquandofornecessáriovocê necessitade umesquemade identificaçãoconsistente para todosos itensnosistemade gerenciamentode configurações. Durante o processode planejamentode gerenciamentode configuração,você decide exatamente quaisitensserãocontrolados.Planosde projetos,especificações,projetos, programas,e massade dadosde teste sãonormalmente mantidoscomoitensde configuração.Todososdocumentosque podemser uteisparaa evoluçãofuturadosistema devemsercontroladospelosistemade gerenciamentode configuração. O esquemade identificaçãode itensde configuraçãodeve atribuirumúniconome paratodos os documentossobcontrole de configuração.Esse nome pode refletirotipodoitem, uma parte do sistemaaoqual ele se aplica,o criadordo item.Noesquemade atribuiçãode nomes, você pode desejarevidenciararelaçãoentre ositensparagarantir que os documentos relacionadospossuamumamesmaraizemseusnomes.Portanto,você pode definirum esquemade hierarquiacomnome. Esquemasde nomeshierarquizadossãosimplese de fácil compreensão:algumasvezes, podemmapearumaestruturade diretóriosusadaparaarmazenararquivosde projeto.No entanto,refletemaestruturade projetonaqual o software foi desenvolvido.Osnomesde itensde configuraçãoassociamcomponentes comumprojetoespecificoe,dessamaneira, reduzemasoportunidadesparaoreuso.Pode sermuitodifícil encontrarcomponentes relacionados.
  14. 14. 2 BANCODE DADOSDE CONFIGURAÇÃO O banco de dadosde configuraçãoé utilizadopararegistrartodasas informaçõesrelevantes sobre as configuraçõesde sistemae ositensde configuração.Você usaobanco de dadosCM para auxiliaraavaliaçãodo impactodas mudançasde sistemae para gerar relatóriosparaa gerenciasobre oprocessode CM. Comoparte do processode CM, deve-se definiroesquema do bancode dadosde CM, os formuláriosparacoletarinformaçõesparaseremregistradasno banco de dadose procedimentospararegistroe recuperaçãode informaçõesde projeto. Um banco de dados de configuraçãopode registrarinformaçõessobre usuáriosde componentes,clientesde sistemas,plataformasde execução,mudançaspropostase etc. De preferência,umbancode dadosde configuraçãodeve serintegradocomaversãodo sistemade gerenciamentousadaparaarmazenare gerenciarosdocumentosformaisdo projeto. Um banco de dados de configuraçãoarmazenainformaçõessobre itensde configuraçãoe referenciaseusnomesnumsistemade gerenciamentode versãooudepósitode arquivos. 2 Gerenciamentode mudanças As necessidadese requisitosorganizacionaisalteram-se durante avidaútil de umsistema.Isso significaque você precisafazerasmudançascorrespondentesnosistemade software.Para garantir que essasmudançasserãoaplicadasaosistemade maneiracontrolada,você precisa de um conjuntode procedimentosde gerenciamentode mudançasapoiadoporferramentas. Procedimentosde gerenciamentode mudançadizemrespeitoaanalise de custoe beneficio das mudançaspropostas,a aprovaçãodas mudançasviáveise a rastreabilidade de quais componentesdosistemaforamalterados.Oprocessode gerenciamentode mudançadeve surtirefeitoquandoosoftware oua documentaçãoassociadasãocolocadosembaseline pela equipe de gerenciamentode configurações. O primeiroestágionoprocessode gerenciamentode configuraçõesé completarum formuláriode solicitaçãode mudança(CRF – change requestform) que descreveamudança necessáriaparao sistema.Umavezque o formuláriode solicitaçãode mudançaé enviado,ele deve serregistradonobanco de dadosde configuração.A solicitaçãode mudançaé então analisadapara verificarse amudança solicitadaé necessária. Para mudançasvalidas,oestagioseguinte é aavaliaçãodamudança e o custo.O impactoda mudançano restante dosistemadeve serverificado.Issoenvolvetodososcomponentes afetadospelamudança.Se realizaramudança significaque mudançasadicionaisemalguma parte do sistemasãonecessárias,issoaumentaclaramente ocustode sua implementação.Em seguidaasmudançasnecessárias paraos módulosdosistemasãoavaliadas.Finalmente,o custo para realizara mudançaé estimado,considerandooscustosde mudançanos componentesrelacionados. 3 gerenciamentode versõese releases Os processosenvolvidosnogerenciamentode versõese relasespreocupam-se coma identificaçãoe a manutençãodarastreabilidadedasversõesde umsistema.Gerentesde versõesidealizamprocedimentosparaassegurarque as versõesde umsistemapossamser
  15. 15. recuperadasquandosolicitadase nãosejamalteradasacidentalmentepelaequipede desenvolvimento.Paraprodutos,osgerentestrabalhamcomaequipe de marketing,e ,para sistemasfeitossobencomenda,comosclientes,paraplanejarquandonovosreleasesde um sistemadevemsercriadose distribuídosparaimplantação. Um release dosistemaé umaversãodistribuídaaosclientes.Cadareleasedeve incorporar novasfuncionalidadesouserplanejadoparaumaplataformadiferentede hardware. 1 IDENTIFICAÇÃODEVERSÕES Para criar uma versãoespecificade umsistema,você precisaespecificarasversõesdos componentesde sistemaque devemserincluídasnele.Você nãopode usaro nome doitemde configuraçãopara identificaraversão,porque ele pode termuitasversõesparacada item de configuraçãoidentificado. A trêstécnicasbásicaspara identificaçãodaversãode componentes. 1. Numeraçãode versões.Ocomponente recebe umnumeroexplicitoe únicode versão.Issoé o maiscomumente usadonoesquemade identificação. 2. identificaçãobaseadaematributos.Cadacomponente temumnome (comoonome do item de configuração,que nãoé únicopara diferentesversões) e umgrupode atributosassociados para cada versão,componentessãoportanto,identificadospelaespecificaçãode seusnomes e valoresde atributos. 3. identificaçãoorientadaamudanças.Cada componente é denominadocomonaidentificação baseadaematributos,masé tambémassociadocomuma ou maissolicitaçõesde mudanças. Ou seja,considera–se que cada versãode componente foi criadaemrespostaauma ou mais solicitaçõesde mudanças.A versãode componente é identificadapeloconjuntode solicitaçõesde mudançasque se aplicamaocomponente. 2 GERENCIAMENTODE RELEASES Um release de sistemaé umaversãodosistemadistribuídoparaosclientes.Osgerentesde release de sistemassãoresponsáveispordecidirquandoumsistemapode serliberadoparaos clientes,gerenciaroprocessode criaçãodo release e de meiosde distribuiçãoe documentaro release paraassegurarque ele pode serrecriadoexatamente comofoi distribuído,se for necessário. A criação de um release é umprocessode criação de arquivose documentosque inclui todos os componentesdoreleasedosistema.Ocódigoexecutável de programase todosos arquivos de dados associadosdevemsercoletadose identificados.Se osmanuaisaseremlidosem computadoressãodistribuídos,copiaseletrônicasdevemserarmazenadascomosoftware. Finalmente,quandotodasasinformaçõesestiveremdisponíveis,odiretóriodorelease é manipuladoparaa distribuição. Quandoum release de sistemaé produzido,eledeveserdocumentadoparaassegurarque possaser recriadoipsisliterisnofuturo.Issoé importante parasistemasembutidosde ciclode vidalongoe feitospara osclientes,comoaquelesque controlammaquinascomplexas. Para documentarumrelease você deve registrarasversõesespecificasdoscomponentesde códigofonte usadospara criar o códigoexecutável.Você deve mantercompiasdoscódigos fonte e códigoexecutável,e de todososarquivosde dadose de configuração.Você deve
  16. 16. tambémregistraras versõesdosistemaoperacional,asbibliotecas,oscompiladorese outras ferramentasusadasparaconstruiro software.Elaspodemsernecessáriasparaconstruir exatamente omesmosistemaemalgumadataposterior. 4 construçãode sistemas A construçãode sistemasé umprocessode compilaçãoe ligaçãode componentesde software numprograma que executadeterminadaconfiguraçãodefinida.Quandovocê estaconstruindo um sistemacombase emseuscomponentes,você devepensarnasseguintesquestões: 1. Todos os componentesque compõemumsistemaforamincluídosnasinstruçõesde construção? 2. A versãoapropriadade cada componente necessáriofoi incluídanasinstruçõesde construção? 3. todos osarquivosde dadosnecessáriosestãodisponíveis? 4. Se os arquivosde dadosestãoreferenciadosdentrode umcomponente,onome usadoé o mesmoque o doarquivode dados na maquina – alvo? 5. A versãoapropriadado compiladore de outrasferramentasrequeridasestadisponível?As versõesatuaisdasferramentasde software podemserincompatíveiscomasversõesantigas usadaspara desenvolverosistema. 5 ferramentascase paragerenciamentode configurações Processosde gerenciamentode configuraçõessãonormalmente padronizadose envolvem aplicaçõesde procedimentospredefinidos.Elesrequeremogerenciamentocuidadosode grande quantidade de dadose é essencial aatençãoaos detalhes.Quandoumsistemaestá sendoconstruídocom base emversõesde componentes,umúnicoerrode gerenciamentode configuraçãopode significarque osoftware nãoirá operaradequadamente. Conseqüentemente,oapoiode umferramentaCASEé essencial paraogerenciamentode configuração.Essasferramentaspodemsercombinadasparacriaruma área de trabalhopara apoiartodas as atividadesde CM. REFERÊNCIAS SOMMERVILE, Ian.ENGENHARIA DE SOFTWARE.8 Edição. SãoPaulo:PearsonAddisonWesley, 2007.

×