Você está na página 1de 30

Modelagem de serviços com UML

         
     

comentários

     
     

Modelagem de serviços com UML

Este artigo discute como a UML pode apoiar a modelagem de serviços em projetos SOA, facilitando a comunicação no seu time nos processos de identificação, especificação e realização de serviços.

0

0

Curtir

0

   
 

(0)

       

(3)

           

Fique por dentro

Este artigo tratará do uso da linguagem UML para a modelagem de serviços em projetos SOA. O artigo descreve como um projetista pode se apoiar nos recursos visuais e facilidade de modelagem da UML para facilitar a comunicação no seu time nos processos de identificação,

Modelagem de serviços com UML

especificação e realização de serviços.

O artigo é útil para analistas, arquitetos, desenvolvedores que estejam trabalhando em projetos centrados em serviços com o uso de arquiteturas SOA para que estes realizem o processo de modelagem com maior maturidade. O artigo também é útil para estudantes de graduação e especializações que desejem conhecer o estilo arquitetural SOA e os seus benefícios sobre as abordagens tradicionais monolíticas.

A arquitetura orientada por serviços é um estilo arquitetural para o desenvolvimento de aplicações baseadas em pequenos ativos reusáveis, chamados de serviços.

Esta abordagem busca ofertar diversas vantagens sobre as abordagens monolíticas tradicionais, que entregam aplicações em grandes sistemas executáveis com grande acoplamento entre suas partes. Algumas destas vantagens incluem:

· entrega iterativa e incremental, que possibilita ciclos de projetos mais curtos e melhor retorno sobre os investimentos de TI;

· capacidade de operação autônoma de cada um dos serviços em ambiente de produção;

· maior facilidade para reuso e composição com outros serviços;

· abstração tecnológica, que reduz a dependência tecnológica entre clientes e fornecedores de serviços.

A Figura 1 apresenta um esquema deste modelo, onde cada um dos serviços, bem como dos clientes que os consomem, podem ser implementados em tecnologias distintas.

Modelagem de serviços com UML

Modelagem de serviços com UML Figura 1 . Visão Geral de uma Arquitetura Centrada em Serviços.

Figura 1. Visão Geral de uma Arquitetura Centrada em Serviços.

Para que times construam sistemas de software centrados em serviços, eles devem identificar e especificar serviços e realizar tarefas de modelagem. Este artigo descreve como a linguagem de modelagem UML pode apoiar desenvolvedores e projetistas nestas atividades.

O ciclo de vida de projetos SOA

Projetos SOA (Service Oriented Architecture) requerem, tipicamente, que os estágios da Figura 2 sejam executados.

que os estágios da Figura 2 sejam executados. Figura 2 . Ciclo de Vida de Projetos

Figura 2. Ciclo de Vida de Projetos SOA.

Modelagem de serviços com UML

A identificação de serviços tem por objetivo gerar uma lista de serviços candidatos a partir da análise de metas de negócio, processos de negócio e ativos já existentes na organização.

A especificação tem por objetivo selecionar, a partir da lista de serviços candidatos, os serviços que serão implementados e gerar uma especificação destes.

A especificação gera um contrato técnico que define as operações, mensagens e contratos de um

serviço e as políticas a ele aplicadas. Finalmente, a realização tem por objetivo implementar e testar um serviço em conformidade com os padrões arquiteturais estabelecidos na organização. Exemplos destes padrões incluem o WS-* ou RS-*.

Normalmente, a etapa de identificação gera um lote de serviços candidatos que são então organizados em pequenos projetos. Cada projeto entrega poucos serviços através da especificação e realização de forma iterativa e incremental.

O trabalho resultante da especificação é organizado em um ou mais modelos de serviço, que podem ser documentos puramente textuais ou documentos mais leves que façam uso de desenhos e diagramas.

Observamos da nossa experiência em projetos que documentos textuais e longos não são lidos e geram grande desperdício de esforço e tempo dos projetistas. A UML, neste sentido, se mostra uma ferramenta eficaz para reduzir o tempo de documentação, pois utiliza a linguagem visual para melhorar a comunicação entre analistas de negócio, arquitetos, desenvolvedores e analistas de teste.

A evolução da modelagem em sistemas de TI

A modelagem de sistemas SOA é uma evolução natural dos mecanismos de modelagem de sistemas

existentes na TI desde os anos 70. No modelo de maturidade OSIMM (Open Group Service Integration Maturity Model) os níveis de maturidade de modelagem são apresentados (ver Figura

3).

Modelagem de serviços com UML

Modelagem de serviços com UML Figura 3 . Níveis de maturidade de modelagem. Modelagem de serviços

Figura 3. Níveis de maturidade de modelagem.

Modelagem de serviços e a linguagem UML

Conhecer as características de um serviço nos ajuda a modelá-lo com maior precisão. Estas características incluem:

· contratos de serviços padronizados: refere-se à definição da interface, ou conjunto de funcionalidades, de um determinada serviço. Este contrato forma a API pública de um serviço para uso por seus clientes;

· serviços fracamente acoplados: refere-se ao projeto e implementação apropriados de serviços de forma a minimizar dependências do ambiente que o cerca como, por exemplo, tecnologias e outros detalhes de implementação;

· operação autônoma em ambiente de produção: refere-se a garantir que cada serviço possa operar em produção independentemente de outros serviços;

· granularidade em nível de capacidades de negócio: refere-se a garantir que a API de um serviço possua um tamanho apropriado e orientado aos módulos de negócio de uma organização;

· composibilidade: refere-se a permitir que serviços possam ser compostos para formar serviços de granularidade mais alta.

A UML, através de diagramas de classes, fornece instrumentos precisos para expressar contratos e avaliar quantitativamente o acoplamento entre serviços. Os diagramas de componentes e

Modelagem de serviços com UML

implantação da UML permitem expressar a alocação de serviços a componentes e expressar, portanto, a sua operação autônoma.

Finalmente, diagramas de casos de uso permitem expressar as funcionalidades de negócio e apoiar na correta identificação da granularidade destes serviços.

A linguagem UML se tornou um padrão na indústria para a modelagem de sistemas e possui um conjunto padronizado de diagramas para a modelagem de interações, estruturas e comportamentos.

Uma das características da UML no seu desenho original é o mecanismo de extensibilidade, que permite que a mesma seja usada em diversos contextos e estilos arquiteturais. A extensibilidade UML nos permite usá-la para especificar serviços com propriedade em projetos SOA.

Identificação de serviços e modelagem UML

Serviços podem ser identificados através de fontes diversas, sendo que as mais comuns são processos de negócio, modelos de domínio corporativos e ativos de software que rodem em ambiente de produção.

Exemplos destes elementos são mostrados nas Figuras 4 a 6, em notação UML, para um exemplo didático de um sistema acadêmico. Observe que um processo de negócio pode ser representado na UML através de um caso de uso estereotipado com o adjetivo <<Processo de Negócio>>.

Note também que conceitos podem ser representados na UML através de classes estereotipadas.

ser representados na UML através de classes estereotipadas. Figura 4. Exemplos de processos de negócio em

Figura 4. Exemplos de processos de negócio em um sistema acadêmico.

Exemplos de processos de negócio em um sistema acadêmico.

Modelagem de serviços com UML

Figura 5.Exemplos de conceitos de um domínio corporativo em um sistema acadêmico.

de um domínio corporativo em um sistema acadêmico. Figura 6 . Exemplo de ativo legado em

Figura 6. Exemplo de ativo legado em um contexto fictício de uma universidade para um software que foi identificado para reuso binário.

É recomendável que se obtenha (textualmente ou através da UML) uma lista dos processos de negócio, entidades do modelo de domínio corporativo e softwares legados. Estes insumos são fontes típicas para serviços SOA.

Processos de negócio devem ser examinados em termos de suas atividades detalhadas. Caso exista a representação BPMN do processo de negócio, as atividades estarão explícitas.

Caso contrário, talvez seja necessária uma investigação sobre os elementos constituintes dos principais processos de negócio. No exemplo ilustrado na Figura 4, uma eventual atividade que deve ser acionada para efetivação de uma matrícula é analisar se a guia de matrícula em curso foi paga.

Esta atividade primordial pode ser então descrita dentro de um serviço de gestão do pagamento da matrícula em um curso, conforme mostrado na Figura 7.

Modelagem de serviços com UML

Modelagem de serviços com UML Figura 7. Serviço de pagamento de matrícula em curso Uma outra

Figura 7. Serviço de pagamento de matrícula em curso

Uma outra fonte de serviços são objetos do domínio corporativo. Normalmente estes objetos nos levam a derivar serviços de manutenção de informações.

Em conformidade com a Figura 8, teríamos então os serviços de dados para Manter Matrícula e Manter Aluno.

os serviços de dados para Manter Matrícula e Manter Aluno. Figura 8. Serviços de dados para

Figura 8. Serviços de dados para manter entidades do domínio corporativo (Aluno e Matrícula).

Uma outra fonte comum para a identificação de serviços são ativos legados, ou seja, softwares já existentes que operem normalmente e que podem ser reusados binariamente.

Neste caso, uma boa prática é o uso de um padrão de desenho chamado fachada para a criação de um serviço de acesso ao código legado. O serviço de fachada consiste na criação de um contrato simplificado (API) que isole a complexidade de operação do software legado.

No exemplo do software COBOL já existente para a comunicação da universidade com o MEC, podemos fazer a modelagem do serviço conforme mostrado na Figura 9.

Modelagem de serviços com UML

Modelagem de serviços com UML Figura 9. Serviços de fachada para um componente de software já

Figura 9. Serviços de fachada para um componente de software já existente.

O projetista SOA pode escolher, para melhor comunicação e rastreabilidade, ligar os serviços às

suas fontes (processos de negócio, entidades corporativas ou componentes de software legados). Se o fizer, o desenho resultante e as relações são mostrados na Figura 10.

resultante e as relações são mostrados na Figura 10 . abrir imagem em nova janela Figura

Figura 10. Ligações entre serviços e suas fontes - processos de negócios, entidades ou componentes de software.

O modelo apresentado mostra que serviços possuem dependências de processos de negócios e

objetos de negócio. A mesma figura também mostra que um componente de software pode realizar um serviço SOA. O verbo realizar na UML (realizes) indica que um determinado objeto fornece uma implementação concreta para um contrato (interface de operações).

Dicas para as sessões de modelagem de serviços

A identificação de serviços talvez seja o estágio mais subjetivo do processo de construção de serviços. Algumas perguntas típicas que surgem neste estágio são:

Modelagem de serviços com UML

· Isto é realmente um serviço?

· O grão (tamanho) deste serviço está apropriado?

· Os serviços do meu inventário cobrem o escopo de negócio do nosso projeto?

· Como decompor serviços?

Algumas dicas podem ajudar o projetista neste estágio para que o modelo resultante seja construído apropriadamente.

Dica 1: Trabalho Colaborativo

O trabalho da modelagem deve ser realizado de forma colaborativa, com envolvimento de analistas

de negócio, projetistas e desenvolvedores. Embora isso possa parecer caro ou exagerado em um primeiro momento, o esforço fornece retornos tangíveis, minimiza retrabalho e evita erros mais graves em produção.

Dica 2: Modelagem para fins de comunicação

O principal objetivo de um esforço de modelagem é a comunicação de conceitos e não a

documentação. Uma sessão de modelagem SOA, portanto, deve permitir a troca de informações

sobre o domínio corporativo e os seus processos de negócio.

A documentação em texto e a formalização dos modelos UML em papel é, portanto, um efeito

colateral positivo do objetivo central que é o alinhamento de conceitos e entendimento do

problema de negócio.

Dica 3: Pequenas sessões de modelagem e maior frequência de modelagem

A modelagem não deve ser um esforço realizado uma única vez no projeto, com longas e cansativas

reuniões. Ao invés disso, ela deve ser realizada em pequenas sessões (não mais que 90 minutos), dispostas ao longo do ciclo de vida do projeto. Instrumentos simples como quadros brancos podem ser usados para facilitar a reunião e permitir que modelos UML sejam rapidamente desenhados e comunicados.

Dica 4: Análise de Valor

A lista de verificação a seguir pode ser usada para analisar se o fator de impacto de um serviço está

Modelagem de serviços com UML

apropriado:

· O serviço tem valor de negócio e claro reconhecimento pelos especialistas de negócio da organização? O valor de negócio pode ser quantificado na iniciativa privada como redução de custos, aumento de receita, produtividade e aumento da satisfação do cliente. Na iniciativa pública ele pode ser quantificado como acessibilidade à população de baixa renda, redução de filas em postos de atendimento ou redução da burocracia governamental.

· O serviço é reusável dentro e fora da organização?

· O serviço torna a sua TI mais eficiente e ágil?

· O serviço tem valor no estado atual e no estado futuro da organização?

Se um serviço atende a dois ou mais critérios da lista apresentada, é provável que esteja identificado corretamente.

Aplicação de tipos aos serviços

Na modelagem de serviços, pode ser útil comunicar o tipo associado a um determinado serviço. Embora a tipologia de serviços SOA não seja fixa, uma possível classificação é fornecida aqui para apoio aos projetistas SOA. Observe a Tabela 1.

Serviços de Dados

Tem por objetivo manter informações de uma entidade do

domínio corporativo. Também chamados de serviços CRUD,

normalmente possuem operações básicas para inclusão,

remoção, alteração e pesquisa de informações

Serviços de Regras de Negócio

Implementam uma coleção de regras de negócio e algoritmos

nucleares ao domínio sob modelagem

Serviços de Decisão

Categoria especial de serviços de regras de negócio, normalmente

implementam dezenas ou até mesmo centenas de regras de

negócio voláteis, organizadas como tabelas de decisão, fluxos de

regras ou linguagens específicas de domínio (DSL)

Serviços de Integração

São dedicados à modelagem da interoperabilidade do domínio sob

Modelagem de serviços com UML

 

modelagem com informações existentes em outras áreas ou em

outras empresas.

Serviços de Mediação

Cuidam da extração, enriquecimento, transformação e

roteamento de informações entre fontes de dados distintas,

normalmente com conversões de protocolos.

Serviços de Interação Humana

São responsáveis pela disponibilização de informações para seres

humanos em interfaces de portais. Tecnologias com Java Portlets

e Microsoft WebParts são normalmente usadas para consumir as

informações destes serviços

Serviços Compostos

Agregam contratos de dois ou mais serviços base e normalmente

são usados em empresas que possuem implementações SOA

maduras, onde existem tantos serviços disponíveis que eles

começam a ser usados para criar serviços de mais alto nível.

Tabela 1.Tipologia de serviços SOA

Um exemplo concreto é fornecido na Figura 11 para o contexto exemplo usado neste artigo (sistema acadêmico).

o contexto exemplo usado neste artigo (sistema acadêmico). Figura 11. Tipologia de serviços na UML, com

Figura 11. Tipologia de serviços na UML, com exemplos didáticos de tipos de serviços no contexto do exemplo de um sistema acadêmico.

Políticas de serviços

Modelagem de serviços com UML

Um aspecto chave de implementações SOA é que serviços devem ser governados. Políticas são instrumentos usados para fornecer governança e são derivadas dos requisitos de negócio e requisitos técnicos.

Além disso, políticas têm por objetivo orientar como serviços serão construídos e geridos em ambiente de produção. Os tipos mais comuns de políticas incluem:

· Políticas de negócio: Endereçam questões de negócio, acordos de níveis de serviço (SLA), critérios de desempenho, escalabilidade ou confiabilidade, níveis de aprovação ou mesmo limites de gastos como serviços externos pagos (ex. consulta de CEP dos correios).

· Políticas de conformidade: Tratam regulações de setores da indústria como, por exemplo, o TISS para a saúde suplementar brasileira ou o IFX para serviços financeiros.

· Conformidade a padrões tecnológicos: Endereçam padrões técnicos diversos tais como WS-I para interoperabilidade ou o WADL ou WSDL para a exposição de contratos de serviços.

· Políticas de segurança: Abordam padrões para garantir o transporte seguro de informações, auditoria, autenticação e autorização, entre outros.

· Políticas de processos: Abordam aspectos do ciclo de vida de um serviço, como por exemplo, quem pode publicar um serviço em produção, quem pode mudar a versão de um serviço ou como serviços antigos serão aposentados.

Governança de serviços através de políticas

Embora nem todo aspecto de governança possa ser automatizado, as políticas de QoS (negócio ou segurança) de um serviço podem ser descritas através da UML e eventualmente automatizadas. Considere como exemplo de um serviço (Self-Service Aluno) que precise operar com disponibilidade de 99% e que requeira transporte seguro para tráfego das suas informações.

Os dois atributos de qualidade (disponibilidade e transporte seguro) são definidos como políticas e então aplicadas sobre um determinado serviço. A Figura 12 mostra este caso, onde um determinado serviço possui dependências de duas políticas.

Quando um serviço depende de uma política, podemos também dizer que esta política é aplicada em tempo de execução sobre aquele serviço. Caso exista alguma falha no atendimento do atributo de qualidade, então o serviço tem o seu QoS comprometido.

Modelagem de serviços com UML

Modelagem de serviços com UML Figura 12. Aplicação de políticas de governança sobre um serviço. A

Figura 12. Aplicação de políticas de governança sobre um serviço.

A Tabela 2 fornece um catálogo inicial de políticas comuns em projetos SOA. Este catálogo pode ser estendido e personalizado conforme a necessidade particular de um projeto ou empresa.

Política

Descrição

Alta

O

serviço deve operar com alta disponibilidade, definida em base diária,

Disponibilidade

mensal ou anual. Se medido em base diária, o serviço não pode ficar mais

(99%)

que 14 minutos fora do ar, somando-se as interrupções no período.

Se medido em base mensal, não pode ficar mais que sete horas fora do ar

em cada mês. Se medido em base anual, não pode ficar mais que quatro

dias fora do ar no ano.

Auditoria simples

As operações de um serviço que promovem modificação em dados devem ser

auditadas.

Auditoria ampla

Todas as operações (inclusive de leitura) de um serviço devem ser auditadas.

(não-repúdio)

Autenticação

A

invocação a um serviço deve ser validada através das credenciais do

solicitante.

Modelagem de serviços com UML

Autorização

As operações a um serviço devem ser validadas através uma lista de controle

de acesso (ACL), para avaliar a permissão apropriada do solicitante.

Banda de

O

volume de mensagens servidas por unidade de tempo por serviço deve ser

passagem alta

de pelo menos 1.000.000 de mensagens por dia.

Endereçamento

O

endereço (URL) do serviço deve ser virtualizado para a redução da

Virtual

dependência entre o fornecedor e o consumidor de serviços.

Tempo de

O

tempo médio (estatisticamente) das operações de um serviço não deve ser

Resposta

maior que 0.1 segundos.

Instantâneo

Tempo de

O

tempo médio das operações de um serviço não deve ser maior que um

Resposta Rápido

segundo.

Tempo de

O

tempo médio das operações de um serviço não deve ser maior que seis

Resposta Bom

segundos.

Transporte seguro

As mensagens dos parâmetros e resposta das operações do serviço devem

ser enviadas com confidencialidade e integridade.

Tabela 2. Catálogo de Políticas SOA.

Definição de dependências entre serviços

Serviços podem possuir dependências de operações de outros serviços e estas relações também podem ser comunicadas pelos projetistas para o seu time.

Estas dependências permitem que serviços de mais alto nível estejam baseados em serviços de mais baixo nível, façam reuso de operações já criadas anteriormente e também promovam a reusabilidade em um nível mais elevado.

Como exemplo, consideremos um serviço de efetivação de matrícula semestral de aluno que use as

Modelagem de serviços com UML

funções de análise de pré-requisitos de matrícula em disciplina e também a consulta sobre a adimplência deste aluno. Observe o resultado deste mapeamento na Figura 13.

aluno. Observe o resultado deste mapeamento na Figura 13 . Figura 13. Serviços podem estabelecer dependências

Figura 13. Serviços podem estabelecer dependências com outros serviços.

Especificação de contratos de operações e dados de serviços

Uma vez que serviços sejam identificados, tenham suas dependências definidas e políticas aplicadas, eles podem ser especificados.

A especificação define o contrato de operações, onde cada operação recebe um ou mais objetos e

retorna um objeto ou uma falha (exceção). Contratos devem exigir um forte cuidado pelo projetista e talvez sejam o ponto mais importante para a construção de serviços reusáveis.

A especificação de um bom contrato (ou API) deve obedecer às seguintes propriedades:

· ser de fácil aprendizado;

· ser fácil de usar, mesmo sem documentação;

· ser difícil de ser mal utilizada;

· fácil de ler e ser mantida;

· fácil para estender.

Bons princípios para a especificação de contratos incluem:

Modelagem de serviços com UML

· Ter atenção aos nomes dos serviços, operações e mensagens. Nomes devem ser autoexplicativos e orientados pelos conceitos de negócio;

· Reduzir o tamanho das funcionalidades expostas. A API de um serviço deve ter o menor tamanho possível para atender aos requisitos de negócio;

· Considerar as implicações de desempenho do desenho dos contratos;

· Reduzir o esforço dos clientes no uso da API, com a redução de códigos clientes que podem ser trazidos para dentro da implementação dos serviços.

Consideremos como exemplo o serviço de Manter Alunos, que lida com as operações CRUD sobre um determinado aluno.

A Figura 14 exibe a especificação de um serviço, com o seu contrato de operações e os tipos de dados referenciados como parâmetros ou com falhas/exceções.

referenciados como parâmetros ou com falhas/exceções. abrir imagem em nova janela Figura 14. Especificação de
ou com falhas/exceções. abrir imagem em nova janela Figura 14. Especificação de um serviço, com o

Figura 14. Especificação de um serviço, com o contrato de operações e os contratos de dados.

Embora esta figura possa lembrar um diagrama de classes para o leitor usualmente acostumado com a UML, é fundamental notar que a implementação do código não está no serviço.

Um serviço é apenas um contrato, agnóstico de tecnologia. O serviço irá invocar operações de

Modelagem de serviços com UML

classes, acessar dados de tabelas e manipular outras primitivas na linguagem alvo escolhida para sua implementação.

Aplicação de padrões SOA para contratos de serviços

Hoje se há conhecimento acerca de um conjunto de cinco padrões de projeto que podem promover uma melhor modelagem de contratos:

· Padrão: Contratos Concorrentes

o Problema: Um contrato de um serviço pode não ser apropriado ou aplicável a todos os seus consumidores. Um contrato é definido como um conjunto de operações.

o Solução: Múltiplos contratos podem ser criados para um único serviço. Uma classe pode expor múltiplos contratos através da implementação e exposição de interfaces <<Interface>>.

·

Padrão: Centralização de Contratos

o

Problema: Programas consumidores podem ser desenhados para acessar os recursos de um

serviço através de diferentes pontos de entrada, resultando em diferentes formas de dependências de implementação que inibem a evolução do serviço.

o Solução: Acesso à lógica de um serviço é limitado ao seu contrato, o que força os consumidores a evitar dependências de implementação.

· Padrão: Contratos Não Normalizados

o Problema: Serviços com contratos estritamente normalizados podem impor demandas funcionais e de performance desnecessárias para alguns programas consumidores.

o Solução: Contratos podem incluir uma certa medida de desnormalização, expressando um contrato de forma redundante para diferentes tipos de programas consumidores.

· Padrão: Contratos Desacoplados

o Problema: Para que um serviço seja um recurso corporativo, ele deve ser equipado com um contrato técnico que existe independentemente da sua implementação.

Modelagem de serviços com UML

o Solução: Um contrato é fisicamente desacoplado da sua implementação.

· Padrão: Abstração das Validações

o Problema: Contratos que contém restrições detalhadas de validações são invalidados mais facilmente quando as regras destas restrições mudam.

o Solução: Lógica e regras de validações granulares podem ser abstraídas do contrato do serviço, o que reduz a granularidade de restrições e potencialmente aumenta a longevidade do contrato.

Análise da granularidade de serviços

A identificação dos serviços candidatos é um processo que consiste no estudo das entidades

nucleares, processos de negócio e ativos organizacionais. O resultado é uma lista de serviços que tipicamente tem dois tipos de grãos:

· Serviços de grão fino: Possuem um único contrato e poucas operações de negócio (< 5).

· Serviços de grão grosso: Normalmente possuem mais de um contrato e muitas operações de negócio.

A análise da granularidade é um processo que se segue à identificação de serviços e que pode levar à reorganização do seu portfólio. Embora não existam construtos específicos da UML para este processo, o resultado final é um modelo UML refatorado. Os tipos mais comuns de operações que modificam a granularidade dos serviços são:

· Unificação: Esta operação tem por objetivo unificar dois serviços de grão fino em um serviço de grão grosso que forneça, isoladamente, valor mais claro de negócio. A recomendação para o uso deste conceito é a análise de serviços de grão fino que não fornecem valor de negócio adequado e, portanto, não devem existir no portfólio de serviços;

· Decomposição: Esta operação tem por objetivo quebrar serviços identificados de grão grosso em dois ou mais serviços menores.

A recomendação para o uso deste conceito é a análise de fatorações do serviço maior que podem

entregar, isoladamente, valor de negócio. Em outros cenários, o condutor de reusabilidade pode levar a serviços de grão mais fino;

· Interseção: Esta abordagem pode ser aplicada, em serviços de grão grosso, para extrair um conjunto de operações comuns e derivar um terceiro serviço que capture as operações comuns.

Este conceito, entretanto, não deve ser aplicado com muita frequência e também não deve ser

Modelagem de serviços com UML

aplicado em serviços de grão mais fino, pois pode levar a um alto custo de gerenciamento dos serviços ou mesmo problemas de desempenho em ambientes de produção;

· Subconjunto: Esta operação agrega dois ou mais serviços em um serviço candidato já existente. Diferentemente da operação de unificação, que cria um novo serviço, esta operação apenas introduz um novo subconjunto de operações em um serviço já existente no portfólio. O uso excessivo desta operação como a unificação, pode levar a uma baixa reusabilidade;

· Subtração: A subtração de serviços remove um fragmento do contrato original e, portanto, altera a funcionalidade original do serviço. Ela deve ser usada quando o contrato possuir operações excessivas que não agregam funcionalidade de negócio e remetem mais a um desenho OO do que um desenho centrado em serviços.

Decisões de implementação sobre serviços

Serviços SOA devem ser implementados em alguma tecnologia e ter o seu contrato estabelecido em um padrão.

O projetista, no seu desenho SOA, pode indicar algumas decisões tecnológicas e o padrão a ser usado para externalizar o contrato de seus serviços. Os padrões mais comuns para a implementação de serviços são apresentados na Tabela 3.

WS-*

Baseados no protocolo de envelopamento SOAP, algum protocolo de

transporte (ex. HTTP, TCP ou SMTP), contratos de serviços WSDL e

mensagens baseadas em XML/XSD. Os WS-* têm como grande vantagem

possuir mais de 30 especificações para aspectos diversos de governança tais

como transações atômicas (WS-AT), segurança de mensagens (WS-Security),

interoperabilidade de serviços (WS-I) e políticas de tempo de execução (WS-

Policy).

RS-* (REST)

Baseados no protocolo HTTP, contratos de serviços WADL e mensagens em

XML ou JSON. Estes padrões têm como grande vantagem a simplicidade e

facilidade para aprendizado.

SCA (Service

Modelo de componentização de serviços que promove abstração da tecnologia

Component

de implementação e protocolos de transporte. Largamente usado em

Architecture)

implementações SOA IBM e Oracle.

Modelagem de serviços com UML

WCF (Windows

Modelo de componentização da Microsoft para a exposição de serviços, com

Communication

abstração da tecnologia de implementação e também de protocolos de

Foundation)

transporte.

JBI (Java Business

Modelo de componentização definida pela JCP (JSR 312) para a exposição de

Integration)

serviços implementados em plataforma Java.

Tabela 3.Padrões mais comuns para a implementação de serviços

A Figura 15 apresenta decisões de realização com os padrões WS-*.

apresenta decisões de realização com os padrões WS-*. abrir imagem em nova janela Figura 15. Decisões
com os padrões WS-*. abrir imagem em nova janela Figura 15. Decisões de realização de serviços

Figura 15. Decisões de realização de serviços como WSDL, XSD e políticas como WS-Policy.

Alocação de serviços a componentes e nodos

Serviços, embora agnósticos de tecnologia pelo padrão de desenho interface, devem ser implementados em alguma tecnologia alvo. Portanto, um serviço é realizado através de componentes de software, que são normalmente empacotados em tecnologias como LIBs, DLLs, Assemblies, JARs ou WARs. Um componente de software que reside em um ambiente físico representa uma máquina real ou máquina virtual em um ambiente de nuvens.

Na UML, temos primitivas básicas para representar componentes (retângulos) e nodos (cubos) em

Modelagem de serviços com UML

uma visualização chamada de diagrama de implantação. Através de diagramas de implantação podemos mostrar onde serviços são efetivamente implementados e implantados, descrevendo a topologia física de uma arquitetura baseada em serviços. Observe a Figura 16. Neste diagrama indicamos que um componente (software) reside em um nodo (hardware) e realiza um ou mais serviços SOA.

em um nodo (hardware) e realiza um ou mais serviços SOA. Figura 16. Fragmento que mostra

Figura 16. Fragmento que mostra a alocação de serviços a componentes e nodos.

Projetistas devem trabalhar a visualização de implantação SOA em conjunto com o time de infraestrutura para atender a políticas de natureza física tais como a volumetria, performance, escalabilidade e recuperação de falhas.

Modelagem de serviços de infraestrutura

Finalmente, o projetista SOA pode representar uma camada mais nuclear de serviços que tem por papel suportar os serviços de nível mais alto. Normalmente, estes serviços não têm ligação direta com o negócio, embora tenham papel central na manutenção de atributos de qualidade ou na facilitação da orquestração dos serviços.

Estes serviços podem ser classificados nos seguintes tipos:

Modelagem de serviços com UML

· Barramento de Serviços: É um tipo de serviço de middleware que promove um conjunto variado de funcionalidades para gerir mensagens, controle do tráfego e abstração de protocolos e localizações.

São normalmente implementados por produtos muito complexos e em implementações SOA de

grande porte (ex. ESBs da IBM, Oracle ou TIBCO), embora estejamos observando barramentos leves como o Apache Camel ou o Microsoft WCF começarem a ser usados em implementações SOA

leves;

· Intermediários (Proxies): São interceptadores de mensagens que promovem funções mais elementares de transmissão, roteamento ou manipulação de dados. Um uso comum para estes serviços é para a implementação de políticas de transporte seguro ou auditoria;

· Motores de regras: São middlewares dedicados a execução de regras de negócio descritas em linguagem de alto nível (DSLs) em serviços de decisão. São chamados no mercado como BRMS (Business Rule Management Suites);

· Motores de fluxos de trabalho: São middlewares dedicados à orquestração de outros serviços para

a execução de fluxos de trabalho ou mesmo processos de negócio. São chamados no mercado como BPMS (Business Process Management Suites);

· Conectores de Adaptação: São peças dedicadas à ligação de um serviço a um recurso nativo. Exemplos envolvem conectores JDBC ou ADO.NET a banco de dados ou mesmo conectores ao SAP ECC ou a CICS COBOL;

· Conectores de Roteamento: São peças dedicadas ao roteamento de mensagens entre serviços e que promovem conectividade entre consumidores e fornecedores de serviços;

· Adaptadores de Transformadores: Peças dedicadas ao enriquecimento de mensagens através da tradução do seu formato entre consumidores e fornecedores de mensagens.

Os diagramas de componentes e implantação podem apoiar o projetista a mostrar estes elementos da infraestrutura SOA e comunicar como arquiteturas físicas SOA serão implementadas em empresas.

Os retornos da modelagem de serviços

A modelagem de serviços aqui proposta faz uso de diagramas de caso de uso, classes, componentes

e implantação. Embora seja uma abordagem mais leve do que modelos formais como o IBM UML Profile for Software Services e a linguagem Open Group Archimate, ela deve ser usada

Modelagem de serviços com UML

moderadamente.

Se o esforço da modelagem não for dimensionado apropriadamente, ela pode ser muito demorada e reduzir o seu benefício em projetos de software.

A Figura 17 fornece um esquema que relaciona o valor da modelagem e o tempo nela investido (o

eixo X representa o esforço em horas para a modelagem e o eixo Y o retorno do esforço de modelagem.).

Embora este valor não possa ser quantificado em esforço ou prazo, ele deve ser analisado conforme

a realidade de cada organização e os fatores de cada projeto (tamanho, necessidades contratuais e distribuição física do time).

necessidades contratuais e distribuição física do time). Figura 17. Retornos Decrescentes da Modelagem. Algumas

Figura 17. Retornos Decrescentes da Modelagem.

Algumas abordagens que podem apoiar na racionalização do esforço de modelagem incluem:

· busca pela visão em amplitude nos primeiros esforços de modelagem;

· tratamento diferenciado de acordo com o valor e complexidade de cada serviço. Serviços mais críticos requerem um maior investimento em modelagem e, então, maior profundidade de análise;

· padronização da modelagem para serviços similares.

A Tabela 4 apresenta um resumo dos principais passos descritos neste artigo e que resultam em

Modelagem de serviços com UML

uma modelagem SOA centrada em UML consistente e robusta.

 

Passo

Produto UML

01.

Identificação de Conceitos

Diagrama de classes com nomes, onde cada nome

Corporativos

é um elemento do modelo de domínio

corporativo.

02.

Identificação de Processos

Diagrama de casos de uso de negócio. Cada caso

de Negócio

de uso de negócio corresponde a um processo de

negócio.

03.

Identificação de Ativos

Diagrama de componentes onde cada componente

Existentes

corresponde a um ativo organizacional

potencialmente reusável.

04. Identificação de Serviços

Diagrama de classes (sem atributos e

comportamentos) com uma classe para cada

serviço.

05. Aplicação de Tipos aos

Diagrama de classes com estereótipos.

Serviços

06.

Governança de Serviços

Diagrama de classes para serviços e classes para

Através de Políticas

políticas.

07.

Definição de Dependência

Diagrama de classes com relações de

entre Serviços

dependências entre serviços.

08.

Especificação de Contratos

Diagrama de classes com serviços onde os

de Operações e Dados de

métodos da classe descrevem o contrato do

Serviços

serviço. Também é gerado o diagrama de classes

para representar as estruturas de dados que são

Modelagem de serviços com UML

 

parâmetros e retornos das operações.

09.

Análise da Granularidade

Diagrama de classes refatorado com métodos ou

dos Serviços

classes movimentadas através de operações

lógicas diversas.

10.

Alocação de Serviços a

Diagrama de classes com componentes e nodos

Componentes e Nodos

que mostrem o local físico onde os serviços irão

operar.

11.

Modelagem de Serviços de

Diagrama de componentes com serviços de

Infraestrutura

infraestrutura que cuidam de funções mais

fundamentais para atender uma arquitetura SOA.

Tabela 4. Passos da modelagem UML para serviços

Os passos 1 a 4 são normalmente realizados como um esforço anterior aos projetos SOA (pré-game em métodos ágeis). Os passos 5 a 11 são realizados repetidamente em pequenos projetos, que entregam um ou mais serviços em ambiente de produção, com uma rápida revisão e extensão dos produtos gerados nos passos 1 a 4.

Outros diagramas da UML podem ser usados conforme necessário para agregar valor na comunicação. Em cenários complexos de mediação, por exemplo, o uso de diagrama de sequência ou diagrama de interação pode comunicar a sequência de mensagens desta mediação.

Em casos muito complexos de agregação de serviços ou de alocação de serviços a nodos e componentes, o diagrama de estruturas compostas pode comunicar a estruturação recursiva de contratos.

A abordagem centrada em serviços introduz uma forma alternativa de construção de sistemas, baseada na implantação de pequenos serviços reusáveis e agnósticos de tecnologia. Se usada corretamente, pode promover benefícios concretos para as organizações, como a sobrevida de ativos de TI, redução de dependências tecnológicas e aumento da eficiência.

Os princípios da modelagem UML aqui apresentados podem ser aplicados em pequenos projetos, com duas ou três pessoas, com uso de quadros brancos ou mesmo em grandes projetos com dezenas de pessoas, com o uso de ferramentas formais de modelagem.

Modelagem de serviços com UML

Para os iniciantes em SOA, é recomendável o uso das técnicas de modelagem para a identificação de serviços para a geração de um inventário mais apropriado. Para aqueles que já experimentaram SOA, são recomendáveis técnicas de modelagem de contratos de operações de serviços.

Para aqueles times que querem ir além, recomenda-se a modelagem de políticas para introduzir governança sobre seus serviços.

Referências

[1] Dias Jr, J. J. L., Oliveira, J., & Meira, S. R. L. (2012). Pontos Chaves para Adoção de Uma Arquitetura Orientada a Serviços: Uma Análise Comparativa de Modelos de Maturidade SOA da Indústria. In VII Simpósio Brasileiro de Sistemas de Informação.

[2] Erl, T. (2009). SOA Design Patterns (p. 800).

[3] Group, T. O. (2009). Service Integration Maturity Model.

https://www.opengroup.org/projects/osimm/uploads/40/17990/OSIMM_v0.3a.pdf

[4] Johnston, S. (2005). UML profile for software services. IBM DeveloperWorks.

http://www-128.ibm.com/developerworks/rational/library/05/419_soa/

[5] Jonkers, H., van den Berg, H., Iacob, M. E., & Quartel, D. (2010). ArchiMate Extension for Modeling TOGAF’s Implementation and Migration phases. Reading, Berkshire: Whitepaper, The Open Group.

phases. Reading, Berkshire: Whitepaper, The Open Group. Marco Aurélio De Souza Mendes É consultor independente de

É consultor independente de Arquitetura de Software e Engenharia de Software com mais de 16 anos de experiência em projetos de TI. É também professor de pós-graduação dos cursos de Estratégias de Arquitetura de Sistemas do IGTI e [ ]

Modelagem de serviços com UML

Modelagem de serviços com UML

Não há comentários

Publicidade

com UML Não há comentários Meus comentarios Publicidade Serviços Inclua um comentário Adicionar aos

Mais posts

Artigo

Modelagem de serviços com UML

|

|

|

|

             
 

Curtir

           

66.554 pessoas curtiram DevMedia.

       
         

Hospedagem web por Porta 80 Web Hosting