EstilosArquiteturais

Prof.FellipeAleixo(fellipe.aleixo@ifrn.edu.br)

ComoDefinirArquiteturas?

•Doistiposdeelementospodemserutilizadosparaadefiniçãodeumaarquitetura:• Componentesà blocosdeconstruçãodeumsistema–partesdosoftwareouprovedoresdefuncionalidade• Serviçosà sãoprovidospeloscomponentesparaosatoresouunsparaosoutros

•Umconjuntodecomponentesofereceasfuncionalidadesdeumsistema

EstilosArquiteturais

• Estilosarquiteturaisdeumsoftwareequivalemaosestilosarquiteturaisdeumacasa

•Referem-seao“formato”geraldosistema

•Aescolhadoestiloarquiteturalapropriadoémuitoimportante,poisasdemaisdecisõessãotomadasnocontextodoreferidoestilo

EstilosArquiteturais

•Umsistemapodeserdefinidosegundo• Umestilode“fluxo”,comooPipes and Filters• Umestilointerativo,comooModel-View-Controller

•Umestilodefinecaracterísticaseregrasqueformamaarquitetura

•Aescolhadoestiloapropriadoéachaveparaosucessodosistema

ElementosdeumEstilo

1. Osblocos básicosdeconstrução

2. Osconectores entreosblocosbásicos(comunicação)

3. Regrasqueespecificamcomoosserviçospodemsercombinadoseutilizadosemconjunto

4. Asoluçõesintrínsecasaoestilo

5. Contextoesituaçõesproblemanasquaisoreferidoestiloémaisútil

PadrõeseEstilosArquiteturais

EstiloArquitetural Padrão

FromMud to Structure(1)Emcamadas,(2)Pipes and Filters,(3)Blackboard

Distributed Systems (4) Broker

Interactive Systems (5) Model-View-Controller e(6)Presentation-Abstraction-Control

Adaptable Systems (7)Microkernel e(8)Reflection

AspectosdoProcessodeDefiniçãodaArquiteturadeSoftware• Tempo• Quandocriaraarquiteturadosoftware?

•Categoriadeproblemas• Odomíniodasoluçãoinfluenciaasdecisõesarquiteturais

•Camadaseabstrações• Pensaremdiferentesníveisdeabstraçãoéumahabilidadefundamentalnaconstruçãodaarquitetura

QuandoCriaraArquitetura?

•Noiníciodoprocessodedesenvolvimento

• Seodesenvolvimentoéiterativoeincremental:• Aarquiteturainiciaaserelaboradanasiteraçõesiniciaisemparalelocomalgumprojeto(baixonível)ecodificação• Cadaiteraçãopodeincluirmaisrefinamentos daarquiteturaemconjuntocomprojetosecodificação• Acadaiteraçãoaarquiteturaficamaiscompletaeestável

CategoriasdeProblemas

•Quandosedesenvolveaarquitetura,vocêresolveproblemasdeváriosdomínioscomputacionais

•Nosistemadefolhadepagamento:• Domíniodebancodedados– paraarmazenar ohistóricodepagamentosdosfuncionários• Domíniodesistemainterativo– paraaleituradashorastrabalhadaspelosfuncionários(calcularopagamento)

• Solucionarproblemasreaisenvolveváriosdomínios

DefinindoCamadaseAbstrações

•Apresentamosomodelo4+1 devisõesarquiteturais1. Visãológica2. Visãodeprocessos3. Visãofísica4. Visãodedesenvolvimento5. +avisãodecenários(oucasosdeuso)

•Cadavisãoapresentaumaabstração(oupontodevistadiferente)damesmaarquitetura

DefinindoCamadaseAbstrações

•Algumasvezesseusistemaouoseuambientepossuicamadas explicitasdefuncionalidade

•Porexemplo:seestásendodesenvolvidoumsistemadecomunicação,vocêprecisaestarfamiliarcomomodeloOSI• NomodeloOSI,as(sete)camadasrepresentamavisãológicadaarquitetura

DefinindoCamadaseAbstrações

• Emalgunscasos,ascamadaspodemestarassociadasaoselementosfísicos(computadores)

DefinindoCamadaseAbstrações

•Umaabstração éumaformadedescreveralgoemtermosgerais– deixandoosdetalhesparaalgumaimplementaçãoespecífica

•Porexemplo:aarquiteturaemtrêscamadas,oselementossãodistribuídosemtrêsgruposdeacordocomsuafuncionalidadeabstrata1. Apresentação2. Lógicadonegócio3. Armazenamentopersistente

TécnicasAuxiliaresparaaDefiniçãodaArquiteturadeSoftware1. Abstração• Habilidadedeextrairoqueécomumegeralàdadasentidades

2. Encapsulamento• Agruparinformaçõesparapreservarasfronteirasdaabstração

3. OcultaçãodeInformação• Esconderasinformaçõesqueumclientenãoprecisasaber

4. Modularização• Gerênciadacomplexidadequebrandoosistemaempartes

5. Separation of Concerns• Responsabilidadesnãorelacionadasprecisamficarseparadas

6. AcoplamentoeCoesão• Acoplamento(-)– comoosdiferentesmódulosserelacionam• Coesão(+)– amedidadequantoummóduloéautossuficiente

TécnicasAuxiliaresparaaDefiniçãodaArquiteturadeSoftware7. SuficiênciaeCompletude• Componentespossuemcaracterísticassuficientesparaumainteraçãoútileeficientecomosdemais

8. SeparaçãodasPolíticaseImplementação• Implementaçõesnãoseprendemaocontextoà (+)reuso

9. SeparaçãodasInterfacesdaImplementação• Clientesacessaminterfacesseparadasdaimplementação

10. ÚnicoPontodeReferência• Definiçãoúnicadositensdaarquiteturadesoftware

11. DividirparaConquistar• Dividiroproblemaempartesmenores,simplificandoasolução

DefinindoaArquitetura

ProcessodeDefiniçãodaArquitetura

•Passo1:selecioneumcomponenteaserrefinado• Oprimeirocomponentequevocêiráselecionaréosistemacompleto• Paraocomponentequevocêestárefinando:

1. Definaosobjetivosemetasdocomponente2. Utilizecomoentradaosrequisitos eadeclaraçãodoproblema

ProcessodeDefiniçãodaArquitetura

•Passo2:identifiqueosrequisitosdocomponenteeosrequisitosparaassuasinterações• Queoutraspartesdosistemaouexterioreleinterage?• Oscasosdeusoajudamaentenderasinterconexõeseosserviçosqueestenecessitadeoutraspartesdosistema• Esquematizeofluxodeinformações(dealtonível)entreessescomponentes• Penseem:• Quepartesdocomponentesãoresponsáveisporpartesdaarquitetura• Ospassosdeprocessamentonecessários• (paraaOO)brainstorm dasclassesquecompõemosistema

ProcessodeDefiniçãodaArquitetura

•CartõesCRC(Class-Responsibility-Collaboration)podemserusadosnoregistrodoscomponentes• ParacadacomponenteescrevaumcartãoCRC(cenários)• Exemplo dosistemadefolhadepagamento:

ProcessodeDefiniçãodaArquitetura

•Passo3:pesquiseporumestiloarquiteturaloupadrão queseencaixeaosrequisitoseinteraçõesidentificadasnopasso2• Senãoencontrarnenhumquecaseperfeitamentecomoseuproblema,tentebuscarporproblemassimilares• (teremosmaissubsídionodecorrerdadisciplina)

ProcessodeDefiniçãodaArquitetura

•Passo4:apliqueopadrãoqueseadequouaoseuproblemaaorganizaçãodasclassesecomponentes• Cadapadrãodescreveumaestruturaedefinecomosedaráasinteraçõesentreasclassesoucomponentes

ProcessodeDefiniçãodaArquitetura

•Passo5:repitaospassosde2a4paracadaumdos(sub)componenteidentificadosnoprocesso• Aoescolheropróximocomponenteaserrefinadoevitesebasearnoseuinteresse– escolhaopróximocomponentemaisimportanteparaaarquitetura• Escolhacomponentescomfuncionalidadescríticas• Oucomponentespossivelmentemaisdifíceisdeprojetar

DocumenteoseuTrabalho

• Tomenotasenquantovocêdefineaarquitetura,registre:• asdecisõeschave(evantagensdecadaescolha)• opçõesrejeitadas(easrazõesparateremsidoexcluídas)• ospressupostos(aseremvalidadoscomocliente)

• Esbocecomoaspartestrabalhamjuntas

•Aofinaldoprocesso,redijaodocumentodearquitetura