quinta-feira, 21 de maio de 2009

Desenvolvedores e SOA

Ao depararmos com novos assuntos relacionados à tecnologia temos visões distintas dependendo da experiência que temos, dos projetos nos quais estamos envolvidos dentre outros aspectos, porém, quando aparece um tema novo de conteúdo mais genérico envolvendo uma visão horizontal de sistemas a tendência é visualizar tal assunto como algo complexo.

Pela característica horizontal destes assuntos, torna-se necessário o mapeamento do que é relevante para cada papel dentro de um processo de desenvolvimento de software. Um destes assuntos é SOA (Service Oriented Architecture). Desenvolvedores em geral podem imaginar que isso é assunto para arquitetos de software e de sistemas em geral, mas, pelo contrário, SOA trás um leque de novas frentes de desenvolvimento que devem ser atacadas para que desenvolvedores se preparem para atuar em grandes projetos.

Esta apresentação ajuda os desenvolvedores a terem esta visão. Este post visa justamente ser um auxílio inicial e um empurrão àqueles que desenvolvem e querem se preparar para atuar em projetos cuja arquitetura seja voltada a serviços.

Boa leitura!

segunda-feira, 18 de maio de 2009

Métricas e o café !


A JSR-275 é uma API do java para tratamento de unidades de medidas e será utilizada como tipo de diversos atributos que armazenam valores cujo valor final é conhecido somente se associado a uma unidade de medidas.
Por exemplo, se um atributo armazena a distância entre dois pontos, o valor armazenado, suponhamos 100, é sempre relativo à unidade de medida que se considera. Assim, pois, se falarmos que 100 é o valor e que a unidade é km daí sim tiramos a informação concreta e real.
Basicamente esta API trata de elementos mensuráveis (Measurable) e das medidas propriamente ditas (Measure). Estes por sua vez estão sempre vinculados às chamadas dimensões (Quantity), que representam a natureza relativa à medida em questão. Estas dimensões estão representadas na API, algumas delas são representadas abaixo, enfatizando que as demais são formadas por derivações das dimensões básicas ou transfomações das mesmas aceitas pela comunidade:
DimensãoUnidade (SI)Quantity (JSR-275)
Tamanho metros (m) Length
Massaquilogramas (kg) Mass
Duração segundos (s) Duration
Corrente Elétricaamperes (A)EletricCurrent
Temperatura Termodinâmica Kelvin (K)Temperature
Intensidade Luminosa candela (cd)LuminousIntensity
Quantidade de Substância moles (mol) AmountOfSubstance

Além das dimensões a API representa também as unidades de medidas. Há a separação entre as medidas do sistema internacional de medidas e as não SI.
Nas aplicações de mercado, frequentemente é necessário realizar conversões das diversas unidades de medida, o que é plenamente suportado pela API. Uma boa estratégia para lidar com valores que representam unidades de medida é persistir os valores num determinado grupo de unidades de medidas, por exemplo, o SI e na camada de apresentação realizar as conversões quando necessário com apoio da API.
Neste site encontram-se algumas conversões comuns entres as diversas unidades de medidas. Bons códigos!

Estudo sobre complexidade arquitetural


Um excelente estudo realizado pela NASA endereça um dos assuntos mais críticos contidos em grandes sistemas computacionais, como apresentado, o sistema de controle aeroespacial: Como lidar com o crescimento da tamanho e da complexidade de um software ao longo do tempo e entre diferentes projetos realizados com base em um mesmo domínio? O estudo, apesar de ser baseado no domínio aeroespacial, pode ser aplicado a qualquer sistema que tenha as características por ele apresentado. É uma leitura rica e repleta de reflexões possíveis para a nossa realidade e enfatiza basicamente os seguintes aspectos:
  1. A importancia no investimento em arquitetura de software
  2. A necessidade de se enxugar ao máximo os requisitos diminuindo complexidade
  3. Tratar o acréscimo de complexidade no software em todas as fases do projeto
  4. Tratar sistematicamente desde os requisitos a disciplina de "proteção a falhas"
Estes aspectos acima citados, ganham grande enfoque e estão diluídos em 16 recomendações "macro" abaixo listadas:
  • Difundir a consciência de complexidade entre as diversas camadas do sistema para todos os participantes de um projeto
  • Documentar os motivadores e bases para os requisitos e seu objetivo-chave para o negócio, promovendo eliminação de requisitos desnecessários, diminuição de sua complexidade e amarração com o escopo.
  • Difundir o conhecimento do negócio, com todos os seus aspectos multidiciplinares
  • Introduzir a análise arquitetural o mais cedo possível no projeto
  • Realizar revisões arquiteturais
  • Dar maior suporte e investir em arquitetos de software
  • Envolver os usuários finais desde o inicio e continuamente no processo
  • Decisão "Make-or-Buy" (COTS) baseada na facilidade de separação desta do restante do sistema e da complexidade no processo de testes
  • Investir numa arquitetura de referência
  • Estimular a difusão tecnológica entre equipes e projetos
  • Usar ferramentas de análise estáticas de código e "code compliance"
  • Padronizar a terminologia usada para definir os diversos tipos de falhas de sistema, através da definição de um padrão léxico para proteção a falhas e definição de um conjunto de principios e funcionalidades que caracterizem arquiteturas de software a respeito de desta disciplina.
  • Estabelecer a revisão dos requisitos ou proposta baseada nos aspectos de tratamento de falhas.
  • Desenvolver a cultura de proteção a falhas e autonomia de sistemas
  • Pesquisar técnicas de contenção de falhas
  • Coletar e USAR métricas de software (Como medir complexidade das fases de software)?
Vale a pena o estudo do documento completo. Ele trás ainda boas referências e pequenos estudos práticos. Bons estudos!