Arquitetura evolutiva e design emergente
•Transferir como PPTX, PDF•
1 gostou•602 visualizações
Recomendados
Mais conteúdo relacionado
Destaque
Destaque (20)
Semelhante a Arquitetura evolutiva e design emergente
Semelhante a Arquitetura evolutiva e design emergente (20)
Arquitetura evolutiva e design emergente
- 1. 2011 Praticando a Arquitetura Evolucionária Leandro Daniel @leandronet
- 2. Leandro Daniel @leandronet Comunidade .net Magazine Autor de artigos Consultoria Desenvolvimento de software Editor Técnico .NET Easy.net Magazine ClubeDelphi SQL Server Business Intelligence Arquitetura de Software Várias certificações...
- 4. Agenda
- 6. Arquitetura Implementação Design @leandronet #qconsp
- 7. Arquitetura é aquela coisa que é difícil de mudar depois. Por essa razão, deve existir o mínimo possível dessa coisa. @leandronet #qconsp
- 10. c Apresentando: Um código C#!
- 11. c Essaéumaabstração do código (by NDepend) Assembly Classe Método
- 12. c
- 13. c
- 14. c c
- 15. Qual abordagem você utilizaria para fazer esse software? </Intermission>
- 16. Arquitetura e o desenvolvimento de Software
- 17. Espectro do Design Waterfall clássico Some DUF Agile XGH Design Emergente BDUF #qconsp @leandronet
- 18. Arquitetura Evolucionária e Design Emergente #Simples #Adaptativa #Foco do cliente #Agile #YAGNI #Iterativa #Flexível #qconsp @leandronet
- 19. Design Emergente "Não existe nenhum design no início. Você começa codificando uma pequena quantidade de funcionalidades, e vai acrescentando outras gradativamente, deixando que o design tome forma!” Martin Fowler @leandronet #qconsp
- 20. Sim, a entropia existe em software... Manter as coisas como estão, exige trabalho! #qconsp @leandronet
- 22. Quanto mais tempo você adiar suas decisões... ...Mais contextualizadas elas serão! @leandronet #qconsp
- 24. Práxis da Arquitetura Evolucionária
- 25. Dívida técnica sempre é uma vilã? Fuuuuuuu!!! Depende! OMG!! #qconsp @leandronet
- 26. Quadrante da dívida técnica “Nós não temos tempo para design” “Nós vamos lidar com as consequências” Prudente e De propósito Irresponsável e De propósito “O que são camadas?” “Agora nós sabemos que deveríamos ter feito isso” Prudente e Sem querer Irresponsável e Sem querer #qconsp @leandronet
- 27. Identificando padrões idiomáticos #qconsp @leandronet
- 28. Possibilidades no Visual Studio 2010 #qconsp @leandronet
- 29. Possibilidades no NDepend(1 de 2)
- 30. Possibilidades no NDepend(2 de 2)
- 31. Outras abstrações para visualização de métricas: CodeCity #qconsp @leandronet
- 33. JDK visto no CodeCity #qconsp @leandronet
- 34. Existem várias métricas e combinações de uso... LOC LOCM NOC ILCC ... ABC Vamos começar do básico! :) #qconsp @leandronet
- 35. Usando a matriz de dependência do NDepend
- 36. Design Emergente pelas métricas (1 de 5) #qconsp @leandronet
- 37. Design Emergente pelas métricas (2 de 5) #qconsp @leandronet
- 38. Design Emergente pelas métricas (3 de 5) #qconsp @leandronet
- 39. Design Emergente pelas métricas (4 de 5) #qconsp @leandronet
- 40. Design Emergente pelas métricas (5 de 5) #qconsp @leandronet
- 41. Para fechar, algumas dicas importantes...
- 42. É necessário tomar essa decisão agora? Posso adiar essa decisão com segurança? O que posso fazer para tornar essa decisão reversível? @leandronet
- 43. Toda e qualquer atividade dentro do desenvolvimento de software é importante. Pense sempre em flexibilidade. Não lute contra as “mudanças”. @leandronet
- 44. Tenha ciência do seu conhecimento (e da sua ignorância, se possível...) “A simplicidade consiste em subtrair o óbvio e acrescentar o significativo.” (John Maeda) Quando em dúvida, erre pela simplicidade. @leandronet
- 46. “Martin Fowler” + Design + Enterprise
- 47. Software metrics + NDependhttp://reverb.leandrodaniel.com http://voidpodcast.com http://www.ndepend.com
- 49. Obrigado! :) @leandronet contato@leandrodaniel.com http://reverb.leandrodaniel.com
Notas do Editor
- LOC: Lines of CodeLOCM: Lack of cohesion of methods (falta de coesão entre métodos)NOC: Number of ChildrenILCC: IL cyclomatic complexityABC: Association between methods
- O Princípio da responsabilidade única (SRP) está ficando popular entre a Comunidade de arquitetos de software hoje em dia. O princípio afirma que: uma classe não deve ter mais de uma razão para mudar. Outra maneira de interpretar o SRP é que uma classe não deve usar também muitos diferentes tipos de outras classes. Se nós estendemos a ideia a outro nível (módulos (assemblies, namespaces e métodos), certamente, se um elemento de código está usando dezenas de outros elementos de código diferente (no mesmo nível), significa que ele tem muitas responsabilidades. Muitas vezes o termo classe Deusou componente Deusé usado para qualificar esse pedaço de código. DSM pode ajudar a identificar elementos de código com muitas responsabilidades. Esse elemento de código é representado por colunas com muitas células azuis e linhas com muitas células verdes.
- Um padrão que é óbvio por um DSM é a estrutura de camadas (ou seja, acíclicos estruturais). Quando a matriz é triangular, com todas as células azuis no triângulo inferior esquerdo e todas as células verdes o triângulo superior direito e, em seguida, ele mostra que a estrutura é perfeitamente em camadas. Em outras palavras, a estrutura não contém qualquer ciclo de dependência.
- Ciclo de dependência: Se uma estrutura contém um ciclo, o ciclo será exibido por um quadrado vermelho sobre o DSM. Podemos ver que dentro do quadrado vermelho, verdes e azuis de células são misturadas em diagonal. Existem também algumas células pretas que representam mútuo uso direto (ou seja a está usando b e b é utilizando A).
- Alta coesão e baixoacoplamentoAideia de alta-coesão (dentro de um componente) / baixo acoplamento (entre componentes) é popular nos dias de hoje. Mas se alguém não é possível medir e visualizar as dependências, é difícil de obter uma avaliação concreta de coesão e acoplamento. DSM é bom em apresentando alta coesão. No DSM abaixo, um agregado ao quadrado óbvio em torno a diagonal é exibido. Isso significa que os elementos envolvidos na Praça tem uma alta coesão: eles são fortemente dependentes entre si embora. Além disso, podemos ver que eles ficam em camadas como não há nenhum ciclo. Eles certamente são candidatos a ser agrupados em um artefato de pai (como um namespace ou um assembly). Por outro lado, o fato da maioria das células ao redor da Praça vazia advogar para baixo acoplamento entre elementos do quadrado e outros elementos.
- Elemento popular: Um elemento de código popular é usado por muitos outros elementos de código. Elementos de código populares são inevitáveis (pense na classe String, por exemplo) mas um código popular não é uma falha. Isso apenas significa que em cada base de código, existem alguns conceitos centrais representados com as classes populares.Um elemento de código popular é representado por colunas com muitas células verdes e linhas com muitas células azuis.