De que se trata o artigo

Um dos principais desafios ao se construir soluções na abordagem SOA é a complexidade na fase de Análise e Projeto. Neste artigo descrevemos um método de Análise e Projeto em SOA criado a partir do estudo de propostas existentes e de boas práticas.


Para que serve

O método serve como orientação para que arquitetos e analistas sejam capazes de identificar e especificar serviços de forma consistente, resultando em soluções que sigam efetivamente os princípios da abordagem SOA.

Em que situação o tema útil

Com a adoção da abordagem SOA, espera-se obter benefícios como aumento do reuso e flexibilidade para atender às demandas do negócio. Mas para que benefícios se concretizem, é fundamental que os serviços sejam devidamente identificados e especificados.

Autores: Henrique Shoiti Fugita e Davi Carvalho S., Jr.

Agilidade e complexidade são palavras cada vez mais utilizadas no mundo dos negócios, qualquer que seja a área. Este dinamismo e necessidade de lidar com cenários cada vez mais complexos exigem uma integração cada vez maior entre as áreas das empresas, e entre estas e seus fornecedores e clientes.

Este é o contexto em que vivemos hoje. O comportamento da bolsa de valores de Tóquio, no Japão, já está sendo monitorada em tempo real pelos analistas financeiros do Brasil e de outras partes do mundo. O comentário de um consumidor no seu Twitter, sobre uma nova bebida que acabou de ser lançada, é fundamental para as decisões comerciais e de marketing da empresa que a fabrica.

A arquitetura orientada a serviços (SOA) surge neste cenário. SOA vem sendo aceita como um estilo de arquitetura, uma abordagem para integrar as competências e informações destes vários domínios, estruturando as aplicações de software em serviços. Como resultado, espera-se que SOA traga flexibilidade e agilidade às aplicações e facilite a integração entre elas.

Entendendo SOA

Existem dezenas ou talvez centenas de definições de arquitetura orientada a serviços (SOA). Por trás de qualquer uma destas visões do que é SOA, temos o conceito de orientação a serviços.

Service-oriented architecture (SOA) é um estilo de arquitetura de software que suporta a abordagem de orientação a serviços. Mais do que uma proposta de arquitetura, SOA propõe uma forma de projetar e desenvolver soluções de software como serviços ou componentes de serviço.

Krafzig, Banke e Slama em sua obra “Enterprise SOA” (EUA, Prentice Hall, 2004) apresentam os componentes desta arquitetura, que se relacionam entre si, e podem ser compostos por outros, como pode ser visto na Figura 1.

Figura 1. Elementos de uma Arquitetura Orientada a Serviços.

Como um framework extensível e flexível, SOA reúne características únicas que geram valor para o negócio. Alguns exemplos: redução de custos através de reuso, maior facilidade de integração devido ao baixo acoplamento, e construção de aplicações mais flexíveis e independentes de ambiente operacional, e hardware.

Basicamente, uma arquitetura SOA se caracteriza pela interação de três tipos de agentes de software: os Provedores de Serviço, os Consumidores (ou Clientes) de Serviço e o Registro de Serviço – conforme a Figura 2.

Figura 2. Agentes de uma arquitetura SOA.

A importância de Análise e Projeto em SOA

Em um método tradicional de desenvolvimento de software, temos a fase de Análise e Projeto, em que os requisitos identificados são analisados para dar origem a um conjunto de especificações de funcionalidades de um novo sistema. Atualmente, este é um método já bem conhecido e maduro.

O desenvolvimento de soluções orientadas a serviços é recente, mas impõe questões que não são solucionadas com as técnicas dos métodos tradicionais. Quais requisitos de negócio e quais funcionalidades devem dar origem a serviços? É melhor implementar um novo componente de serviço ou expor um sistema legado como serviço? Como especificar um serviço de modo que ele seja reusável, autônomo e apresente baixo acoplamento? Qual o nível de granularidade adequado para um serviço?

A fase de Análise e Projeto numa abordagem SOA deve responder a essas questões, pois é justamente nesse momento que os serviços de uma solução SOA são identificados, definidos e especificados. Por isso, trata-se de uma etapa fundamental para o desenvolvimento de uma solução que efetivamente siga o paradigma de orientação a serviços e que esteja alinhada com os requisitos do negócio.

Um serviço mal identificado ou mal especificado corre o risco de nunca ser reusado, dar origem a soluções engessadas ou precisar de manutenção bem antes do esperado, gerando impacto em aplicações que dele dependem e retrabalho.

Um método que identifique e especifique corretamente os serviços é condição básica para alcançarmos os objetivos de um “ecossistema” baseado em SOA: agilidade, flexibilidade, reuso, independência de plataforma de hardware ou software, baixo acoplamento, desconstrução dos “silos” de informação e, principalmente, o alinhamento entre as demandas do negócio e as soluções de TI.

E esta é justamente a proposta do Método de Análise e Projeto Orientado a Serviços (MAPOS), apresentado aqui de forma resumida.

MAPOS – Método de Análise e Projeto Orientado a Serviços

O MAPOS é o resultado de uma dissertação de mestrado apresentada na Escola Politécnica da Universidade de São Paulo (POLI/USP). O método propõe uma abordagem de Análise e Projeto em SOA, descrevendo como realizar a identificação, análise e especificação de um conjunto de serviços alinhados com os requisitos de negócio e aderentes aos princípios da orientação a serviços.

O MAPOS tem como referências as poucas propostas existentes atualmente, tais como as iniciativas da IBM, de Thomas Erl (reconhecido autor e conferencista de SOA), além de trabalhos de pesquisa de Michael Papazoglou e da dupla Eric Marks e Michael Bell. Como proposta, o método busca unificar as boas práticas existentes e atender aos requisitos de Análise e Projeto impostos pela abordagem SOA.

Ele inicia-se na Modelagem de Negócio, passa pelas fases de Análise e Projeto (abrangidas pelo método), seguindo adiante com atividades de Construção, como Implementação e Testes, conforme pode ser visualizado na Figura 3.

Figura 3. Atividades do Método de Análise e Projeto Orientado a Serviços.

A seguir serão descritas as atividades de todo o ciclo de vida, a partir da fase de Modelagem de Negócio que precede a Análise e o Projeto Orientados a Serviços, até a fase de Construção subsequente.

Modelagem de Processo as-is e to-be

Na Modelagem de Processo as-is, o Analista de Processos deve levantar o estado atual dos processos de negócio envolvidos no projeto. Como resultado desta atividade, temos um modelo representando os processos de negócio antes do projeto.

Na Modelagem de Processo to-be, o Analista de Processos realiza avaliações e simulações e propõe modificações ao processo com o intuito de atender aos requisitos de negócio previamente definidos. Tais modificações do processo podem ser mudanças no fluxo de trabalho, automatização de atividades manuais, integração com aplicações, etc. Como produto desta atividade, é elaborado um novo modelo descrevendo o estado futuro dos processos de negócio, após o projeto.

Os modelos podem ser representados na forma de casos de uso de negócio ou preferencialmente utilizando uma notação de processo, como BPMN, que pode ser convertida diretamente para a linguagem WS-BPEL por diversas ferramentas existentes no mercado.

Identificação de Serviços Candidatos

Esta primeira atividade da fase de Análise tem como ponto de partida o modelo de processo to-be ou modelo de casos de uso de negócio produzido durante a Modelagem de Negócio.

...
Quer ler esse conteúdo completo? Tenha acesso completo