Post on 19-Oct-2020
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