Fabio's blog

Este é o checklist para escrever padrões de Doug Lea:

1. Descreva um único tipo de problema
2. Descreva em que o problema ocorre
3. Descreva a solução como uma entidade de software passível de ser construida
4. Descreva os passos do projeto ou regras para construir a solução
5. Descreva as forças que conduzem para a solução
6. Descreva evidências que a solução é ótima para resolver as forças
7. Descreva detalhes que são permitidos variar e quais não são
8. Descreva ao menos uma instância de uso
9. Descreva evidências que a solução resolve de forma ótima o problema
10. Descreva os detalhes que são permitidos variar e os que não são
11. Descreva ao menos um instância atualmente em uso
12. Descreva evidências de generalidades através de diferentes instâncias
13. Descreva ou referêncie as variantes e subpadrões
14. Descreva ou referêncie outros padrões que se relacionam com este padrão
15. Descreva ou referêncie outros padrões que este padrão faz referência
16. Relacione com outros padrões com contexto similares, problemas e soluções

A muito tempo atrás , indo para banca de revista para comprar a primeira edição de uma revista recem lançada chamada Java Magazine, estava conversando com um amigo desenvolvedor de software sobre o futuro do desenvolvimento de software e chegamos a conclusão que o futuro seria das máquinas virtuais, e portanto do Java, no entanto tinha uma questão que eu não conseguia responder : “Eu não entendo para que é necessário um arquiteto de software.” Quando iniciei a desenvolver em Java entendi o porquê. Ao contrário do Delphi que vem com uma arquitetura “pronta” no Java você precisa definir a sua.

Embora nos anos subsequentes eu tenha efetivamente criado algumas arquiteturas para atender aos meus clientes eu o fazia de uma forma ad-hoc sem notar como esta área crescia. Ao ler o paper de Kruchten The Past,Present, and Future of Software Architecture observei esta evolução. Após ler este artigo me dei conta de como tinha evoluido a área e iniciei de imediato o processo de estudo, afinal : “nós(desenvolvedores de software) como os tubarões precisamos sempre nadar(aprender) para não morrermos afogados”^[1].

Eu tenho um método para estudar um assunto. Inicio lendo um tutorial ou um paper sobre o assunto e depois passo para um livro sobre o assunto depois começo a fazer alguns projetos exploratórios na área. No caso do estudo de Arquitetura de Software fiz o mesmo só que tive a ajuda do excelente artigo sobre The Past,Present, and Future of Software Architecture. Que possui uma excelente lista de referências.

Os principais papers são:

1. An Introduction to Software Architecture – neste paper é apresentado os estilos arquiteturais
2. Foundations for the Study of Software Architecture é lançado a formula Software Architecture={elements, forms, rationale}
3. 4+1 view architecture – uma única visão não é suficiente explana as 4+1 visões, excelente
4. A Field Guide to Boxology – explana os trade offs entre os diversos estilos arquiteturais
5. A Field Guide to Boxology(tabela)

Após ler os papers, você pode ler os livros:

• Software Architecture , Perspectives on an Emerging Discipline, que repete muito do que eu já tinha lido nos papers
• Software Architecture in Practice, espetacular
• Documenting Software Architecture estou atualmente lendo

Espero que este blog seja útil para aqueles que querem iniciar em arquitetura de software. Caso este seja seu caso deixe seu comentário.

• 1. Sandro Alves[Escovador de bits]