Seções iMasters
Arquitetura de Informação + Desenvolvimento

Arquitetura de Software e Extensibilidade

Os princípios e as técnicas de engenharia de software possuem diversos objetivos, como padronização, organizar componentes, separação de responsabilidades, como também extensibilidade e composição.

Há muito tempo que se buscam soluções, que permitam que sejam construídos sistemas que sejam fáceis de modificar, mas que também possam ser estendidos com facilidade. O fluxo de mudanças em determinados tipos de negócios tem uma variação muito grande e os softwares que visam atender os mesmos, caso não sejam fáceis de serem estendidos, adicionando funcionalidades facilmente, certamente irão fracassar.

Atualmente, se vê no cenário mundial de arquitetura de software, um esforço grande em tornar real este desejo de softwares que sejam fáceis de estender. Ou seja, sistemas que sejam como um “lego”, em que peças são adicionadas com facilidade ao mesmo. Martin Fowler, em seu livro “Padrões de Arquitetura de Aplicações Corporativa”, apresenta um pattern chamado PlugIn Pattern, que tem a descrição da seguinte forma:

“Conecta classes durante a configuração em vez de na compilação.”

Esta frase simples sobre o pattern nos mostra a ideia central. O Plugin, como seu próprio nome diz, tem o objetivo de em tempo de execução, conectar objetos que respeitem um determinado contrato de serviço, e que os mesmos possam ser carregados em tempo de execução. O Plugin pattern é uma das formas que podemos utilizar para ter uma arquitetura extensível.

Extensibilidades e Contratos de Serviço

É necessário entender que, precisamos estender o que muda e o que varia. Ou seja, utilizar a extensibilidade com sabedoria. Para conseguir ter um software extensível, precisamos enxergar os pontos que terão um maior fluxo de mudança e definir contratos de serviço ou uma interface de comunicação. Um contrato de serviço ou interface de comunicação é um contrato em que serão especificadas regras a serem respeitadas.E isso é justamente o essencial para aquele contrato e que também pode ter complementos diferentes, como por exemplo, Login, Tratamento de Exceções e outras questões. Vejamos um exemplo no diagrama abaixo:

O contrato de serviço ou interface de comunicação propriamente dito:

Veja que é definido um contrato, alguém que calcule os juros, pois quando um financiamento é realizado, uma instituição financeira está por trás e cada instituição tem seu modo de calcular os juros.

O cálculo dos juros é um ponto de extensão, um ponto em que se faz necessário trabalhar com a extensibilidade. Poderíamos também, já partindo para a parte de infraestrutura, tornar extensível a parte do sistema que trata de Log de informações, seja ela log de erro ou de transação. Veja o outro exemplo:

No caso de tornar o mecanismo de efetuar logs extensível, temos um contrato de serviço que define o que um “logger” precisa fazer. Além disso, temos as classes concretas que efetuam log de diversas maneira, como banco de dados, arquivo XML, Log no Event Viewer do windows.

No Log de banco de dados, a classe aponta para uma abstração de um repositório
que, sendo abstrato, também define um contrato de serviço. Sendo assim, se hoje
o log é feito no banco de dados em um servidor SQL Server, por exemplo, amanhã,
se passar a ser feito no Oracle, a mudança não causará impacto no mecanismo de
login.

Veja como a extensibilidade faz com que o software seja como um “lego”, em que o contrato de serviço é como se fosse a parte em que será feito o “encaixe”. E a implementação concreta age como o “pino” de encaixe, havendo assim uma arquitetura flexível e de fácil manutenção e evolução.

Em breve abordaremos tecnologias para auxiliar na criação de Arquiteturas flexíveis como o MEF, por exemplo .

Abraços e até a próxima.

Mensagem do anunciante:

Torne-se um Parceiro de Software Intel®. Filie-se ao Intel® Developer Zone. Intel®Developer Zone

Comente também

5 Comentários

Fernando

Muito bom Carlos, uma série de posts sobre extensibilidade vai ser muito bom para fazer com que os leitores mudem a forma de projetar software.

Entendo que criar um software extensível desde sua concepção gera benefícios enormes para sua manutenção e evolução.

bruno

Resumindo, é programar para interface. As dependência que possuem variações você utiliza uma variável/campo/parâmetro do tipo interface. Façam referência sempre para interface ou classe abstrata e raramente para classes concretas.

Tupiniquin

Uma pena que 95% das faculdade de TI no Brasil tem professores que sequer sabem falar e escrever em português corretamente, quem dirá explicar o que é programar para uma interface. Lástima!

Caio Braga

Esse artigo não tem que estar em Arquitetura de Informação. São coisas bem diferentes. Abraços.

Ygor

Engraçado. Isso me lembrou um pouco o padrão strategy. http://www.dofactory.com/Patterns/PatternStrategy.aspx

Obrigado pela contribuição.

Qual a sua opinião?