MAPOS (FUGITA e HIRAMA, 2008a) (FUGITA e HIRAMA, 2008b) é uma proposta de método para análise e projeto fundamentada nos princípios da orientação a serviços e nas melhores práticas existentes em vários métodos de desenvolvimento de sistemas orientados a serviço, como: Papazoglou e van den Heuvel (2006), RUP plugin for SOMA (IBM, 2008), Erl (2005) e Marks e Bell (2006).
Na Figura 2.8 são mostradas as fases do ciclo de desenvolvimento no qual MAPOS se insere e suas respectivas atividades.
Na fase Modelagem de Negócios especificam-se os requisitos do sistema de software, com a realização das atividades: Modelagem de processos as-is e Modelagem de processos to-be. A modelagem de processos as-is cria uma representação dos processos de negócio da forma como eles são executados na empresa. Esse modelo é útil para que clientes e interessados no sistema de software entendam como seus negócios são conduzidos. Esse entendimento permite maior precisão sobre requisitos do sistema de software e maior retorno do investimento. Na modelagem de processos to-be o analista de negócios avalia o modelo as-is buscando identificar possíveis melhorias, originando o modelo de processos to-be. Os requisitos para desenvolvimento do sistema de software derivam deste modelo. Esses modelos podem ser representados usando-se casos de uso da UML 2.0 ou por meio da linguagem Business Process Model and Notation (BPMN).
Figura 2.8: Método de Análise e Projeto Orientado a Serviços (FUGITA, 2009).
Na fase Análise, três atividades são conduzidas para identificar os serviços que irão compor a solução SOA:
Identificação de serviços candidatos: utiliza como artefato de entrada o modelo de processos to-be. Os processos são decompostos em uma série de passos, que são mapeados como operações candidatas. As operações com um mesmo contexto lógico e semântico são agrupadas, gerando os
serviços candidatos, representados no modelo de serviços candidatos que constitui o artefato de saída dessa atividade;
Análise de gap: avalia quais operações candidatas possuem sua funcionalidade fornecida por um serviço já implementado ou por um sistema legado. Os cenários de reúso que podem resultar dessa análise são mostrados na Tabela 2.1. Após a realização da análise de gap o modelo de serviços candidatos deve ser revisado, visto que algumas operações de serviços mencionados podem já ter sido implementadas;
Tabela 2.1: Cenários de reúso possíveis (FUGITA, 2009). Cenário Descrição
1 Funcionalidade fornecida por um serviço já implementado 2 Funcionalidade parcialmente fornecida por um serviço 3 Funcionalidade fornecida por um sistema legado
4 Funcionalidade parcialmente fornecida por um sistema legado 5 Funcionalidade não implementada
Análise de realização: define a estratégia de realização para cada um dos cenários de reúso identificados na análise de gap, como mostrado na Tabela 2.2. Custos, viabilidade técnica, riscos técnicos e de projeto, esforço e retorno do investimento são alguns dos aspectos que influenciam na decisão da estratégia de realização de um serviço candidato.
Tabela 2.2: Cenários e estratégias de realização de serviços (FUGITA, 2009). Cenário Estratégia de realização
1 Reúso do serviço, envolve apenas custo de utilização do serviço.
2 Alterar o serviço existente (risco inerente à alteração de um serviço) ou implementar uma lógica de mediação, possibilitando o reúso do serviço da forma como está implementado atualmente.
3 Criar um serviço encapsulador que acessa a funcionalidade através de APIs ou adaptadores; caso não existam tais mecanismos deve-se avaliar a viabilidade, custos e riscos envolvidos na criação de tais mecanismos.
4 Criar um serviço encapsulador que acessa apenas a parte da funcionalidade reusável ou realizar alterações no sistema legado de forma a fornecer toda a funcionalidade necessária.
5 Especificar e implementar o serviço, incorrendo em custos de desenvolvimento.
O analista de serviços, com apoio do gerente de projetos e do arquiteto corporativo, decide a viabilidade da realização dos serviços conforme as estratégias e cenários de reúso. Caso alguma estratégia de realização não seja viável, retorna-
se à atividade de modelagem de processos to-be para que em seguida as atividades de análise sejam executadas novamente.
A fase Projeto é constituída das seguintes atividades:
Especificação de serviços: utiliza como artefato de entrada o modelo de serviços candidatos para criar as interfaces dos serviços na qual constam as operações fornecidas por cada serviço e as mensagens de entrada e saída relacionadas a cada operação. Podem ser utilizados esquemas XSD para especificar o formato das mensagens e a linguagem WSDL para descrever as interfaces de serviço. Na Tabela 2.3 estão apresentadas as estratégias para criação das interfaces de serviço. A lógica envolvida na funcionalidade fornecida por uma operação é especificada por meio de diagramas de atividades da UML. As interações com outros serviços e sistemas legados são especificadas por meio de diagramas de sequência ou de colaboração. Políticas de serviços representam os requisitos não funcionais relacionados aos serviços e são especificadas por meio de SLAs. Serviços devem ser classificados de acordo com sua granularidade e nível de funcionalidade.
Tabela 2.3: Estratégias de criação de interfaces de serviço no MAPOS (FUGITA, 2009)
Estratégia Descrição Cenários
abrangidos
Top-down A interface do serviço é criada a partir do serviço
candidato. 5 e 2
Bottom-up Especifica as operações e mensagens baseadas nas características da funcionalidade existente 3
Meet-in-
the-middle A interface do serviço é parcialmente baseada na funcionalidade existente ao mesmo tempo em que se faz necessário utilizar uma abordagem top-down para especificar o que deve ser adaptado para que a funcionalidade da operação candidata seja completamente atendida.
4
Importar interface
Como a funcionalidade já existe e atende aos requisitos do serviço, importa-se a interface do serviço.
1
Verificação dos princípios: as especificações dos serviços são avaliadas quanto à conformidade com os princípios da orientação a serviços;
Revisão dos serviços: tem a finalidade de corrigir problemas identificados na atividade de verificação dos princípios. As mesmas considerações realizadas na atividade de especificação de serviços são aplicadas a essa atividade.
Orquestração de serviços: especifica-se a lógica de orquestração de serviços, utilizando a linguagem BPEL, que determina a implementação do processo de negócio e engloba as chamadas aos serviços através de suas interfaces, a manipulação de variáveis de processo, o gerenciamento de informações de estado, o tratamento de exceções e a compensação. A fase Construção, composta por duas atividades, é descrita brevemente por Fugita (2009), pois o método tem enfoque nas fases Análise e Projeto:
Implementação: conduzida por desenvolvedores que recebem as especificações de serviços e implementam os web services e outros componentes necessários.
Teste: conduzida por testadores que utilizam as especificações de serviço para elaborar os casos de teste que serão aplicados aos web services desenvolvidos.
Fugita (2009) afirma que a partir desta fase o ciclo tradicional de desenvolvimento de software orientado a objetos ou baseado em componentes pode ser utilizado.