03 Estilos aruiteturais - IFRNdiatinf.ifrn.edu.br/prof/lib/exe/...estilos_aruiteturais.pdf ·...
Transcript of 03 Estilos aruiteturais - IFRNdiatinf.ifrn.edu.br/prof/lib/exe/...estilos_aruiteturais.pdf ·...
-
EstilosArquiteturais
Prof.FellipeAleixo([email protected])
-
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