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