Carregar apresentação
A apresentação está carregando. Por favor, espere
1
Arquitetura Orientado a Serviços
Análise e Projeto de Sistemas – if718
2
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
3
Por que projetos de software são complicados?
4
Problemas Software é abstrato Software é complexo
Requisitos incompletos Tecnologia muda muito rápido Mudança é inevitável Problemas
5
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) Diante desse cenário, várias abordagens em engenharia de software sugiram justamente para tentar amenizar estes números: Desenvolvimento Baseado em Componentes, Linhas de Produtos de Software, Desenvolvimento Orientado a Aspectos, Arquitetura Orientada a Serviço e Desenvolvimento Dirigido a Modelos. Arquitetura orientada a Serviço e Desenvolvimento Dirigido a Modelos são abordagens que propiciam o aumento de produtividade no desenvolvimento de software, incentivando o reuso e automação da produção de artefatos, que podem variar desde modelos de requisitos e código de uma linguagem de programação. Potencialmente, a utilização em conjunto destas abordagens têm se mostrado promissoras no sentido de contribuir para processos de desenvolvimento mais eficientes, com menor custo, favorecendo maior produtividade e qualidade dos produtos de software desenvolvidos.
6
O que é Arquitetura Orientada a Serviços ?
dsdsdsa
7
SOA
8
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
9
SOA Estilo de arquitetura onde as funcionalidades de aplicações existentes são disponibilizadas na forma de serviços
10
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
11
Como Projetar Serviços?
12
SOA: Vantagens
13
Serviços são coleções de “capacidade”
Assim como pessoas, um serviço pode prover múltiplas capacidades.
14
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
15
Tipos Serviços
16
Analisar Serviços
17
Contexto <<subsystem>> Analisar Serviços Arquiteto de
Software Projetar Serviços Projetar Arquitetura Revisor de projeto Prototipar Interface gráfica Arquiteto de Informação Check List bla bla bla blabla Analisar Casos de Uso Projetar Casos de Uso Projetar Subsistemas decisões do arquiteto <<subsystem>> Analista de Sistemas Revisar Projeto Projetar classes Projetar Base de Dados Projetista de Banco de Dados
18
Visão inicial da arquitetura do sistema
Objetivos Visão inicial da arquitetura do sistema Sistemática para identificação dos serviços e componentes “Análise” diferente do RUP
19
Passo a Passo
20
Para Identificar Serviços:
abr-17 1. Empacotar Casos de Uso 2. Construir Arquitetura de Serviços 3. Identificar Serviços de Entidades 5. Revisar Resultados Analisar caso de uso
21
Para Identificar Serviços:
abr-17 1. Empacotar Casos de Uso 2. Construir Arquitetura de Serviços 3. Identificar Serviços de Entidades 5. Revisar Resultados Analisar caso de uso
22
Exemplo do QIB Analisar Serviços
23
Exemplo do QIB
24
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)
25
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.
26
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
27
Arquitetura de Serviços
Analisar Serviços A partir do Modelo de Funcionalidades pode se gerar a Arquitetura de Serviço automaticamente utilizando as seguintes regras: Contratos de serviços: os pacotes de casos de uso são mapeados em contratos de serviços. Se os casos de uso não estiverem organizados em pacotes, é necessário “empacotar” os casos semelhantes. Casos de usos que não pertencem a nenhum pacote e relacionamentos caso de uso ator são mapeados como contratos independentes. Participantes: os atores são diretamente mapeados como participantes. O próprio “sistema” dá origem a um participante independente.
28
Participants
29
Services Contracts
30
Arquitetura de Serviços
31
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
32
3. Identificar Serviços de entidades
33
Fluxo de Atividades
34
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
35
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? * Caso o diagrama fique muito complexo dividí-lo ... Fazer pelo menos 2 casos de uso por diagrama O objetivo aqui é identificar as capacidades (operações) dos serviços.
37
Mensagens de retorno
38
Fazer diagrama para o pacote Controle de Qualit Card
Exercício Fazer diagrama para o pacote Controle de Qualit Card
39
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
40
Modelo de informação atualizado
41
Fluxo de Atividades
42
Identificação de componentes
Sistemática para identificar os componentes Identificar os participants provedores Componentes “provedores” implementam os contratos de serviços Definir relacionamento entre componentes
43
Identificar Componentes
44
Analisar Serviços Análise e Projeto de Sistemas – if718
Apresentações semelhantes
© 2024 SlidePlayer.com.br Inc.
All rights reserved.