segunda-feira, 29 de agosto de 2011

Impactos de SOA na Metodologia de Desenvolvimento de Software

Impactos de SOA na Metodologia de Desenvolvimento de Software




Quando a gente pensa em SOA. Várias coisas mudam com relação a forma padrão de se desenvolver software.

Geralmente um sistema é desenvolvido a partir uma demanda de negócio e o cliente desse sistema tem na cabeça um série de telas que seguem a uma determinada sequencia de passos.

Baseado nessa sequência de telas o analista sistemas confecciona casos de uso( no caso de MDS baseada no RUP) ou use estories (no caso de MDS baseada em SCRUM) com o objetivo de traduzir essa visão do cliente.

A princípio essas telas manipulam as informações ali postadas e as grava num banco de dados.

Ainda nesse contexto um arquiteto de sistemas pensa na tecnologia que será adotada para se desenvolver o sistema e no padrão de desenvolvimento que os desenvolvedores deverão utilizar para a implementação deste sistema.

Bom, até aqui acredito que não existam novidades. Tudo o que foi feito baseou-se no processo de negócio apresentado pelo demandante do sistema e acontece em função do sistema que está sendo desenvolvido. Mais tradicional que isso, impossível!

Quando uma empresa adota o SOA deve-se pensar de uma forma mais corporativa, ou seja, os esforços de desenvolvimento não devem se limitar apenas ao sistema em questão, mas sim ao reuso desses esforços na construção de outros sistemas. Falei alguma novidade? Muitos dirão que não. Afinal de contas as aplicações de hoje são compostas por componentes.

Esses componentes estão muito voltadas para uma tecnologia específica. Como exemplo, podemos citar sistemas feito em java. Estes podem conversar perfeitamente com outras aplicações java. Entretanto criar uma interface capaz de fazer dois sistemas feitos utilizando linguagens de programação diferentes pode ser um grande desafio.

É possível? Obviamente sim. É a melhor forma? Dependo da situação pode ser, contudo existem formas mais inteligentes de se desenvolver esses sistemas e é aí que entra o SOA.



Isto posto, vamos imaginar o seguinte cenário: imagine se transformássemos os componentes que constituem um sistema em serviços multiplataforma reutilizáveis imaginando ainda que esses componentes venham compor vários sistemas. Essa não seria uma forma inteligente e mais barata de se desenvolver um sistema? A resposta é COM CERTEZA.

Entretanto é importante desenvolver esses serviços de forma inteligente com baixo acoplamento e alta coesão e para fazer isso o SOA utiliza-se de oito princípios que tentam responder alguns questionamentos:



• Como identificar os serviços a serem criados?

• Que características deve ter esse serviço?

• Qual tamanho deve ter o serviço em questão?

• Esse serviço deve atender ao processo como um todo ou deve atender a apenas uma atividade desse processo?



Falaremos agora sobre os princípios do SOA:



1. Toda interface de um serviço deve ter um contrato formalizado

2. Os serviços devem ter baixo acoplamento

3. Os serviços devem ser abstratos

4. Os serviços devem ser reutilizáveis

5. Os serviços devem ser autônomos

6. Os serviços não devem manter estado

7. Os serviços devem ter a capacidade de serem descobertos

8. Os serviços podem ser compostos

Muito bem, será que o foco deste texto é realmente externar os impactos que uma MDS tradicional. Na primeira parte falamos sobre as diferenças. Agora vamos tratar dos impactos. Basicamente falaremos sobre as etapas envolvidas no ciclo de vida do desenvolvimento de sistemas.

1. Etapa de planejamento (alto impacto)

2. Etapa de análise (médio impacto)

3. Etapa de design (Impacto alto)

4. Etapa de teste (baixo impacto)

É isso aí.

2 comentários:

Hugo Maia disse...
Este comentário foi removido pelo autor.
Hugo Maia disse...

Olá Lucas, agradeço o comentário. Muito legal o teu site tb!!! Abs