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 Architectureestou 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]

Esta imagem de Escher ilustra bem a arquitetura de software. Atualmente estou lendo o livro Software Architecture in Practice que na página 23 define:

A arquitetura de software de um programa ou sistema de computador é a estrutura ou estruturas do sistema, que compreende os componentes de software, as propriedades externamente visíveis destes componentes e as relações entre eles.
[Bass 98]

Pretendo escrever um resumo do livro em breve.

Tirado de pythonlogia :

Ao contrário do que muitas pessoas pensam duck typing não é um mecanismo disponível em linguagens de programação que usam tipagem dinâmica mas sim uma técnica (ou prática) de desenvolvimento. Essa técnica é explicada da seguinte forma:

Se um objeto anda como um pato e faz quack como um pato então ele é um pato.

O problema dessa explicação é que ela não fornece muitos elementos úteis para que as pessoas possam entender exatamente como isso funciona então irei recorrer à outra citação extraída do livro Design Patterns:

Program to an interface, not an implementation. (Programe para uma interface, não para uma implementação).

Duck Typing é uma técnica que funciona com qualquer linguagem de programação com suporte ao paradigma OO e diz basicamente que se o seu objeto responde à uma determinada mensagem (chamada de método) característica de um determinado tipo de objeto então esse objeto também pode ser considerado do mesmo tipo.

Acredito que esta técnica seja mais fácil de ser utilizada em linguagens dinâmicas como Python, Ruby e Smalltalk mas como fazer em Java? Em Java para que usemos um determinado comportamento de um objeto é necessário que ele defina previamente que usa a interface com o comportamento desejado.

leia mais

Ao se definir uma arquitetura de software é necessário também definir uma pilha de aplicativos que permita o desenvolvimento do sistema. A LZT tem um interessante case que foi apresentado na Pycon de desenvolvimento de software para postos de gasolina . Abaixo segue a pilha de aplicativos utilizados pela LZT que têm 8 programadores e 16 funcionários no total.

• CVS
• sqlalchemy
• Elixir
• Genshi
• simpleTAL
• ReportLab
• GTK
• Ubuntu/FreeBSD/Windows