Fabio's blog

O Guia de Arquitetura de Aplicações , Application Architecture Guide, fornece um guia prático para decisões de projeto e arquiteturais . Embora tenha sido feito para a arquitetura .NET o guia sintetiza idéias e conceitos de diversas fontes e propõe um conjunto de soluções para o desenvolvimento de vários tipos de aplicação.

Para cada uma desses tipos de aplicação ele define um arquétipo . O arquétipo do guia define, entre outras coisas:

• Objetivos
• Considerações de projeto
• Cenários chave
• Mapa de padrões

Os tipos de aplicação vistos são:

• Mobile applications
• Rich client applications
• Rich Internet applications
• Service applications
• Web applications

Além disso no início do guia ele oferece uma descrição de alguns conceitos básicos de arquitetura de software.

Links:

• Application Architecture Guide

Um termo que não gosto é o de Requisitos Não-funcionais, afinal o que é um requisito não funcional é um requisito sem função ???.

Alguns autores falam que é um termo disfuncional, na realidade copiei o título deste blog de uma seção do livro Software Achitecture in Practice , inclusive com o trocadilho. Eles preferem falar de atributos de qualidade.

Parece um jogo semântico tirado de 1984 de George Orwell, mais um truque do dupli pensar, entretanto não é, os nomes que damos as “coisas” afetam em muito a forma como as vemos e usamos.

Por exemplo, é mais fácil o cliente aceitar ações a favor dos atributos de qualidade, afinal para que gastar dinheiro com Requisitos que “Não tem função”. Entretanto quem não gastaria seus recursos melhorando os atributos de qualidade do sistema.

E os demais Requisitos não-funcionais?

Todo o Requisito não-funcional possui uma categoria, como por exemplo atributos de qualidade. Assim chame por sua categoria. Fica bem melhor do que falar em requisitos não-funcionais.

A algum tempo procuro algum grupo na web em que o tema central seja arquitetura de software. Quando já tinha desistido eis que Adriano Tavares me convida para o pangeanet.org .

Por enquanto estou como o convidado recém chegado que não conhece ninguém, ouvindo mais do que falando. Estou gostando muito do que “ouço” . Já li bons artigos de Marco Mendes e Alcebíades Júnior.

Como eu disse em outro post a arquitetura é algo que é feito no início do projeto . Isso leva a alguns pensarem que o arquiteto é necessário apenas no início do projeto. Entretanto durante toda a vida do projeto são feitas alterações da arquitetura.

Estas alterações podem ser intencionais ou acidentais[1]. As alterações acidentais ocorrem das várias decisões individuais de design que ocorrem durante o desenvolvimento que depois são identificadas com o nome de arquitetura. Ao contrário as mudanças arquiteturais intencionais são efetuadas por meio de decisões de design que tem como fim um arquitetura definida.

As decisões de design quando tomadas sem o acompanhamento de um Arquiteto pode levar a um comprometimento da arquitetura do sistema. Todavia nem sempre é possível contar com o Arquiteto para estes casos é importante que se tenha um documentação adequada da arquitetura que possas guiar os desenvolvedores.

Por fim , precisa-se de um arquiteto durante toda a vida do projeto embora no início sua atividade seja mais visível é importante a sua participação durante a evolução do sistema.

Referências:

• [1] – The Accidental Architecture, Grady Booch

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]