O documento discute os principais aspectos de projeto de arquitetura de software, incluindo a definição de arquitetura, seus benefícios e desafios. Aborda estilos de arquitetura como cliente-servidor e camadas, além de decomposição modular orientada a objetos ou funções. Também explica modelos de controle e organização como centralizado e baseado em eventos.

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