Modelagem de Serviços Com UML

Modelagem de servios com UML
DEVMEDIA
Buscar
comentrios
post favorito (6)
Engenharia de Software75 - 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.
Gostei
(3)
Curtir
(0)
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,
http://www.devmedia.com.br/modelagem-de-servicos-com-uml/32496[28/05/2015 20:09:56]
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 SOA
Projetos
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 TI
A
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 UML
Conhecer
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 UML
Servios
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 <<Processo de Negcio>>.
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 servios
A
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 Colaborativo

O
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 comunicao

O
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 modelagem
A
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 Valor

A
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 servios
Na
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 polticas
Embora
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
O
servio deve operar com alta disponibilidade, definida em base diria,
Disponibilidade
mensal
ou anual. Se medido em base diria, o servio no pode ficar mais
(99%)
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
Todas
as operaes (inclusive de leitura) de um servio devem ser auditadas.
(no-repdio)
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
Endereamento
Virtual
Tempo
de
Resposta
O
volume de mensagens servidas por unidade de tempo por servio deve ser
de
pelo menos 1.000.000 de mensagens por dia.
O
endereo (URL) do servio deve ser virtualizado para a reduo da
dependncia
entre o fornecedor e o consumidor de servios.
O
tempo mdio (estatisticamente) das operaes de um servio no deve ser
maior
que 0.1 segundos.
Instantneo
Tempo
de
Resposta Rpido
Tempo
de
Resposta Bom
Transporte
seguro
O
tempo mdio das operaes de um servio no deve ser maior que um
segundo.
O
tempo mdio das operaes de um servio no deve ser maior que seis
segundos.
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 servios
Servios
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
servios
Uma
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 <<Interface>>.
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 servios
Servios
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
(WSPolicy).
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
Modelo de componentizao de servios que promove

abstrao da tecnologia
Component
de implementao e protocolos de transporte.

Largamente usado em
Architecture)
implementaes SOA IBM e Oracle.
WCF (Windows
Modelo de componentizao da Microsoft para a

exposio de servios, com
Communication
abstrao
da tecnologia de implementao e tambm
de protocolos de
Foundation)
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 nodos
Servios, 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 infraestrutura
Finalmente,
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 servios
A 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
01.
Identificao de Conceitos
Corporativos
Produto UML
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
Diagrama de
classes com esteretipos.
Servios
06.
Governana de Servios
Atravs de Polticas
07. Definio
de Dependncia
entre Servios
08.
Especificao de Contratos
Diagrama de
classes para servios e classes para
polticas.
Diagrama de
classes com relaes de
dependncias entre servios.
Diagrama de
classes com servios onde os
de Operaes e Dados de
mtodos da classe descrevem o contrato do
Servios
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.
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
[...]
O que voc achou deste

post?
Gostei
(3)
(0)
No 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 posts
Artigo
Postar dvida / Comentrio
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
DevMedia
Curtir
66.554 pessoas curtiram DevMedia.
Plug-in social do Facebook
Hospedagem web por Porta 80 Web Hosting

Modelagem de Serviços Com UML

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Modelagem de Serviços Com UML

Hochgeladen von

Copyright:

Verfügbare Formate

Modelagem de servios com UML

post favorito (6)

Engenharia de Software75 - ndice

Modelagem de servios com UML

Fique por dentro

Modelagem de servios com UML

especificao e realizao de servios.

sobre os investimentos de TI;

capacidade de operao autnoma

maior facilidade para reuso e

abstrao tecnolgica, que

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

Modelagem de servios com UML

Figura 1. Viso Geral de uma Arquitetura

Modelagem de servios com UML

organizados em pequenos projetos. Cada projeto entrega poucos servios atravs

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

Modelagem de servios com UML

Figura 3. Nveis de maturidade de modelagem.

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

servios fracamente acoplados:

operao autnoma em ambiente

granularidade mais alta.

Modelagem de servios com UML

implantao da UML permitem expressar a alocao

Finalmente, diagramas de casos de uso permitem expressar as funcionalidades de

Modelagem de servios com UML

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

matrcula em um curso, conforme mostrado na Figura 7.

Modelagem de servios com UML

Figura 7. Servio de pagamento

Modelagem de servios com UML

abrir imagem em nova janela

Modelagem de servios com UML

Isto realmente um servio?

O gro (tamanho) deste servio

Os servios do meu inventrio

Como decompor servios?

Dica 1: Trabalho Colaborativo

Dica 2: Modelagem para fins de comunicao

Dica 3: Pequenas sesses de modelagem e maior

Dica 4: Anlise de Valor

Modelagem de servios com UML

O servio tem valor de negcio e

O servio reusvel dentro e

O servio torna a sua TI mais

O servio tem valor no estado

Modelagem de servios com UML

Tabela 1.Tipologia de servios SOA

Figura 11. Tipologia de

Modelagem de servios com UML

Polticas de negcio: Endeream

Polticas de conformidade: Tratam

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

Polticas de segurana: Abordam

Polticas de processos: Abordam

Modelagem de servios com UML

Figura 12. Aplicao

Modelagem de servios com UML

Modelagem de servios com UML

funes de anlise de pr-requisitos de matrcula em disciplina e

Figura 13. Servios podem

ser de fcil aprendizado;

ser fcil de usar, mesmo sem