Fabio's blog

Como você sabe como um usuário de Subversion ou de Mercurial podemos facilmente copiar um ramo, branch, no controle de versão criando um ramo para adicionarmos código de uma nova funcionalidade. Porém em algum momento vamos ter que retornar os código alterados para o ramo principal. Se você esta só isso é tranqüilo quando você terminar o seu trabalho deve simplesmente efetuar o merge das suas alteração no ramo de origem. Quando todo o código estiver pronto efetuamos um release e tiramos uma nova copia do ramo original criando um ramo do release. Entretanto quando se tem vários desenvolvedores e vários fluxos de mudança a situação logo fica caótica.

Para resolver este problema usa-se um protocolo de atualização de ramos . A idéia é a seguinte se chamarmos o ramo original de mainline , o ramo que copiamos da mainline de codeline e pensarmos que toda codeline feita para adicionar novas funcionalidades esta abaixo da mainline e toda codeline feita para um release esta acima da mainline , nós criamos uma níveis entre as codelines. Estes níveis nos permite pensar que todo o código acima da mainline , código de um release, é mais estável que o código abaixo dele , por exemplo uma codeline adicionando uma nova funcionalidade ainda não testada. Portanto quanto mais alto estiver a codeline mais estável é o código.

O protocolo de atualização consiste em efetuar o merge imediatamente da codeline mais estável para as codelines menos estáveis e apenas efetuar o merge de uma codeline menos estáveis ao concluir o novo código e tiver efetuado os testes necessários.

Estes níveis formam uma escala de estabilidade de código que podemos chamar de “escala tofu” .

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.