Arquitetura Orientado a Serviços
Análise e Projeto de Sistemas – if718
Objetivo
» Mostrar os principais problemas nos
processos de desenvolvimento de
software
» Apresentar os principais conceitos de
Service Oriented Architecture (SOA)
» Apresentar os passos necessários
para realizar a atividade analisar
Serviços
POR QUE PROJETOS DE
SOFTWARE SÃO COMPLICADOS?
» Software é abstrato
» Software é complexo
» Requisitos incompletos
» Tecnologia muda muito rápido
Problemas
» Mudança é inevitável
Engenharia de Software
» Desenvolvimento Baseado em
Componentes
» Desenvolvimento Orientado a
Aspectos
» Linhas de Produtos de Software
» Desenvolvimento Dirigido a Modelos
(Mode-Driven Development - MDD)
» Arquitetura Orientada a Serviços
(Service Oriented Architecture - SOA)
O QUE É ARQUITETURA ORIENTADA
A SERVIÇOS ?
SOA
SOA
Confusão com o Termo Service
Oriented Computing
“SOA é, basicamente, um modelo
de arquitetura de que beneficia a
eficiência, agilidade e
produtividade no
desenvolvimento de aplicações e
está alinhado com os objetivos de
“service oriented computing”
Thomas Erl
SOA
Estilo de arquitetura onde as
funcionalidades de aplicações existentes
são disponibilizadas na forma de serviços
O que são serviços?
» Serviço é um componente que atende a uma
função de negócio (business function). Ele
pode receber e responder requisições
ocultando os detalhes de sua
implementação.
Desacoplados em relação ao cliente/consumidor
Descritos através de contratos de operações
Como Projetar Serviços?
SOA: Vantagens
Serviços são coleções de “capacidade”
Assim como pessoas, um serviço pode prover múltiplas
capacidades.
Classificação dos Serviços
• Quando estamos modelando os serviços, fica
evidente que podemos classifica-los em função:
– Tipo de logica que encapsulam
– Potencial de Reuso
– Como a logica implementada se relaciona com o
domínio da aplicação
• Por isso, podemos classificar os serviços:
– Serviços de entidades
– Serviços de tarefas
– Serviços de utilidade
Tipos Serviços
Analisar Serviços
Contexto
Analisar
Serviços
Arquiteto de
Software
Projetar
Arquitetura
Projetar
Serviços
Revisor de
projeto
Prototipar
Interface gráfica
Arquiteto de
Informação
Analisar
Casos de Uso
Projetar
Casos de Uso
Analista de
Sistemas
Projetar
Subsistemas
<<subsystem>>
Projetar
classes
decisões do
arquiteto
Projetar
Base de Dados
Projetista de
Banco de Dados
Check
List
 bla bla
 bla
 blabla
Revisar
Projeto
Objetivos
» Visão inicial da arquitetura do
sistema
» Sistemática para identificação dos
serviços e componentes
“Análise” diferente do RUP
Passo a Passo
Para Identificar Serviços:
1. Empacotar Casos de Uso
2. Construir Arquitetura de Serviços
3. Identificar Serviços de Entidades
5. Revisar Resultados
Para Identificar Serviços:
1. Empacotar Casos de Uso
2. Construir Arquitetura de Serviços
3. Identificar Serviços de Entidades
5. Revisar Resultados
Desbloquear Talões
de Cheque
Efetuar Login
Solicitar Talões de Cheque
Alterar Senha
ClienteAtor
Consultar Saldo
Consultar Extrato
Realizar Transferência
Operadora do DOC
<<include>>
<<include>>
Realizar DOC
Analisar Serviços
Exemplo do QIB
Consultar Cheques
Consultar Qualiti Card
Efetuar Pagamento do
Qualiti Card
Operadora Cartão de
Crédito
Mostrar Dados da
Consulta
Controle de Acesso
Controle Cheque
Exemplo do QIB
Controle Conta
Realizar Transferência
ClienteAtor
Realizar Doc
Operadora Doc
Controle Qualit Card
Operadora de Cartão de Crédito
2. Construir Arquitetura de Serviços
• Arquitetura de Serviços (Service Architecture)
é gerada a partir do modelo de casos de uso
• Passo inicial para identificação dos serviços
do sistema
• SOAML (Profile UML para modelar SOA)
Arquitetura de Serviços
• Services architecture descreve como os participantes
que consomem e fornecem serviços para atender
aos requisitos do negócio.
• Participant representa uma “parte” que consomem
e/ou fornecem serviços. Podem representar pessoas,
organizações ou sistemas.
• A service contract é a especificação do acordo entre
provedores e consumidores de um serviço quanto às
informações trocadas entre participantes.
Arquitetura de Serviços
• Gerada estaticamente a partir do modelo de casos
de uso “empacotado”:
• Atores => participant
• Sistema => participant
• Pacote de casos de uso => Service Contract
• Relação na direção caso de uso – ator => Service
Contract
• Casos de uso no modelo principal=> Service
Contract
Pacote 2
UC 5
UC3
Pacote 1
UC 1
Ator 2
Ator 1
UC2
Analisar Serviços
Arquitetura de Serviços
UC 4
provide
consume
<<Participant>>
Ator1
consume
<<Service Contract>>
UC5-Ator2
<<Service Contract>>
Pacote1
<<Service Contract>>
Pacote2
<<Participant>>
Sistema
provide
consume
provide
<<Service Contract>>
UC5
consume
provide
<<Participant>>
Ator2
Participants
<<consumer>>
Cliente Front-end
Controle de Acesso
Controle Cheque
Controle Conta
<<participant>>
Sistema back-end
Realizar Transferência
ClienteAtor
Realizar Doc
Controle Qualit Card
<<participant>>
Operadora DOC
<<participant>>
Operadora Cartão
Operadora Doc
Operadora de Cartão de Crédito
Services Contracts
<<Service Contract>>
Controle de Acesso
<<Service Contract>>
Controle de Cheque
<<Service Contract>>
Controle de Conta
Controle de Acesso
Controle Cheque
Controle Conta
<<Service Contract>>
Realiazr Transferencia
Realizar Transferência
ClienteAtor
Realizar Doc
Controle Qualit Card
<<Service Contract>>
Controle Qualiti Card
<<Service Contract>>
Relizar Doc
<<Service Contract>>
Servico Operadora Doc
Operadora Doc
Operadora de Cartão de Crédito
<<Service Contract>>
Servico Operadora Cartao
Arquitetura de Serviços
<<Service Contract>>
Controle de Cheque
consumer
<<Service Contract>>
Realiazar Transferencia
consumer
consumer
<<participant>>
Operadora Cartão
provider
<<participant>>
Sistema back-end
provider
consumer
consumer
provider
comsumer
<<Service Contract>>
Controle de Acesso
<<consumer>>
Cliente Front-end
<<Service Contract>>
Servico Operadora Cartao
provider
<<Service Contract>>
Controle de Conta
provider
<<Service Contract>>
Servico Operadora Doc
provider
<<Service Contract>>
Controle Qualiti Card
<<Service Contract>>
Relizar Doc
consumer
provider
<<participant>>
Operadora DOC
3. Identificar Serviços de entidades
• Um tipo de serviço que é derivado de um
ou mais entidades de negócio relacionadas.
– São altamente reutilizável e usados por
vários serviços
• Exemplo: Serviços para fazer CRUD
3. Identificar Serviços de entidades
Conta
<<Service Contract>>
Serviço Conta
ContaintInternet
<<Service Contract>>
Serviço Conta Internet
PagamentoCartão
Comprovante
<<Service Contract>>
Serviço PagamentoCartão
Fluxo de Atividades
Interação dos Serviços
• Sistemática “semelhante” Distribuir
comportamento entre as classes
• Para cada Serviço (service contract)
– Diagrama de seqüência (coreografia dos serviços)
– Surgimento de novas entidades
• Atualizar o Modelo de Informação do negócio
Interação dos Serviços
• Levar em consideração TODOS os casos de uso
envolvidos
• Diagrama de interação único*
• Não possuem mensagens reflexivas
– Por que?
Controle de Acesso
Controle Cheque
Controle Conta
Realizar Transferência
ClienteAtor
Realizar Doc
Operadora Doc
Controle Qualit Card
Operadora de Cartão de Crédito
: Serviço Conta Internet
: Controle de Acesso
: Cliente Front-end
1 : logar(login,senha)
2 : existe(login, senha)
3 : ContaInternet
4 : sessão
Mensagens de retorno
5 : alterarSenha(login,senhaAntiga, SenhaNova)
6 : existe(login,senha)
7 : ContaInternet
8 : atualizar(ContaInternet)
9 : Conta Internet
10 : sessão
Exercício
• Fazer diagrama para o pacote Controle de
Qualit Card
Atualizar o Modelo de informação
• Atualizar atributos das entidades
• Possíveis fontes: conhecimento do negócio,
requisitos, glossário, modelo do negócio,
mensagens do modelo de interação etc.
• São propriedades/características das entidades
identificadas
– informação cujo valor é o aspecto crucial
– informação de propriedade exclusiva do objeto
• Caso seja identificada nova entidade, verificar
necessidade de criar novo serviço
• Remover entidades desnecessárias
Modelo de informação atualizado
Conta
+numero
+saldo
ContaintInternet
+login
+senha
PagamentoCartão
+numero da fatura
+data
+valor
+numero da conta
Fluxo de Atividades
Identificação de componentes
• Sistemática para identificar os componentes
1. Identificar os participants provedores
2. Componentes “provedores” implementam os
contratos de serviços
3. Definir relacionamento entre componentes
<<Service Contract>>
OperadoraCartao
<<Service Contract>>
ControleAcesso
provider
consumer
Identificar Componentes
<<participant>>
Cliente Front-end
<<Service Contractt>>
ControleConta
consumer
consumer
provider
comsumer
provider
<<participant>>
Sistema back-end
<<participant>>
Operadora Cartão
consumer
<<Service Contract>>
ControleQualitiCard
<<Service Contract>>
ContaInternet
<<Service Contract>>
ContaBancaria
<<Service Contract>>
Transação
<<Front-end>>
Cliente Front-end
IControleAcesso
IControleConta
Controle de Acesso
Controle Conta
IControleCartão
Controle Cartão
IOperadoraCartão
IContaInternet
ContaInternet
IContaBancaria
ContaBancaria
ITrasação
Trasação
OperadoraCartão
Analisar Serviços
Análise e Projeto de Sistemas – if718