Lançado o Eclipse Galileo
A Fundação eclipse anunciou hoje o lançamento do Eclipse Galileo. Um dos destaques é o Xtext que permite a criação de DSL.
A Fundação eclipse anunciou hoje o lançamento do Eclipse Galileo. Um dos destaques é o Xtext que permite a criação de DSL.
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:
Os tipos de aplicação vistos são:
Além disso no início do guia ele oferece uma descrição de alguns conceitos básicos de arquitetura de software.
Links:
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.
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.
image: detail of installation by Bronwyn Lace