terça-feira, 24 de novembro de 2009

SOA Manifesto

Após o mundo de TI passar por algumas rodadas de disseminação do conceito SOA, sem esquecer de alguns tumultos “provocados” pelo post “SOA is Dead; Long Live Services”, alguns bam-bam-bans no tema, motivados por Thomas Erl e incluindo a autora do post citado, compilaram o “SOA Manifesto”. Segue uma tradução livre:

 

Manifesto SOA

Orientação a serviço é um paradigma que direciona o que você faz.
Arquitetura orientada a serviço é um tipo de arquitetura que resulta da aplicação de orientação a serviço.

Nós aplicamos orientação a serviço para auxiliar organizações a entregar valor de negócio sustentável de forma consistente, com maior agilidade e eficiência de custo, alinhado às necessidades de mudança do negócio.

Através de nosso trabalho nós priorizaremos:
Valor de negócio acima de estratégia técnica
Objetivos estratégicos acima de benefícios específicos de projeto
Interoperabilidade intrínseca acima de integração customizada
Serviços compartilhados acima de implementações de propósito específico
Flexibilidade acima de otimização
Refinamentos evolutivos acima de busca da perfeição desde o início
Ou seja, enquanto nós valorizamos os itens da direita, nós valorizamos ainda mais os itens da esquerda.

 

Princípios que Guiam o Manifesto SOA

Nós seguimos estes princípios:
Respeitar a estrutura social e de poder de uma organização.
Reconhecer que SOA requer mudança em vários níveis.
O escopo da adoção de SOA pode variar. Manter esforços gerenciáveis e dentro de limites significativos.
Produtos e padrões sozinhos não lhe fornecerão SOA nem aplicarão o paradigma de orientação a serviços para você.
SOA pode ser concretizada através de várias tecnologias e padrões.
Estabelecer um conjunto uniforme de políticas e padrões corporativos baseado em padrões de facto da indústria e da comunidade.
Buscar uniformidade no exterior e permitir diversidade no interior.
Identificar serviços através da colaboração entre interessados de negócio e tecnologia.
Maximizar o uso de serviços considerando o escopo atual e futuro de utilização.
Verificar se os serviços satisfazem os objetivos e requisitos de negócio.
Evoluir os serviços e sua organização em resposta ao seu real uso.
Separar os diferentes aspectos de um sistema que mudam em ritmos diferentes.
Reduzir as dependências implícitas e publicar todas as dependências externas para aumentar a robustez e reduzir o impacto de mudanças.
Em todo nível de abstração, organizar cada serviço em torno de uma unidade de funcionalidade coesa e gerenciável.

 

E ai, concorda? Então vai e “assina embaixo”! :-)

quarta-feira, 18 de novembro de 2009

Engenharia de Software – Escopo, Prazo, Custo e Qualidade

Sempre que falamos em desenvolvimento de software surge o triângulo:

Não há mágica a ser feita. Para uma mesma área, aumentar um lado implica em diminuir um outro. Mas isto pressupõe que o escopo é (totalmente) conhecido e, o mais importante, não sofrerá mudanças. Já foi esse tempo, não dá mais pra atender ao cliente com escopo fechado. Já dizia o filósofo Heráclito: “a única constante é a mudança”.

No artigo do Ivar Jacobson “Closing the Gap between Business and IT”, ele cita:

“We need to deliver results often and with high quality, on frequent intervals.  IT will have to accept that the business will change its mind about what it wants. This is a natural part of seeing results more frequently, and the feedback obtained is valuable and important. Frequent demonstrations of progress creates confidence and increases productivity, quality and it gives quick results.”

Em resumo, temos que saber lidar com a mudança e demonstrar resultados rapidamente e com qualidade.

Em outro artigo, da Marília Coelho, “Precisamos ser mais psicólogos que engenheiros para ter sucesso com engenharia de software”, a autora fala das dificuldades no entendimento do problema do cliente e cita uma frase de Einstein:

“Einstein certa vez afirmou que se ele tivesse uma hora para salvar o mundo, gastaria 55 minutos definindo o problema e apenas cinco minutos buscando a solução.”

Isto tem a ver com a “pressa” e com a visão míope do “dá pra fazer”, sem buscar o entendimento sobre a real necessidade do cliente e sem explorar as alternativas mais apropriadas.

Ela também cita alguns dados do Standish Group:

“41% dos projetos falham em adicionar valor ao negócio e sobre o Retorno de Investimento – ROI.

49% dos projetos ultrapassam as estimativas iniciais de custo.

Somente 28% dos projetos acontecem no prazo e no orçamento.”

O escopo fechado traz, no início do projeto, a ilusão da certeza do prazo e do custo. Qualquer mudança posterior é temida! A tal da “change request”!

A autora ainda discorre sobre a necessidade de mudança de cultura na engenharia de software e conclui:

“Para que os três pilares – processo, ferramentas e pessoas – funcionem de forma harmônica na organização, o suporte executivo é fundamental, pois as ansiedades, e a pressão do “fazer para ontem” são forças que devem ser gerenciadas corretamente. Os números mostram que continuar como está não é bom para o negócio e não é bom para TI. Pense em fazer algo para mudar o futuro da engenharia de software, conseqüentemente mudando a percepção de que TI não é um centro de custo, mas sim uma área que agrega valor ao negócio através da inovação tecnológica.”

Pensamentos Finais

Escopo muda, é um fato, e assim deveria ser tratado. Com entregas ágeis, frequentes e com qualidade o prazo (final) deixa de ser um “bicho-papão” e a previsibilidade sobre o custo torna-se maior. Ganhar a confiança do cliente, mantendo-o sempre envolvido, aumenta as chances de sucesso pois, no fim das contas, há um relacionamento humano.

Vida longa e próspera à engenharia de software!

domingo, 15 de março de 2009

Certificação - Análise e Design

Análise e Design são atividades do ciclo-de-desenvolvimento de software que lidam, respectivamente, com o tratamento/entendimento do problema e a "criação" da solução técnica para atender os requisitos de software do projeto.

No contexto do RUP (Rational Unified Process), Análise e Design são apresentadas no formato de uma disciplina. Esta disciplina engloba fluxo de trabalho, atividades, papéis e artefatos que orientam o entendimento do problema e a elaboração da solução técnica do software a ser desenvolvido. É nesta disciplina que um dos assuntos mais relevantes do processo unificado é tratado: Arquitetura de Software.

Este post cita, para os amigos leitores, duas certificações relacionadas a A&D.

A primeira não se trata realmente de uma certificação de A&D, mas de UML. Ou seja, tem o intuito de avaliar o quanto você domina a linguagem visual mais usada para representar os modelos de A&D.

 

Certificação UML - OMG:

Site para certificação UML 2 da OMG:

OMG Certified UML Professional (OCUP)

Há 3 níveis de certificação:

  • Fundamental: conceitos básicos, principais elementos e diagramas;
  • Intermediate: amplia o escopo e exige conhecimentos mais avançados dos elementos da UML;
  • Advanced: amplia ainda mais o escopo chegando a exigir conhecimentos sobre a arquitetura da linguagem, representação de semântica usando UML, relação com MDA, conhecimento da OCL (Object Constraint Language) que é uma linguagem de texto que estende a UML para definições e restrições de modelos e metamodelos que não são simples ou mesmo possíveis de serem feitos por diagramas, etc.

Para nós, reles mortais, não parece valer muito a pena ir além da Intermediate. Talvez a Fundamental já baste.

Apesar de interessante (principalmente para o mercado), a certificação de UML, como já dito acima, é limitada à especificação de UML. No escopo de A&D, UML é uma ferramenta (poderosa) que pode ser usada para representar os modelos, através de seus vários diagramas: caso de uso, classes, sequência, implantação, para citar alguns.

De outra forma, uma certificação que avalie o grau de maturidade de um analista quanto ao emprego da UML como ferramenta, além do conhecimento de padrões de design e boas práticas de A&D (baixo acoplamento, alta coesão, poder de abstração, identificação de interfaces, etc) parece ser mais relevante.

A certificação de A&D da IBM Rational abrange todos estes quesitos. Entretanto, é bom deixar claro que ela é fortemente baseada na disciplina de A&D do RUP. Ou seja, além de avaliar estes quesitos, ela também exige seus conhecimentos específicos na disciplina de A&D do RUP. Não sei se isto pode ser ruim, visto que RUP é um dos processos mais seguidos no mundo. Assim, mesmo que sua empresa não siga o RUP, um profissional com conhecimento profundo sobre esta disciplina só tem a acrescentar. Isto se aplica especialmente para arquitetos de software e designers.

 

Certificação A&D - IBM Rational:

Site para certificação de A&D da Rational:

IBM Certified Solution Designer - Object Oriented Analysis and Design, vUML 2

Para obter a certificação é necessário passar em 2 testes:

  1. Test 833 - Object Oriented Analysis and Design - Part 1 (Analysis): trata questões relacionadas ao entendimento do problema;
  2. Test 834 - Object Oriented Analysis and Design - Part 2 (Design): exige conhecimentos que afetam a definição da solução técnica para os requisitos de software.

Referências

- Livros sobre o assunto que vale a pena conferir:

- Um colega blogueiro postou algumas dicas sobre A&D, confiram em: Análise e Design: Para que serve e como fazer? [José Papo].

 

Dicas

- Estude bem a disciplina de A&D do RUP

- Leia os livros UML Distilled e Applying UML and Patterns

- Entenda a aplicação de design patterns

- Por último, mas talvez o mais importante: pratique A&D!

Boa Sorte!!!

terça-feira, 17 de fevereiro de 2009

Refatoração em Banco de Dados

Muitos de nós já estamos acostumados com o termo Refactoring, uma boa prática amplamente divulgada por Martin Fowler

Refatoração = remodelar (reprojetar) sem alterar comportamento.

O termo tornou-se comum quando falamos em programação orientada a objetos, mas o conjunto de boas práticas pode ser estendido a outros nichos, como programação em banco de dados.

O livro “Refactoring Databases”, do Scott W. Ambler, trata das técnicas de refactoring empregadas em banco de dados (mais informações ao final).

Selecionei deste livro 2 exemplos de Refatoração em Banco de Dados: “Replace Column” e “Merge Columns” . Segue resumo.

 

1 – Replace Column (página 126)

Motivação: O tipo da coluna deve ser alterado (ex.: numérico para alfanumérico).

Exemplo: Para um dado sistema, a informação que identifica um Usuário deve ser mantida no formato Alfanumérico. Atualmente, esta informação é armazenada no BD no formato Numérico. Vejam na figura abaixo os schemas original, do período de transição e o final.

Mecânica de Alteração:

1) Cria-se a nova coluna (CustomerID);

2) Torna-se a coluna que será substituída (CustomerNumber) deprecated. Ou seja, a coluna é marcada para eliminação. No exemplo, isto é representado através da indicação “{drop date = June 14 2007}”

a. Deprecate é um termo comum em Java utilizado para indicar que um método de uma classe está defasado e, possivelmente, será eliminado desta classe em uma próxima versão.

3) Cria-se uma trigger (SynchronizeCustomerIDNumber) para manter as informações das colunas sincronizadas. A trigger deve ser invocada para qualquer mudança nas colunas. Esta trigger já deve “nascer” deprecated. No exemplo, isto é representado através da indicação “{event = update | insert, drop date = June 14 2007}”;

4) Converter os dados da coluna original para a nova coluna (CustomerNumber para CustomerID);

5) Durante o período de transição, deve-se atualizar outras tabelas e os programas que acessam o dado alterado (refatorar os códigos e atualizar validações de dados).

6) Após o período de transição, elimina-se a coluna anterior (CustomerNumber) e a trigger.

image

Figura 1. Exemplo de alterações em um schema utilizando a Técnica de Refatoração BD “Replace Column”.

 

2 – Merge Columns (página 92)

Motivação: Existência de colunas que guardam a mesma informação (replicação de informação); Informação “quebrada” em várias colunas; Colunas com informações similares que convergiram para uma mesma informação.  

Exemplo: Para um dado sistema, o número de telefone do Usuário deve ser mantido como uma informação única obtida da concatenação de Código de Área e Local. Atualmente, é guardado no BD separando os códigos de País, Área e Local. Vejam na figura abaixo os schemas original, do período de transição e o final.

Mecânica de Alteração:

1) Cria-se a nova coluna (PhoneNumber);

2) Marca-se as colunas anteriores como deprecated. No exemplo, isto é representado através da indicação “{drop date = December 14 2007}”

3) Cria-se uma trigger (SynchronizePhoneNumber) para manter as informações das colunas sincronizadas. A trigger deve ser invocada para qualquer mudança nas colunas. Esta trigger já deve “nascer” deprecated. No exemplo, isto é representado através da indicação “{event = update | insert, drop date = December 14 2007}”;

4) Converter os dados das colunas originais para a nova coluna (PhoneNumber = merge column);

5) Durante o período de transição, deve-se atualizar outras tabelas e os programas que acessam o dado alterado (refatorar os códigos e atualizar validações de dados).

6) Após o período de transição, elimina-se as colunas anteriores (PhoneAreaCode e PhoneLocal) e a trigger.

image

Figura 2. Exemplo de alterações em um schema utilizando a Técnica de Refatoração BD “Merge Columns”.

 

Mais sobre o livro

Antes de apresentar as técnicas de refatoração em si, o livro explica como a idéia surgiu e evoluiu. Também é apresentado um processo que visa orientar na aplicação destas técnicas. A importância sobre Testes em Banco de Dados é ressaltada.

Várias outras técnicas são apresentadas. Elas são subdivididas nas categorias: Estruturais (os 2 exemplos acima estão aqui), Qualidade de Dados, Integridade Referencial, Arquiteturais e Métodos.

Sobre o Autor:

O autor, Scott W. Ambler, é bem conceituado e já escreveu vários livros sobre os assuntos: Orientação a Objetos, Processo Unificado, Métodos Ágeis, EJB, Bancos de Dados, UML, etc

Ele mantém um site sobre suas obras.

URL: http://www.ambysoft.com/scottAmbler.html

Há também o site do livro que apresenta um “Catálogo de Refatorações de Banco de Dados”.

URL: http://www.agiledata.org/essays/databaseRefactoringCatalog.html

Boa leitura!