Embed Size (px)
Citation preview
DEPARTAMENTO DE COMPUTAÇÃO
CURSO DE PÓS-GRADUAÇÃO EM ENGENHARIA DE SOFTWARE COM UML
“LATO-SENSU”
MAX CLAUS NUNES
MODELAGEM UML APLICADA À ARQUITETURA SOA
Londrina
2012
MAX CLAUS NUNES
MODELAGEM UML APLICADA À ARQUITETURA SOA
Monografia apresentado à Banca Examinadora do
Curso de Pós-Graduação em Engenharia de
Software com UML do Centro Universitário
Filadélfia de Londrina - UniFil como requisito
parcial para obtenção do grau de Especialista em
Engenharia de Software sob a orientação do
Professor MSc. Sergio Akio Tanaka.
LONDRINA
2012
MAX CLAUS NUNES
MODELAGEM UML APLICADA À ARQUITETURA SOA
Monografia apresentado à Banca Examinadora do Curso de Pós-Graduação em Engenharia
de Software do Centro Universitário Filadélfia de Londrina - UniFil em cumprimento a
requisito parcial para obtenção do título de Especialista em Engenharia de Software.
APROVADA PELA COMISSÃO EXAMINADORA
EM LONDRINA, 30 DE JUNHO DE 2012.
Prof. MSc. Sergio Akio Tanaka (UniFil) - Orientador
Profa. MSc. Simone Sawasaki Tanaka (UniFil) - Examinadora
Londrina, 30 de Junho de 2012.
Ao Aluno MAX CLAUS NUNES
Prezado(a) Senhor(a):
Tem a presente a finalidade de NOTIFICAR-LHE nos termos do art. 867 e seguintes
do Código de Processo Civil com vistas a prevenir responsabilidades, provendo a conservação
e ressalva de direitos. A “UniFil” em razão da apresentação recorrente de trabalhos onde se
tem efetuado a cópia de trechos e até capítulos ou trabalhos inteiros, vem notificá-lo que tal
pratica é vedada pela Lei de Direitos Autorais nº 9.610/98 em seus artigos 1º, 5º incisos VI e
X, 7º, 22º, 24º inciso IV, 29º e 41º, cumulados com a nova redação dos artigos 184 e 186 do
Código penal dados pela lei 10.695/2003, que prevê não apenas a proibição de cópia total ou
parcial sem atribuição da devida autoria como inclusive pena de detenção de até quatro anos
mais multa para quem assim proceder. Assim sendo, considera-se o aluno: MAX CLAUS
NUNES, da Pós-Graduação em Engenharia de Software com UML, Linha de Formação:
Engenharia de Software, ciente de previsão legal que veda tal prática e se mesmo assim optar
por faze-lo deverá arcar sozinho com o ônus de tal ato, quer seja ele penal, cível ou
administrativo, não podendo a Instituição de Ensino ser responsabilizada por opção do aluno
sem seu consentimento ou anuência. .
Na esfera administrativa desde já ficam, também devidamente notificados, que os
trabalhos copiados na íntegra ou que apresentem cópia parcial, serão sumariamente
reprovados; bem como estarão sujeitos a outras medidas cabíveis. Conforme Regulamento da
instituição no qual relata o seguinte: “Na constatação de procedimentos ilícitos para a
elaboração dos trabalhos de estágio, caracterizando cópias parciais ou integrais (plágio), será
atribuído a média 0,0 (zero) ao aluno no bimestre em curso, não cabendo recurso”.
Sem mais para o momento.
Atenciosamente.
Aluno:________________________________________
AGRADECIMENTOS
Agradeço a minha mãe e ao meu pai que sempre me incentivaram a investir nos
estudos e estar sempre aperfeiçoando a formação educacional, a carreira e os valores morais, e
dos quais sempre me baseei para a realização de tais características.
Agradeço a minha namorada, que soube entender essa fase na vida, na qual precisei
em certos momentos dar mais atenção aos estudos.
Agradeço também ao meu amigo Mauro Correa Cruz, do qual desenvolvi boa parte
desse trabalho na casa do mesmo e do qual sempre posso contar para alcançar novos
objetivos, sejam eles quais forem.
“As dificuldades devem ser usadas para crescer, não para desencorajar. O espirito
humano cresce mais forte no conflito.” (William Ellery Channing )
CLAUS NUNES, Max. Modelagem UML aplicada à arquitetura SOA. Londrina, 2012. 39f. Monografia do Curso (Engenharia de Software) - Curso Pós Graduação em Engenharia de Software com UML. Centro Universitário Filadélfia de Londrina - UniFil, Londrina, 2012.
RESUMO
Este trabalho apresenta os conceitos da modelagem do Unified Modeling Language (UML) aplicada na abordagem Service-Oriented Architecture (SOA), com o intuito de definir os modelos de design através do perfil Service Oriented Architecture Modeling Language (SoaML). Ao longo do trabalho foram descritos os conceitos dos temas abordados e aplicado a modelagem SoaML, apresentando como especificar, documentar e construir artefatos UML de um sistema baseado na arquitetura orientada a serviços, apresentando através da aplicação desenvolvida no estudo de caso, modelos reais de como a modelagem com SoaML é realizada.
Palavras-chave: Modelagem, SOA, UML, SOAML
ABSTRACT
This paper presents the modeling concepts of the Unified Modeling Language (UML) approach applied in Service-Oriented Architecture (SOA), in order to define the design models through the Profile Service Oriented Architecture Modeling Language (SoaML). Throughout the work have described the concepts of the topics discussed and applied modeling SoaML, showing how to specify, document and UML artifacts to build a system based on service-oriented architecture, developed by the application presenting the case study, actual models of how the modeling SoaML is performed.
Key words: Modeling, SOA, UML, SOAML
LISTA DE FIGURAS E TABELAS
Figura 1 - Diagramas da UML 2.2 (Melo, 2010) ................................................... 1515
Figura 2Diagrama de Classes ................................................................................. 2020
Figura 3 Acesso ao serviço de venda SOS Posto ................................................... 2121
Figura 4Processo do Negócio - Venda ................................................................... 2323
Figura 5 Estrutura do Projeto ................................................................................. 2424
Figura 6 Capacidades ............................................................................................. 2525
Figura 7 Interfaces - Bomba, Cliente, Produto e Tanque ....................................... 2626
Figura 8 Interface Venda ........................................................................................ 2626
Figura 9 Contratos de Serviço ................................................................................ 2727
Figura 10 Protocolo Venda - Bomba ...................................................................... 2828
Figura 11 Protocolo Venda – Cliente ..................................................................... 2929
Figura 12 Protocolo Venda - Produto..................................................................... 3030
Figura 13 Protocolo Venda - Tanque ..................................................................... 3131
Figura 14 Protocolo Venda Automática ................................................................. 3232
Figura 15 Protocolo Venda Caixa .......................................................................... 3333
Figura 16 Participantes ........................................................................................... 3434
Figura 17 Arquitetura ............................................................................................. 3636
Tabela 1 Estereótipos SoaML (Deeg, 2012) .......................................................... 1717
LISTA DE ABREVIATURAS E SIGLAS
BPM Business Process Model ou Business Process Management SOA Arquitetura de Orientada a Serviços
SOAML Service oriented architecture Modeling Language UML Linguagem de Modelagem Unificada WCF Windows Communication Foundation RUP Rational Unified Process RSA Rational Software Architect PI Inteligência de Processos
Formatado: Inglês (EUA)
SUMÁRIO
1 INTRODUÇÃO ....................................................................................................... 1111
2 REVISÃO DE LITERATURA ............................................................................... 1313
3 ESTUDO DE CASO ................................................................................................ 1919
3.1 MODELO DE PROCESSO DO NEGÓCIO (BPM) ................................................. 2121
3.2 MODELO DE SERVIÇOS ....................................................................................... 2424
3.2.1 Estrutura do Projeto ............................................................................................ 2424
3.2.2 Capacidades .......................................................................................................... 2424
3.2.3 Interfaces .............................................................................................................. 2525
3.2.4 Contratos .............................................................................................................. 2626
3.2.5 Participantes ......................................................................................................... 3434
3.2.6 Arquitetura ........................................................................................................... 3535
4 CONCLUSÕES E TRABALHOS FUTUROS ...................................................... 3737
REFERÊNCIAS ................................................................................................................. 3838
1 INTRODUÇÃO
No desenvolvimento de sistemas, inúmeros fatores podem impactar no sucesso do
projeto. A falta de documentação e modelagem do mesmo torna a base inicial fraca e propícia
a insucesso. Sem documentação, no decorrer do projeto, várias tarefas tornam-se mais difíceis
e trabalhosas, por não possuir um documento disponível para informativo da equipe atual e
futura envolvida no projeto.
O princípio de Pareto relata que 80% dos problemas são causados por apenas 20%
das causa (Alchin, 2010). Realizando a documentação adequadamente, é possível definir
exatamente o escopo e limites do projeto, antecipando dúvidas, problemas e pontos críticos
que seriam notados apenas no desenvolvimento, se não fosse documentado previamente.
Dando prioridade de análise e design, para os pontos mais impactantes do projeto.
“A UML é uma linguagem para visualização, especificação, construção e
documentação, na qual a modelagem viabiliza que a informação seja transcrita graficamente,
possibilitando uma comunicação de fácil entendimento entre todos os envolvidos, devido à
modelagem visual ser a forma mais clara de representar uma informação. Os meta-modelos
providos por ela possibilitam manter rastreabilidade entre diagramas, provendo uma
informação importante, ao analisar impactos de mudanças na arquitetura.” (Alhir, 2002).
Sistemas que seguem a abordagem arquitetural orientada a serviços, tendem a
possuir uma estrutura mais complexa e diferente, das abordagens tradicionais, por tratarem de
serviços compartilhados internamente e externamente do domínio da empresa. Possibilitando
fornecer serviços a parceiros, fornecedores e clientes; e da mesma forma consumir serviços
providos por outras empresas.
Uma arquitetura de serviço é uma especificação formal dos requisitos de negócios
que são executados pela interação dos participantes do serviço, sem tratar de qualquer questão
de arquitetura ou de implementação do suporte técnico da Tecnologia da Informação (TI).
Nesse caso, a arquitetura do serviço contém a mesma informação que o processo de negócio
original e pode ser tratada como uma especificação pela maneira como realiza esse processo
de negócio.
Para representar devidamente os serviços, forma de dependências, comunicação e
outras características da Service Oriented Architecture (SOA) é possível utilizar uma extensão
para Unified Modeling Language (UML), como o Service oriented architecture Modeling
Language (SoaML) que fornece várias maneiras de identificar serviços. Os requisitos do
Formatado: Português (Brasil)
processo de negócio podem ser vistos como uma arquitetura de serviço e, dessa maneira,
indicar os participantes no processo de negócio, os contratos de serviços que especificam a
modo de interação e a coreografia de seus serviços e solicitações.
O objetivo deste trabalho é especificar uma abordagem simples e efetiva na
documentação UML para a arquitetura orientada a serviços, através do SoaML. Identificando
os serviços a partir de um fluxo do processo de negócios, além de disponibilizar uma
explicação sucinta sobre os principais meta-modelos utilizados nesta arquitetura.
Em relação à metodologia utilizada foi fundamentado na obra de Salomon (2004),
onde foi produzido um trabalho monográfico, baseado nos seguintes métodos:
• pesquisas bibliográficas, pesquisa em teses e artigos com valor ao assunto
apresentado, análise de trabalhos monográficos;
• análises de estudos de caso realizado em um projeto existente.
O trabalho teve o foco de realizar uma pesquisa detalhada sobre a modelagem UML
voltada para recursos e características específicas da arquitetura orientada a serviços,
mostrando assim os resultados encontrados na aplicação do mesmo.
Este trabalho esta organizado em capítulos. O capítulo 2 apresenta os principais
conceitos utilizados neste trabalho. O capítulo 3 apresenta a aplicação do SoaML na
especificação e documentação de um projeto orientada a serviços. O Capítulo Erro! Fonte de
referência não encontrada.4 apresenta uma análise sobre cada estudo de caso e os resultados
obtidos. Finalmente no capítulo 45 são apresentadas as conclusões e trabalhos futuros.
2 REVISÃO DE LITERATURA
Este capítulo apresenta os principais conceitos utilizados neste trabalho.
1.1 Arquitetura de Software
A arquitetura é um termo muito abrangente e por isso a própria arquitetura de
software possui diversas definições. Segue três referências diferentes para esta definição:
"A arquitetura de software de um programa ou um sistema de computador é a
estrutura ou estruturas do sistema, as quais compreendem os componentes, as propriedades
visíveis externamente dos componentes, e os relacionamentos entre eles.” (Bass et al., 2003).
"Uma arquitetura é a definição de significantes decisões sobre a organização de um
sistema de software, a seção dos elementos estruturais e as interfaces pela quais o sistema é
composto, junto com o seu comportamento como especificado na colaboração entre aqueles
elementos, a composição desta estrutura e comportamento dos elementos em subsistemas
cada vez maiores, e o estilo arquitetural o qual guia esta organização - estes elementos e suas
interfaces, suas colaborações, e suas composições.” (BOOCH et al., 1999).
"Arquitetura de software é uma definição dos conceitos e decisões de design sobre a
estrutura e textura do software o qual deve ser feito antes da engenharia simultânea para
permitir satisfação efetiva da arquitetura significante explicita funcionalidade e qualidade dos
requisitos e implícita requisitos da família do produto, o problema, e os domínios da solução.”
(JAZAYERI et al., 2000).
Baseado nestas definições está definido que uma arquitetura está preocupada com a
estrutura e comportamento, e que as decisões importantes só podem estar de acordo com um
estilo arquitetônico, sendo influenciada pelos envolvidos e seu ambiente, e incorpora decisões
com base na lógica.
1.2 UML
A Unified Modeling Language (UML) facilita na especificação e documentação, por
disponibilizar metamodelos e diagramas que representam através de imagens informações,
que uma vez escrita poderia se tornar extensa e complexa.
“A UML é uma linguagem padrão para especificar, visualizar, documentar e
construir artefatos de um sistema e pode ser utilizada com todos os processos ao longo do
ciclo de desenvolvimento e através de diferentes tecnologias de implementação” (FURLAN,
1998).
A UML não especifica uma metodologia ou procedimento, como Rational Unified
Process (RUP) e o SCRUM, mas disponibiliza suporte na análise, especificação e
documentação seguida por tais metodologias.
UML define notações e semânticas para os seguintes domínios:
• a interação do usuário ou modelo de caso de uso: descreve a fronteira e a
interação entre o sistema e o usuário;
• a interação ou modelo de comunicação: descreve como os objetos no sistema
irão interagir com cada um dos outros para as funcionalidades do sistema;
• o estado ou modelo dinâmico: Gráficos de estados descrevem os estados ou
condições na quais classes assumem sobre o tempo. Gráfico de atividade
descreve fluxos que o sistema irá implementar;
• o lógico ou modelo de classes: descrevem as classes e objetos nos quais irão
tornassem o sistema;
• o físico modelo de componente: descreve o sistema (e algumas vezes
componentes de hardware) no qual ira tornar-se o sistema;
• o físico modelo de entrega: descreve a arquitetura física e os componentes de
entrega da arquitetura de hardware.
Na Figura 1Figura 1 estão especificados os diagramas disponíveis na versão UML
2.2.
Figura 1 - Diagramas da UML 2.2 (MELO, 2010)
1.3 SOA
“SOA se aplica de baixo acoplamento e interoperáveis serviços de software
para suportar processos de negócios das empresas, fornece um mecanismo para a
definição de modelos de negócios. Pode ajudar a garantir que os serviços representem
fielmente os modelos de negócios.” (LAWER, 2008).
Um serviço é uma oferta de valor para outro através de uma interface bem
definida e disponível para uma comunidade (que pode ser o público em geral). Um
serviço resulta no trabalho oferecido de um para outros.
A arquitetura orientada a serviços (SOA) é um meio de organização e
compreensão sobre a organização, comunidades e sistemas para aumentar a agilidade,
escalabilidade e interoperabilidade. O SOA abrange pessoas, organizações e sistemas
oferecendo serviços para cada um dos outros. Estes serviços nos permitem obter
algumas coisas prontas sem precisar fazer nós mesmos ou sem conhecer como
acontece isto - possibilitando-nos ser mais eficientes e ágeis. Serviços também
permitem oferecer nossas capacidades para os outros em troca de algum valor -
estabelecendo assim uma comunidade, processo ou mercado. O paradigma do SOA
funciona igualmente bem para integração de capacidades existentes como para criação
e integração de novas capacidades.
1.4 SOAML
“Service oriented architecture Modeling Language (SoaML) fornece um modo
padrão para arquitetura de soluções e modelo SOA usando a Linguagem de
Modelagem Unificada (UML). O perfil utiliza os mecanismos internos de extensão do
Meta Object Facility (MOF) e UML para definir conceitos de SOA em termos de
conceitos existentes UML. SoaML pode ser usado com corrente "off the shelf"
ferramentas UML, mas algumas ferramentas podem oferecer recursos de modelagem
aprimorados. “(SoaML, 2009).
Segundo o Specification for the UML Profile and Metamodel for Services
(SOAML, 2009) o SoaML possui capacidades de:
• identificação de serviços, os requisitos que se destinam a cumprir e as
dependências previstas entre eles;
• especificação dos serviços, incluindo as capacidades funcionais que oferecem,
o que os consumidores capacidades deverão fornecer os protocolos ou regras
para usá-los, e a informação de serviço trocado entre consumidores e
fornecedores;
• definindo os consumidores e provedores de serviço, os que requisitam os
serviços que consomem e proporcionam, como eles estão conectados e como
as capacidades de serviços funcionais são utilizados pelos consumidores e
implementado por fornecedores de uma forma consistente com ambos os
protocolos de atendimento das especificações e exigências cumpridas;
• as políticas de utilização e prestação de serviços;
• a capacidade de definir esquemas de classificação com aspectos para apoiar
uma ampla gama de arquitetônicos, organizacionais e físicos esquemas de
particionamento e restrições.
Formatado: Português (Brasil)
A Erro! Fonte de referência não encontrada.Tabela 1 contêm alguns dos
estereótipos disponibilizados pelo SoaML, os quais foram abordados neste trabalho
são.
Tabela 1 Estereótipos SoaML (DEEG, 2012)
Estereótipos SoaML Metaclass UML Descrição
Interface de Serviço
(ServiceInterface)
Classe ou Interface Define como um ponto
de serviço ou um ponto
de requisição e o tipo
do papel no Contrato
do Serviço
(ServiceContract)
define como um
participante necessita
interagir para
disponibilizar ou
utilizar um serviço.
Contrato do Serviço
(ServiceContract)
Colaboração Especifica as condições
entre provedores e
usuários do serviço.
Arquitetura de Serviços
(ServicesArchitectur)
Colaboração Visão de alto nível do
SOA qual define como
um grupo de
participantes trabalham
juntos em um grupo no
sentido de certa partilha
proposta por prover e
usar serviços
Ponto de Serviço
(ServicePoint)
Porta Oferece um serviço do
tipo ServiceInterface ou
Interface
Ponto de Requisição
(RequestPoint)
Porta Utiliza um serviço com
uma ServiceInterface
ou Interface
Participante
(Participant)
Componente Oferece um service por
uma ServicePoint ou
utiliza um serviço por
uma RequestPoint
O capítulo 3 apresenta o estudo de caso onde contêm a especificação com exemplos
sobre o assunto.
Este capítulo teve o objetivo de familiarizar o leitor com os tópicos que serão
abordados neste trabalho, o capítulo 3 refere-se a um estudo de caso abordando a modelagem
SoaML, definindo seus principais estereótipos e diagramas, aplicando este conceitos e tendo
como base o diagrama de classes e regras de negócios existentes de um projeto referente a um
posto de gasolina.
3 ESTUDO DE CASO
Este capítulo descreve superficialmente o projeto utilizado como base para aplicação
dos conceitos da modelagem UML na arquitetura orientada a serviços. Sendo o objetivo
principal demonstrar a aplicação destes conceitos envolvendo os estereótipos e diagramas
disponibilizados pela extensão SoaML.
1.5 Arquitetura do Projeto
O estudo de caso é baseado e aplicado sobre um trabalho, denominado SOS Posto,
desenvolvido durante a Pós Graduação de Engenharia de Software com UML na Unifil. No
qual se trata de um controle para postos e combustíveis, tanto abastecimento quanto
conveniência, tendo o diferencial da possibilidade de autoatendimento do cliente nas bombas
de combustível.
Para que fosse possível abranger e aplicar os conceitos propostos deste trabalho, sem
tornar muito extenso as especificações, foi definido o escopo de aplicação como sendo o
processo de venda. Por possuir dentro desse escopo vários processos relacionados, será o
suficiente para apresentação dos estereótipos e modelagem do SoaML.
Na Figura 2 é possível notar a estrutura de classes do projeto utilizado como modelo.
Figura 2: Diagrama de Classes
A arquitetura orientada a serviços disponibiliza integração dos serviços através
de inúmeras implementações de fornecimento, possibilitando o consumo a partir de
qualquer cliente que venha a consumir o serviço. A forma mais comum de
implementação da hospedagem dos serviços é utilizando Webservices, que
disponibilizam fácil acesso para qualquer tipo de consumidor através da web.
Figura 3 Acesso ao serviço de venda SOS Posto
3.1 MODELO DE PROCESSO DO NEGÓCIO (BPM)
“O termo Business Process Management (BPM) refere-se a atividades realizadas
pelas empresas para otimizar e adaptar seus processos formais - particularmente os processos
controlados por sistemas automatizados. BPM é muitas vezes mais diretamente associado
com a tecnologia e sistemas de software que implementam ampla integração e gestão de
dados de processos e informações. Ferramentas de BPM incluem processo de modelagem de
integração de dados, fluxo de trabalho de acompanhamento e controle do trabalho através da
Inteligência de Processos (PI).”( SAYER, Williams, 2012).
Os serviços devem atender o processo de negócio da empresa, alinhando os sistemas
de TI com as metas estratégicas da organização, pois a partir dele os serviços serão gerados.
A modelagem BPM obtida sobre o módulo de venda do SOS Posto está especificada
na Figura 4. De acordo com a modelagem, definisse que o processo de venda possui a venda
como fluxo principal, de qual possui o ponto inicial e final de todo o processo. A partir da
venda o restante dos processos são vinculados e contribuem no decorrer das solicitações com
o processo geral.
Figura 4Processo do Negócio - Venda
3.2 MODELO DE SERVIÇOS
3.2.1 Estrutura do Projeto
A Figura 5 apresenta, dentro do Rational Software Architect (RSA), a estrutura de
modelagem dos serviços seguida neste trabalho composta por quatro pacotes: capacidades,
interfaces, contratos, participantes e arquitetura. Além da modelagem do processo de
negócios, que servirá como base inicial para modelagem dos serviços.
Figura 5 Estrutura do Projeto
3.2.2 Capacidades
Capacidades de identificar ou especificar um conjunto unido de funções ou recursos
que um serviço prestado por um ou mais participantes podem oferecer; e podem ser utilizados
por si sós ou em conjunto com os participantes para representar geral funcionalidade ou
habilidades que um participante deve ter.
De acordo com o processo de negócios a Figura 6Figura 6 descreve os recursos que
foram identificados como necessários para o processamento de ordens de compra. São
definidos como capacidades por representarem uma abstração da capacidade para afetar
mudanças no processo.
Figura 6 Capacidades
3.2.3 Interfaces
Interfaces simples: a interface simples chama a atenção para um único meio de
interação fornecidos por um participante em uma porta representado como um UML interface.
O participante recebe operações nesta porta e pode fornecer resultados para o consumidor.
Interface do Serviço: uma abordagem baseada em ServiceInterface permite
bidirecional serviços, aqueles onde existem mensagens do provedor para o consumidor como
parte de uma conversa entre as partes. Um serviço interface é definida em termos do
fornecedor do serviço e especifica o interface que o fornecedor oferece, assim como a
interface, se houver, espera a partir do consumidor.
Nas Figura 7Figuras 7 e Figura 88 as ServicesInterfaces definem a interface e as
responsabilidades para que um participante assuma um determinado papel em um
ServiceContract. São formas de especificar como um participante irá interagir como provedor
ou consumidor na especificação do ServiceContract.
É possível notar que a capacidade declarada anteriormente é a exposição do
ServiceInterface, o qual implementa a interface respectiva do seu serviço, que possui a
declaração dos métodos utilizados no processo.
Figura 7 Interfaces - Bomba, Cliente, Produto e Tanque
Figura 8 Interface Venda
3.2.4 Contratos
Contrato de serviço define as especificações dos serviços que representam como os
fornecedores, consumidores e potencialmente outros papéis trabalharão juntos para realizar a
troca de valores, sendo a troca de valores um decreto do serviço que deve ser seguido entre as
interações entre o serviço consumidor e fornecedor. Ou seja, a abordagem do contrato de
serviço define os papéis que cada participante desempenha no serviço (como fornecedor e
consumidor) e as interfaces que implementam o desempenho do papel referenciado no
serviço. Existem três maneiras de especificar uma interação de serviço - uma interface UML,
um ServiceInterface e um ServiceContract. A Figura 9 apresenta os contratos de serviços
especificados de acordo com o fornecimento e consumo existente entre os serviços.
Figura 9 Contratos de Serviço
Especificação de uma interação:
A partir do contrato definido entre os serviços, pode ser especificado através do
diagrama de atividades ou sequência, como ocorrem as interações entre eles. Deve-se ser
representado de quem parte a requisição, e com ocorre o processo em diante até o fim da
interação.
O protocolo na Figura 10 representa como ocorre o contrato entre o serviço de venda e
bomba. A venda inicializa o processo, requisitando a realização de um serviço fornecido pela
bomba. A qual retorna o valor processado ao serviço de venda, e processa uma tarefa sobre
este valor.
Figura 10 Protocolo Venda - Bomba
O protocolo na Figura 11 representa como ocorre o contrato entre o serviço de venda e
cliente. Nesta situação a venda consome dois serviços fornecidos pelo cliente, que são
executados no cliente e processados em seguida o resultado na venda.
Figura 11 Protocolo Venda – Cliente
O protocolo na Figura 12 representa como ocorre o contrato entre o serviço de venda e
produto. A venda consome os serviços fornecidos pelo do produto em duas situações:
validação de um produto existente e validação da quantidade disponível para venda.
Figura 12 Protocolo Venda - Produto
O protocolo na Figura 13 representa como ocorre o contrato entre o serviço de venda e
tanque. A venda inicializa o processo, requisitando a realização de um serviço fornecido pelo
tanque. A qual retorna o valor processado ao serviço de venda, e processa uma tarefa sobre
este valor.
Figura 13 Protocolo Venda - Tanque
As Figura 14Figuras 14 e aFigura 15 15 apresentam interações mais complexas representadas em um diagrama de sequência, ampliando
os detalhes da especificação e mantendo melhor a organização visual sobre qual a sequência em que as interações ocorrem.
Figura 14 Protocolo Venda Automática
Figura 15 Protocolo Venda Caixa
3.2.5 Participantes
“Os participantes consumidores de serviços são entidades específicas ou tipos de
entidades que fornecem ou consomem serviços. Os participantes podem representar as
pessoas, organizações ou componentes de sistemas de informação. Os participantes podem
fornecer qualquer número de serviços e podem consumir qualquer quantidade de serviços.”
(SOAML, 2009).
Os participantes que fornecem um serviço devem ter uma capacidade de fornecer,
mas provedores diferentes podem ter capacidades diferentes de prestar o mesmo serviço -
alguns podem mesmo "terceirizar" ou delegar a execução de serviços através de uma
solicitação de serviços de outros.
Na Figura 16 os participantes: cliente, produto, tanque e bomba são representados
como participantes fornecedores. Como pode ser notado possuem apenas portas
disponibilizando serviços. Em compensação, a venda é representada como sendo um
participante consumidor e fornecedor ao mesmo tempo, por possuir uma porta fornecendo
serviço e outras quatro portas requisitando serviços disponibilizados pelos outros
participantes.
Figura 16 Participantes
3.2.6 Arquitetura
A arquitetura dos serviços representa o escopo geral da arquitetura relaciona à
operação de venda. Na Figura 17 é possível notar que a definição da arquitetura está baseada
nos ServicesInterfaces, Interfaces e Contratos de Serviço implementados anteriormente e
como eles se relacionam dentro do processo para realizar o proposito do mesmo.
No exemplo, a arquitetura do processo de venda define um ambiente onde cinco
participantes (venda, bomba, tanque, produto e cliente) estão envolvidos, para a realização do
processo. A venda consome o serviço fornecido pelos os outros quatro participantes, enquanto
ela disponibiliza através de uma porta seus serviços para um possível consumidor.
Figura 17 Arquitetura
4 CONCLUSÕES E TRABALHOS FUTUROS
A documentação é uma tarefa muito importante dentro do desenvolvimento de um
projeto. Sem a especificação do escopo e dos itens presentes no mesmo, no decorrer do
processo de desenvolvimento torna-se mais complicado em saber qual o impacto na criação
de uma nova funcionalidade ou alteração de uma existente no restante das já implementadas.
Com a abordagem proposta que foi desenvolvida neste trabalho ficou mais nítido
entender exatamente como cada processo funcionava e se relacionava com os demais. Além
de entender melhor os conceitos abrangentes da arquitetura orientada a serviços. Por exemplo,
ficou claro entender que o serviço deve atender as necessidades do processo de negócio, e
para que seja especificado de uma forma exata, o serviço possui vários estereótipos
disponibilizados pelo SoaML, que se relacionam e desta maneira se completam formando
alguns diagramas bem detalhados do processo em geral.
A forma na qual foi estruturada a arquitetura dos serviços atendeu a todas as
necessidades decorrentes do processo de negocio. Dessa forma, foi possível notar no fim do
estudo de caso, que o processo de negocio estava correto. E caso não estivesse, teria poupado
tempo de desenvolvimento, por ter mitigado ainda na etapa de analise e design um futuro erro
ou problema arquitetural gerado por uma análise inconsistente.
Sendo assim, esse trabalho apresentou como especificar, documentar e construir
artefatos UML de um sistema baseado na arquitetura orientada a serviços, demonstrando
através da aplicação desenvolvida no estudo de caso, modelos reais de como a modelagem
com SoaML é realizada.
Para trabalhos futuros, sugere-se criar uma aplicação prática de um sistema
demonstrando a implementação dos modelos documentados no estudo de caso deste trabalho.
REFERÊNCIAS
ALCHIN, Marty. Pro Python – Advanced code techiniques and tools. Apress, New York, p.
12, 2010.
ALHIR, Sinan Si. Guide to Applying the Uml. Springer , New York, 2002.
BASS, Len; Clements, Paul; Kazman, Rick. Software Architecture in Practice – Second
Edition. Addinson-Wesley, Boston, 2003.
BOOCH, Grady; Rumbaugh, James; Jacobson, Ivar, The UML Modeling Language User
Guide. Addinson-Wesley, Boston, 1999.
DEEG, Maria. Modeling Services with SoaML. Disponível em:
<http://www.mid.de/fileadmin/mid/PDF/Solution_Artikel/Modeling_Services_with_SoaML_
Article.pdf >. Acesso em 08 Fevereiro 2012.
ERL, Thomas. SOA - Princípios de design de serviços. Editora Prentice Hall, Boston, 2007.
FURLAN, José Davi. Modelagem de Objetos através da UML — the Unified Modeling
Language. São Paulo, Makron Books, 1998.
JAZAYERI ,Mehdi; Ran, Alexander; Linden, Frank van der. Software Architecture for
Product Families: Principles and Practice. Addinson-Wesley, 2000.
LAWER, James P. Service - Oriented Architecture – SOA Strategy, Methodology, and
Tecnhology. Auerbach Publications, New York, p. 12, 2008.
MELO, Ana Cristina. Desenvolvendo aplicações com UML 2.2 : do conceitual à
implementação. - 3ª ed. - Rio de Janeiro : Brasport, 2010.
Salomon, Délcio Vieira. Como Fazer Uma Monografia. São Paulo: Martins Fontes, 2004.
SAMPAIO, Cleuton. SOA e WebServices em. Brasport, Rio de Janeiro, p. 12, 2006.
SAYER, Natalie J.; Williams, Bruce. Lean For Dummies. John Wiley & Sons. Inc., New
Formatado: Inglês (EUA)
Formatado: Português (Brasil)
Formatado: Inglês (EUA)
Jersey, 2012.
SOAML. Service oriented architecture Modeling Language (SoaML) - Specification for the
UML Profile and Metamodel for Services (UPMS). Disponível em:
< http://www.omg.org/spec/SoaML/1.0/PDF/ >. Acesso em 22 Janeiros 2012.
