Modelagem de Serviços Com UML

Modelagem de servios com UML

http://www.devmedia.com.br/modelagem-de-servicos-com-uml/32496[28/05/2015 20:09:56]

Gostei (3)

(0)

comentrios post favorito (6)

Engenharia de Software 75 - ndice


Este artigo discute como a UML pode apoiar a modelagem de servios em projetos SOA, facilitando a comunicao no seu time nos processos de identificao, especificao e realizao de servios.

Fique por dentro

Este artigo tratar do uso da linguagem UML para a modelagem de servios em projetos SOA. O

artigo descreve como um projetista pode se apoiar nos recursos visuais e facilidade de

modelagem da UML para facilitar a comunicao no seu time nos processos de identificao,

0 0Curtir0

DEVMEDIA



especificao e realizao de servios.

O artigo til para analistas, arquitetos, desenvolvedores que estejam trabalhando em projetos

centrados em servios com o uso de arquiteturas SOA para que estes realizem o processo de

modelagem com maior maturidade. O artigo tambm til para estudantes de graduao e

especializaes que desejem conhecer o estilo arquitetural SOA e os seus benefcios sobre as

abordagens tradicionais monolticas.

A arquitetura orientada por servios um estilo arquitetural para o desenvolvimento de aplicaes

baseadas em pequenos ativos reusveis, chamados de servios.

Esta abordagem busca ofertar diversas vantagens sobre as abordagens monolticas tradicionais, que

entregam aplicaes em grandes sistemas executveis 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 operao autnoma de cada um dos servios em ambiente de produo;

maior facilidade para reuso e composio com outros servios;

abstrao tecnolgica, que reduz a dependncia tecnolgica entre clientes e fornecedores de

servios.

A Figura 1 apresenta um esquema deste modelo, onde cada um dos servios, bem como dos

clientes que os consomem, podem ser implementados em tecnologias distintas.



Figura 1. Viso Geral de uma Arquitetura Centrada em Servios.

Para que times construam sistemas de software centrados em servios, eles devem identificar e

especificar servios 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 SOAProjetos SOA (Service Oriented Architecture) requerem, tipicamente, que os estgios da Figura 2

sejam executados.

Figura 2. Ciclo de Vida de Projetos SOA.



A identificao de servios tem por objetivo gerar uma lista de servios candidatos a partir da

anlise de metas de negcio, processos de negcio e ativos j existentes na organizao.

A especificao tem por objetivo selecionar, a partir da lista de servios candidatos, os servios que

sero implementados e gerar uma especificao destes.

A especificao gera um contrato tcnico que define as operaes, mensagens e contratos de um

servio e as polticas a ele aplicadas. Finalmente, a realizao tem por objetivo implementar e

testar um servio em conformidade com os padres arquiteturais estabelecidos na organizao.

Exemplos destes padres incluem o WS-* ou RS-*.

Normalmente, a etapa de identificao gera um lote de servios candidatos que so ento

organizados em pequenos projetos. Cada projeto entrega poucos servios atravs da especificao

e realizao de forma iterativa e incremental.

O trabalho resultante da especificao organizado em um ou mais modelos de servio, que podem

ser documentos puramente textuais ou documentos mais leves que faam uso de desenhos e

diagramas.

Observamos da nossa experincia em projetos que documentos textuais e longos no so lidos e

geram grande desperdcio de esforo e tempo dos projetistas. A UML, neste sentido, se mostra

uma ferramenta eficaz para reduzir o tempo de documentao, pois utiliza a linguagem visual para

melhorar a comunicao entre analistas de negcio, arquitetos, desenvolvedores e analistas de

teste.

A evoluo da modelagem em sistemas de TIA modelagem de sistemas SOA uma evoluo 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 nveis de maturidade de modelagem so apresentados (ver Figura

3).



Figura 3. Nveis de maturidade de modelagem.

Modelagem de servios e a linguagem UMLConhecer as caractersticas de um servio nos ajuda a model-lo com maior preciso. Estas

caractersticas incluem:

contratos de servios padronizados: refere-se definio da interface, ou conjunto de

funcionalidades, de um determinada servio. Este contrato forma a API pblica de um servio para

uso por seus clientes;

servios fracamente acoplados: refere-se ao projeto e implementao apropriados de servios de

forma a minimizar dependncias do ambiente que o cerca como, por exemplo, tecnologias e outros

detalhes de implementao;

operao autnoma em ambiente de produo: refere-se a garantir que cada servio possa operar

em produo independentemente de outros servios;

granularidade em nvel de capacidades de negcio: refere-se a garantir que a API de um servio

possua um tamanho apropriado e orientado aos mdulos de negcio de uma organizao;

composibilidade: refere-se a permitir que servios possam ser compostos para formar servios de

granularidade mais alta.

A UML, atravs de diagramas de classes, fornece instrumentos precisos para expressar contratos e

avaliar quantitativamente o acoplamento entre servios. Os diagramas de componentes e



implantao da UML permitem expressar a alocao de servios a componentes e expressar,

portanto, a sua operao autnoma.

Finalmente, diagramas de casos de uso permitem expressar as funcionalidades de negcio e apoiar

na correta identificao da granularidade destes servios.

A linguagem UML se tornou um padro na indstria para a modelagem de sistemas e possui um

conjunto padronizado de diagramas para a modelagem de interaes, estruturas e

comportamentos.

Uma das caractersticas 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 servios com propriedade em projetos SOA.

Identificao de servios e modelagem UMLServios podem ser identificados atravs de fontes diversas, sendo que as mais comuns so

processos de negcio, modelos de domnio corporativos e ativos de software que rodem em

ambiente de produo.

Exemplos destes elementos so mostrados nas Figuras 4 a 6, em notao UML, para um exemplo

didtico de um sistema acadmico. Observe que um processo de negcio pode ser representado na

UML atravs de um caso de uso estereotipado com o adjetivo .

Note tambm que conceitos podem ser representados na UML atravs de classes estereotipadas.

Figura 4. Exemplos de processos de negcio em um sistema acadmico.



Figura 5.Exemplos de conceitos de um domnio corporativo em um sistema acadmico.

Figura 6. Exemplo de ativo legado em um contexto fictcio de uma universidade para um software

que foi identificado para reuso binrio.

recomendvel que se obtenha (textualmente ou atravs da UML) uma lista dos processos de

negcio, entidades do modelo de domnio corporativo e softwares legados. Estes insumos so

fontes tpicas para servios SOA.

Processos de negcio devem ser examinados em termos de suas atividades detalhadas. Caso exista

a representao BPMN do processo de negcio, as atividades estaro explcitas.

Caso contrrio, talvez seja necessria uma investigao sobre os elementos constituintes dos

principais processos de negcio. No exemplo ilustrado na Figura 4, uma eventual atividade que

deve ser acionada para efetivao de uma matrcula analisar se a guia de matrcula em curso foi

paga.

Esta atividade primordial pode ser ento descrita dentro de um servio de gesto do pagamento da

matrcula em um curso, conforme mostrado na Figura 7.



Figura 7. Servio de pagamento de matrcula em curso

Uma outra fonte de servios so objetos do domnio corporativo. Normalmente estes objetos nos

levam a derivar servios de manuteno de informaes.

Em conformidade com a Figura 8, teramos ento os servios de dados para Manter Matrcula e

Manter Aluno.

Figura 8. Servios de dados para manter entidades do domnio corporativo (Aluno e Matrcula).

Uma outra fonte comum para a identificao de servios so ativos legados, ou seja, softwares j

existentes que operem normalmente e que podem ser reusados binariamente.

Neste caso, uma boa prtica o uso de um padro de desenho chamado fachada para a criao de

um servio de acesso ao cdigo legado. O servio de fachada consiste na criao de um contrato

simplificado (API) que isole a complexidade de operao do software legado.

No exemplo do software COBOL j existente para a comunicao da universidade com o MEC,

podemos fazer a modelagem do servio conforme mostrado na Figura 9.



Figura 9. Servios de fachada para um componente de software j existente.

O projetista SOA pode escolher, para melhor comunicao e rastreabilidade, ligar os servios s

suas fontes (processos de negcio, entidades corporativas ou componentes de software legados).

Se o fizer, o desenho resultante e as relaes so mostrados na Figura 10.

abrir imagem em nova janela

Figura 10. Ligaes entre servios e suas fontes - processos de negcios, entidades ou

componentes de software.

O modelo apresentado mostra que servios possuem dependncias de processos de negcios e

objetos de negcio. A mesma figura tambm mostra que um componente de software pode realizar

um servio SOA. O verbo realizar na UML (realizes) indica que um determinado objeto fornece uma

implementao concreta para um contrato (interface de operaes).

Dicas para as sesses de modelagem de serviosA identificao de servios talvez seja o estgio mais subjetivo do processo de construo de

servios. Algumas perguntas tpicas que surgem neste estgio so:



Isto realmente um servio?

O gro (tamanho) deste servio est apropriado?

Os servios do meu inventrio cobrem o escopo de negcio do nosso projeto?

Como decompor servios?

Algumas dicas podem ajudar o projetista neste estgio para que o modelo resultante seja

construdo apropriadamente.

Dica 1: Trabalho ColaborativoO trabalho da modelagem deve ser realizado de forma colaborativa, com envolvimento de analistas

de negcio, projetistas e desenvolvedores. Embora isso possa parecer caro ou exagerado em um

primeiro momento, o esforo fornece retornos tangveis, minimiza retrabalho e evita erros mais

graves em produo.

Dica 2: Modelagem para fins de comunicaoO principal objetivo de um esforo de modelagem a comunicao de conceitos e no a

documentao. Uma sesso de modelagem SOA, portanto, deve permitir a troca de informaes

sobre o domnio corporativo e os seus processos de negcio.

A documentao em texto e a formalizao dos modelos UML em papel , portanto, um efeito

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

problema de negcio.

Dica 3: Pequenas sesses de modelagem e maior frequncia de modelagemA modelagem no deve ser um esforo realizado uma nica vez no projeto, com longas e cansativas

reunies. Ao invs disso, ela deve ser realizada em pequenas sesses (no mais que 90 minutos),

dispostas ao longo do ciclo de vida do projeto. Instrumentos simples como quadros brancos podem

ser usados para facilitar a reunio e permitir que modelos UML sejam rapidamente desenhados e

comunicados.

Dica 4: Anlise de ValorA lista de verificao a seguir pode ser usada para analisar se o fator de impacto de um servio est



apropriado:

O servio tem valor de negcio e claro reconhecimento pelos especialistas de negcio da

organizao? O valor de negcio pode ser quantificado na iniciativa privada como reduo de

custos, aumento de receita, produtividade e aumento da satisfao do cliente. Na iniciativa pblica

ele pode ser quantificado como acessibilidade populao de baixa renda, reduo de filas em

postos de atendimento ou reduo da burocracia governamental.

O servio reusvel dentro e fora da organizao?

O servio torna a sua TI mais eficiente e gil?

O servio tem valor no estado atual e no estado futuro da organizao?

Se um servio atende a dois ou mais critrios da lista apresentada, provvel que esteja

identificado corretamente.

Aplicao de tipos aos serviosNa modelagem de servios, pode ser til comunicar o tipo associado a um determinado servio.

Embora a tipologia de servios SOA no seja fixa, uma possvel classificao fornecida aqui para

apoio aos projetistas SOA. Observe a Tabela 1.

Servios de Dados Tem por objetivo manter informaes de uma entidade do

domnio corporativo. Tambm chamados de servios CRUD,

normalmente possuem operaes bsicas para incluso,

remoo, alterao e pesquisa de informaes

Servios de Regras de Negcio Implementam uma coleo de regras de negcio e algoritmos

nucleares ao domnio sob modelagem

Servios de Deciso Categoria especial de servios de regras de negcio, normalmente

implementam dezenas ou at mesmo centenas de regras de

negcio volteis, organizadas como tabelas de deciso, fluxos de

regras ou linguagens especficas de domnio (DSL)

Servios de Integrao So dedicados modelagem da interoperabilidade do domnio sob



modelagem com informaes existentes em outras reas ou em

outras empresas.

Servios de Mediao Cuidam da extrao, enriquecimento, transformao e

roteamento de informaes entre fontes de dados distintas,

normalmente com converses de protocolos.

Servios de Interao Humana So responsveis pela disponibilizao de informaes para seres

humanos em interfaces de portais. Tecnologias com Java Portlets

e Microsoft WebParts so normalmente usadas para consumir as

informaes destes servios

Servios Compostos Agregam contratos de dois ou mais servios base e normalmente

so usados em empresas que possuem implementaes SOA

maduras, onde existem tantos servios disponveis que eles

comeam a ser usados para criar servios de mais alto nvel.

Tabela 1.Tipologia de servios SOA

Um exemplo concreto fornecido na Figura 11 para o contexto exemplo usado neste artigo

(sistema acadmico).

Figura 11. Tipologia de servios na UML, com exemplos didticos de tipos de servios no contexto

do exemplo de um sistema acadmico.

Polticas de servios



Um aspecto chave de implementaes SOA que servios devem ser governados. Polticas so

instrumentos usados para fornecer governana e so derivadas dos requisitos de negcio e

requisitos tcnicos.

Alm disso, polticas tm por objetivo orientar como servios sero construdos e geridos em

ambiente de produo. Os tipos mais comuns de polticas incluem:

Polticas de negcio: Endeream questes de negcio, acordos de nveis de servio (SLA), critrios

de desempenho, escalabilidade ou confiabilidade, nveis de aprovao ou mesmo limites de gastos

como servios externos pagos (ex. consulta de CEP dos correios).

Polticas de conformidade: Tratam regulaes de setores da indstria como, por exemplo, o TISS

para a sade suplementar brasileira ou o IFX para servios financeiros.

Conformidade a padres tecnolgicos: Endeream padres tcnicos diversos tais como WS-I para

interoperabilidade ou o WADL ou WSDL para a exposio de contratos de servios.

Polticas de segurana: Abordam padres para garantir o transporte seguro de informaes,

auditoria, autenticao e autorizao, entre outros.

Polticas de processos: Abordam aspectos do ciclo de vida de um servio, como por exemplo,

quem pode publicar um servio em produo, quem pode mudar a verso de um servio ou como

servios antigos sero aposentados.

Governana de servios atravs de polticasEmbora nem todo aspecto de governana possa ser automatizado, as polticas de QoS (negcio ou

segurana) de um servio podem ser descritas atravs da UML e eventualmente automatizadas.

Considere como exemplo de um servio (Self-Service Aluno) que precise operar com

disponibilidade de 99% e que requeira transporte seguro para trfego das suas informaes.

Os dois atributos de qualidade (disponibilidade e transporte seguro) so definidos como polticas e

ento aplicadas sobre um determinado servio. A Figura 12 mostra este caso, onde um

determinado servio possui dependncias de duas polticas.

Quando um servio depende de uma poltica, podemos tambm dizer que esta poltica aplicada

em tempo de execuo sobre aquele servio. Caso exista alguma falha no atendimento do atributo

de qualidade, ento o servio tem o seu QoS comprometido.



Figura 12. Aplicao de polticas de governana sobre um servio.

A Tabela 2 fornece um catlogo inicial de polticas comuns em projetos SOA. Este catlogo pode

ser estendido e personalizado conforme a necessidade particular de um projeto ou empresa.

Poltica Descrio

Alta

Disponibilidade

(99%)

O servio deve operar com alta disponibilidade, definida em base diria,

mensal ou anual. Se medido em base diria, o servio no pode ficar mais

que 14 minutos fora do ar, somando-se as interrupes no perodo.

Se medido em base mensal, no pode ficar mais que sete horas fora do ar

em cada ms. Se medido em base anual, no pode ficar mais que quatro

dias fora do ar no ano.

Auditoria simples As operaes de um servio que promovem modificao em dados devem ser

auditadas.

Auditoria ampla

(no-repdio)

Todas as operaes (inclusive de leitura) de um servio devem ser auditadas.

Autenticao A invocao a um servio deve ser validada atravs das credenciais do

solicitante.



Autorizao As operaes a um servio devem ser validadas atravs uma lista de controle

de acesso (ACL), para avaliar a permisso apropriada do solicitante.

Banda de

passagem alta

O volume de mensagens servidas por unidade de tempo por servio deve ser

de pelo menos 1.000.000 de mensagens por dia.

Endereamento

Virtual

O endereo (URL) do servio deve ser virtualizado para a reduo da

dependncia entre o fornecedor e o consumidor de servios.

Tempo de

Resposta

Instantneo

O tempo mdio (estatisticamente) das operaes de um servio no deve ser

maior que 0.1 segundos.

Tempo de

Resposta Rpido

O tempo mdio das operaes de um servio no deve ser maior que um

segundo.

Tempo de

Resposta Bom

O tempo mdio das operaes de um servio no deve ser maior que seis

segundos.

Transporte seguro As mensagens dos parmetros e resposta das operaes do servio devem

ser enviadas com confidencialidade e integridade.

Tabela 2. Catlogo de Polticas SOA.

Definio de dependncias entre serviosServios podem possuir dependncias de operaes de outros servios e estas relaes tambm

podem ser comunicadas pelos projetistas para o seu time.

Estas dependncias permitem que servios de mais alto nvel estejam baseados em servios de

mais baixo nvel, faam reuso de operaes j criadas anteriormente e tambm promovam a

reusabilidade em um nvel mais elevado.

Como exemplo, consideremos um servio de efetivao de matrcula semestral de aluno que use as



funes de anlise de pr-requisitos de matrcula em disciplina e tambm a consulta sobre a

adimplncia deste aluno. Observe o resultado deste mapeamento na Figura 13.

Figura 13. Servios podem estabelecer dependncias com outros servios.

Especificao de contratos de operaes e dados de serviosUma vez que servios sejam identificados, tenham suas dependncias definidas e polticas

aplicadas, eles podem ser especificados.

A especificao define o contrato de operaes, onde cada operao recebe um ou mais objetos e

retorna um objeto ou uma falha (exceo). Contratos devem exigir um forte cuidado pelo projetista

e talvez sejam o ponto mais importante para a construo de servios reusveis.

A especificao de um bom contrato (ou API) deve obedecer s seguintes propriedades:

ser de fcil aprendizado;

ser fcil de usar, mesmo sem documentao;

ser difcil de ser mal utilizada;

fcil de ler e ser mantida;

fcil para estender.

Bons princpios para a especificao de contratos incluem:



Ter ateno aos nomes dos servios, operaes e mensagens. Nomes devem ser autoexplicativos

e orientados pelos conceitos de negcio;

Reduzir o tamanho das funcionalidades expostas. A API de um servio deve ter o menor tamanho

possvel para atender aos requisitos de negcio;

Considerar as implicaes de desempenho do desenho dos contratos;

Reduzir o esforo dos clientes no uso da API, com a reduo de cdigos clientes que podem ser

trazidos para dentro da implementao dos servios.

Consideremos como exemplo o servio de Manter Alunos, que lida com as operaes CRUD sobre

um determinado aluno.

A Figura 14 exibe a especificao de um servio, com o seu contrato de operaes e os tipos de

dados referenciados como parmetros ou com falhas/excees.


Figura 14. Especificao de um servio, com o contrato de operaes 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 implementao do cdigo no est no servio.

Um servio apenas um contrato, agnstico de tecnologia. O servio ir invocar operaes de



classes, acessar dados de tabelas e manipular outras primitivas na linguagem alvo escolhida para

sua implementao.

Aplicao de padres SOA para contratos de servios

Hoje se h conhecimento acerca de um conjunto de cinco padres de projeto que podem promover

uma melhor modelagem de contratos:

Padro: Contratos Concorrentes

o Problema: Um contrato de um servio pode no ser apropriado ou aplicvel a todos os seus

consumidores. Um contrato definido como um conjunto de operaes.

o Soluo: Mltiplos contratos podem ser criados para um nico servio. Uma classe pode expor

mltiplos contratos atravs da implementao e exposio de interfaces .

Padro: Centralizao de Contratos

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

servio atravs de diferentes pontos de entrada, resultando em diferentes formas de dependncias

de implementao que inibem a evoluo do servio.

o Soluo: Acesso lgica de um servio limitado ao seu contrato, o que fora os consumidores a

evitar dependncias de implementao.

Padro: Contratos No Normalizados

o Problema: Servios com contratos estritamente normalizados podem impor demandas funcionais

e de performance desnecessrias para alguns programas consumidores.

o Soluo: Contratos podem incluir uma certa medida de desnormalizao, expressando um

contrato de forma redundante para diferentes tipos de programas consumidores.

Padro: Contratos Desacoplados

o Problema: Para que um servio seja um recurso corporativo, ele deve ser equipado com um

contrato tcnico que existe independentemente da sua implementao.



o Soluo: Um contrato fisicamente desacoplado da sua implementao.

Padro: Abstrao das Validaes

o Problema: Contratos que contm restries detalhadas de validaes so invalidados mais

facilmente quando as regras destas restries mudam.

o Soluo: Lgica e regras de validaes granulares podem ser abstradas do contrato do servio, o

que reduz a granularidade de restries e potencialmente aumenta a longevidade do contrato.

Anlise da granularidade de servios

A identificao dos servios candidatos um processo que consiste no estudo das entidades

nucleares, processos de negcio e ativos organizacionais. O resultado uma lista de servios que

tipicamente tem dois tipos de gros:

Servios de gro fino: Possuem um nico contrato e poucas operaes de negcio (< 5).

Servios de gro grosso: Normalmente possuem mais de um contrato e muitas operaes de

negcio.

A anlise da granularidade um processo que se segue identificao de servios e que pode levar

reorganizao do seu portflio. Embora no existam construtos especficos da UML para este

processo, o resultado final um modelo UML refatorado. Os tipos mais comuns de operaes que

modificam a granularidade dos servios so:

Unificao: Esta operao tem por objetivo unificar dois servios de gro fino em um servio de

gro grosso que fornea, isoladamente, valor mais claro de negcio. A recomendao para o uso

deste conceito a anlise de servios de gro fino que no fornecem valor de negcio adequado e,

portanto, no devem existir no portflio de servios;

Decomposio: Esta operao tem por objetivo quebrar servios identificados de gro grosso em

dois ou mais servios menores.

A recomendao para o uso deste conceito a anlise de fatoraes do servio maior que podem

entregar, isoladamente, valor de negcio. Em outros cenrios, o condutor de reusabilidade pode

levar a servios de gro mais fino;

Interseo: Esta abordagem pode ser aplicada, em servios de gro grosso, para extrair um

conjunto de operaes comuns e derivar um terceiro servio que capture as operaes comuns.

Este conceito, entretanto, no deve ser aplicado com muita frequncia e tambm no deve ser



aplicado em servios de gro mais fino, pois pode levar a um alto custo de gerenciamento dos

servios ou mesmo problemas de desempenho em ambientes de produo;

Subconjunto: Esta operao agrega dois ou mais servios em um servio candidato j existente.

Diferentemente da operao de unificao, que cria um novo servio, esta operao apenas

introduz um novo subconjunto de operaes em um servio j existente no portflio. O uso

excessivo desta operao como a unificao, pode levar a uma baixa reusabilidade;

Subtrao: A subtrao de servios remove um fragmento do contrato original e, portanto, altera

a funcionalidade original do servio. Ela deve ser usada quando o contrato possuir operaes

excessivas que no agregam funcionalidade de negcio e remetem mais a um desenho OO do que

um desenho centrado em servios.

Decises de implementao sobre serviosServios SOA devem ser implementados em alguma tecnologia e ter o seu contrato estabelecido em

um padro.

O projetista, no seu desenho SOA, pode indicar algumas decises tecnolgicas e o padro a ser

usado para externalizar o contrato de seus servios. Os padres mais comuns para a

implementao de servios so apresentados na Tabela 3.

WS-* Baseados no protocolo de envelopamento SOAP, algum protocolo de

transporte (ex. HTTP, TCP ou SMTP), contratos de servios WSDL e

mensagens baseadas em XML/XSD. Os WS-* tm como grande vantagem

possuir mais de 30 especificaes para aspectos diversos de governana tais

como transaes atmicas (WS-AT), segurana de mensagens (WS-Security),

interoperabilidade de servios (WS-I) e polticas de tempo de execuo (WS-

Policy).

RS-* (REST) Baseados no protocolo HTTP, contratos de servios WADL e mensagens em

XML ou JSON. Estes padres tm como grande vantagem a simplicidade e

facilidade para aprendizado.

SCA (Service

Component

Architecture)

Modelo de componentizao de servios que promove abstrao da tecnologia

de implementao e protocolos de transporte. Largamente usado em

implementaes SOA IBM e Oracle.



WCF (Windows

Communication

Foundation)

Modelo de componentizao da Microsoft para a exposio de servios, com

abstrao da tecnologia de implementao e tambm de protocolos de

transporte.

JBI (Java Business

Integration)

Modelo de componentizao definida pela JCP (JSR 312) para a exposio de

servios implementados em plataforma Java.

Tabela 3.Padres mais comuns para a implementao de servios

A Figura 15 apresenta decises de realizao com os padres WS-*.


Figura 15. Decises de realizao de servios como WSDL, XSD e polticas como WS-Policy.

Alocao de servios a componentes e nodosServios, embora agnsticos de tecnologia pelo padro de desenho interface, devem ser

implementados em alguma tecnologia alvo. Portanto, um servio realizado atravs de

componentes de software, que so normalmente empacotados em tecnologias como LIBs, DLLs,

Assemblies, JARs ou WARs. Um componente de software que reside em um ambiente fsico

representa uma mquina real ou mquina virtual em um ambiente de nuvens.

Na UML, temos primitivas bsicas para representar componentes (retngulos) e nodos (cubos) em



uma visualizao chamada de diagrama de implantao. Atravs de diagramas de implantao

podemos mostrar onde servios so efetivamente implementados e implantados, descrevendo a

topologia fsica de uma arquitetura baseada em servios. Observe a Figura 16. Neste diagrama

indicamos que um componente (software) reside em um nodo (hardware) e realiza um ou mais

servios SOA.

Figura 16. Fragmento que mostra a alocao de servios a componentes e nodos.

Projetistas devem trabalhar a visualizao de implantao SOA em conjunto com o time de

infraestrutura para atender a polticas de natureza fsica tais como a volumetria, performance,

escalabilidade e recuperao de falhas.

Modelagem de servios de infraestruturaFinalmente, o projetista SOA pode representar uma camada mais nuclear de servios que tem por

papel suportar os servios de nvel mais alto. Normalmente, estes servios no tm ligao direta

com o negcio, embora tenham papel central na manuteno de atributos de qualidade ou na

facilitao da orquestrao dos servios.

Estes servios podem ser classificados nos seguintes tipos:



Barramento de Servios: um tipo de servio de middleware que promove um conjunto variado

de funcionalidades para gerir mensagens, controle do trfego e abstrao de protocolos e

localizaes.

So normalmente implementados por produtos muito complexos e em implementaes SOA de

grande porte (ex. ESBs da IBM, Oracle ou TIBCO), embora estejamos observando barramentos

leves como o Apache Camel ou o Microsoft WCF comearem a ser usados em implementaes SOA

leves;

Intermedirios (Proxies): So interceptadores de mensagens que promovem funes mais

elementares de transmisso, roteamento ou manipulao de dados. Um uso comum para estes

servios para a implementao de polticas de transporte seguro ou auditoria;

Motores de regras: So middlewares dedicados a execuo de regras de negcio descritas em

linguagem de alto nvel (DSLs) em servios de deciso. So chamados no mercado como BRMS

(Business Rule Management Suites);

Motores de fluxos de trabalho: So middlewares dedicados orquestrao de outros servios para

a execuo de fluxos de trabalho ou mesmo processos de negcio. So chamados no mercado

como BPMS (Business Process Management Suites);

Conectores de Adaptao: So peas dedicadas ligao de um servio 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: So peas dedicadas ao roteamento de mensagens entre servios e

que promovem conectividade entre consumidores e fornecedores de servios;

Adaptadores de Transformadores: Peas dedicadas ao enriquecimento de mensagens atravs da

traduo do seu formato entre consumidores e fornecedores de mensagens.

Os diagramas de componentes e implantao podem apoiar o projetista a mostrar estes elementos

da infraestrutura SOA e comunicar como arquiteturas fsicas SOA sero implementadas em

empresas.

Os retornos da modelagem de serviosA modelagem de servios aqui proposta faz uso de diagramas de caso de uso, classes, componentes

e implantao. 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



moderadamente.

Se o esforo da modelagem no for dimensionado apropriadamente, ela pode ser muito demorada e

reduzir o seu benefcio 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 esforo em horas para a modelagem e o eixo Y o retorno do esforo de

modelagem.).

Embora este valor no possa ser quantificado em esforo ou prazo, ele deve ser analisado conforme

a realidade de cada organizao e os fatores de cada projeto (tamanho, necessidades contratuais e

distribuio fsica do time).

Figura 17. Retornos Decrescentes da Modelagem.

Algumas abordagens que podem apoiar na racionalizao do esforo de modelagem incluem:

busca pela viso em amplitude nos primeiros esforos de modelagem;

tratamento diferenciado de acordo com o valor e complexidade de cada servio. Servios mais

crticos requerem um maior investimento em modelagem e, ento, maior profundidade de anlise;

padronizao da modelagem para servios similares.

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



uma modelagem SOA centrada em UML consistente e robusta.

Passo Produto UML

01. Identificao de Conceitos

Corporativos

Diagrama de classes com nomes, onde cada nome

um elemento do modelo de domnio

corporativo.

02. Identificao de Processos

de Negcio

Diagrama de casos de uso de negcio. Cada caso

de uso de negcio corresponde a um processo de

negcio.

03. Identificao de Ativos

Existentes

Diagrama de componentes onde cada componente

corresponde a um ativo organizacional

potencialmente reusvel.

04. Identificao de Servios Diagrama de classes (sem atributos e

comportamentos) com uma classe para cada

servio.

05. Aplicao de Tipos aos

Servios

Diagrama de classes com esteretipos.

06. Governana de Servios

Atravs de Polticas

Diagrama de classes para servios e classes para

polticas.

07. Definio de Dependncia

entre Servios

Diagrama de classes com relaes de

dependncias entre servios.

08. Especificao de Contratos

de Operaes e Dados de

Servios

Diagrama de classes com servios onde os

mtodos da classe descrevem o contrato do

servio. Tambm gerado o diagrama de classes

para representar as estruturas de dados que so



parmetros e retornos das operaes.

09. Anlise da Granularidade

dos Servios

Diagrama de classes refatorado com mtodos ou

classes movimentadas atravs de operaes

lgicas diversas.

10. Alocao de Servios a

Componentes e Nodos

Diagrama de classes com componentes e nodos

que mostrem o local fsico onde os servios iro

operar.

11. Modelagem de Servios de

Infraestrutura

Diagrama de componentes com servios de

infraestrutura que cuidam de funes mais

fundamentais para atender uma arquitetura SOA.

Tabela 4. Passos da modelagem UML para servios

Os passos 1 a 4 so normalmente realizados como um esforo anterior aos projetos SOA (pr-game

em mtodos geis). Os passos 5 a 11 so realizados repetidamente em pequenos projetos, que

entregam um ou mais servios em ambiente de produo, com uma rpida reviso e extenso dos

produtos gerados nos passos 1 a 4.

Outros diagramas da UML podem ser usados conforme necessrio para agregar valor na

comunicao. Em cenrios complexos de mediao, por exemplo, o uso de diagrama de sequncia

ou diagrama de interao pode comunicar a sequncia de mensagens desta mediao.

Em casos muito complexos de agregao de servios ou de alocao de servios a nodos e

componentes, o diagrama de estruturas compostas pode comunicar a estruturao recursiva de

contratos.

A abordagem centrada em servios introduz uma forma alternativa de construo de sistemas,

baseada na implantao de pequenos servios reusveis e agnsticos de tecnologia. Se usada

corretamente, pode promover benefcios concretos para as organizaes, como a sobrevida de

ativos de TI, reduo de dependncias tecnolgicas e aumento da eficincia.

Os princpios da modelagem UML aqui apresentados podem ser aplicados em pequenos projetos,

com duas ou trs pessoas, com uso de quadros brancos ou mesmo em grandes projetos com

dezenas de pessoas, com o uso de ferramentas formais de modelagem.



Gostei (3) (0)

O que voc achou deste post?

Para os iniciantes em SOA, recomendvel o uso das tcnicas de modelagem para a identificao

de servios para a gerao de um inventrio mais apropriado. Para aqueles que j experimentaram

SOA, so recomendveis tcnicas de modelagem de contratos de operaes de servios.

Para aqueles times que querem ir alm, recomenda-se a modelagem de polticas para introduzir

governana sobre seus servios.

Referncias

[1] Dias Jr, J. J. L., Oliveira, J., & Meira, S. R. L. (2012). Pontos Chaves para Adoo de Uma

Arquitetura Orientada a Servios: Uma Anlise Comparativa de Modelos de Maturidade SOA da

Indstria. In VII Simpsio Brasileiro de Sistemas de Informao.

[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 TOGAFs Implementation and Migration phases. Reading, Berkshire: Whitepaper, The

Open Group.

Marco Aurlio De Souza Mendes

consultor independente de Arquitetura de Software e Engenharia de Software com mais de 16 anos de experincia em projetos de TI. tambm professor de ps-graduao dos cursos de Estratgias de Arquitetura de Sistemas do IGTI e [...]



Postar dvida / ComentrioNo h comentrios

Meus comentarios

Publicidade

Servios

Inclua um comentrio

Adicionar aos Favoritos

Marcar como lido/assistido

Incluir anotao pessoal

Verso para impresso

Publicado em 2015

+Engenharia

Mais postsArtigo



Automao de testes para aplicaes mveis em Android Parte 1

Artigo

Gerncia de requisitos com OSRMT

Artigo

Modelagem de processos com o Oryx Standalone Client

Artigo

Guia PMBOK: Auditoria em projetos de software

Artigo

Elaborao do contrato com Product Backlog

Artigo

Conceitos e processos para a criao de PMOs geis Parte 2

Revista

Revista Engenharia de Software Magazine 76

Artigo

Gerenciando projetos geis com o Kanbanize

Artigo

Como identificar dvida tcnica em projetos utilizando minerao de dados

Listar mais contedo



Anuncie | Loja | Publique | Assine | Fale conosco

Hospedagem web por Porta 80 Web Hosting

DevMedia

66.554 pessoas curtiram DevMedia.

Plug-in social do Facebook

Curtir

www.devmedia.com.brModelagem de servios com UML

NlcnZpY29zLWNvbS11bWwvMzI0OTYA: form1: txtsearch: Buscarbutton3:

ZhbHNlJnNob3dfZmFjZXM9ZmFsc2UA: form0: lsd: AVrqrgSRhref: http://www.devmedia.com.br/modelagem-de-servicos-com-uml/32496action: likenobootload: iframe_referer: r_ts: 1432854484ref: xfbml: app_id: 145393072270566button0: lsd_(1): AVrqrgSRhref_(1): http://www.devmedia.com.br/modelagem-de-servicos-com-uml/32496action_(1): likenobootload_(1): iframe_referer_(1): r_ts_(1): 1432854484ref_(1): xfbml_(1): app_id_(1): 145393072270566

RyZWFtPWZhbHNlJndpZHRoPTc2NwA=: form0: button0:

Documents

Modelagem de Serviços Com UML