Metodologiadedesenvolvimentosoa.pdf

Metodologia de Desenvolvimento SOA

Metodologia de Desenvolvimento SOA é instrumento corporativo utilizado para sistematização do desenvolvimento de soluções orientadas a serviço a fim de alcançar benefícios estratégicos da computação orientada a serviço.

Histórico de revisões Data

Versão

Descrição

Autor

Revisor

0.1

Arthur Fonseca; Charlimar Rabelo; Murilo Vidigal; Valéria Guimarães

Ricardo Puttini

0.2

Arthur Fonseca; Charlimar Rabelo; Murilo Vidigal; Valéria Guimarães

Ricardo Puttini

15/07/2016

0.3

Arthur Fonseca; Charlimar Rabelo; Murilo Vidigal; Valéria Guimarães

Ricardo Puttini

22/07/2016

0.4

Arthur Fonseca; Charlimar Rabelo; Murilo Vidigal; Valéria Guimarães

Ricardo Puttini

28/07/2016

0.5

Arthur Fonseca; Charlimar Rabelo; Murilo Vidigal; Valéria Guimarães

Ricardo Puttini

10/08/2016

0.6

Inserção de imagens de visibilidade de fase da metodologia

Arthur Fonseca; Charlimar Rabelo; Murilo Vidigal; Valéria Guimarães

Ricardo Puttini

08/09/2016

0.7

Implementação de etapas de Projeto Orientado Serviço

Arthur Fonseca; Charlimar Rabelo; Marcello Ribeiro; Murilo Vidigal; Valéria Guimarães

Ricardo Puttini

06/10/2016

0.8

Descrição das etapas de Projeto Orientado Serviço

Arthur Fonseca; Charlimar Rabelo; Marcello Ribeiro; Murilo Vidigal; Valéria Guimarães

Ricardo Puttini

07/10/2016

0.9

Revisão da Metodologia

Arthur Fonseca; Charlimar Rabelo; Marcello Ribeiro; Murilo Vidigal; Valéria Guimarães

Ricardo Puttini

Aprovação

1

SUMÁRIO 1

Objetivo .................................................................................................................................. 5

2

Apresentação ......................................................................................................................... 5

3

Visão Geral............................................................................................................................. 7

4

Perfis profissionais ............................................................................................................... 13 4.1

Analista de Processos de Negócio................................. Erro! Indicador não definido.

4.2

Analista SOA .................................................................. Erro! Indicador não definido.

4.3

Arquiteto SOA................................................................. Erro! Indicador não definido.

4.4

Desenvolvedor SOA ....................................................... Erro! Indicador não definido.

4.5

Designer de Interface de Usuário................................... Erro! Indicador não definido.

4.6

Analista de Testes .......................................................... Erro! Indicador não definido.

4.7

Especialista de Infraestrutura SOA ................................ Erro! Indicador não definido.

4.8

Administrador de Dados ................................................. Erro! Indicador não definido.

4.9

Auditor SOA .................................................................... Erro! Indicador não definido.

4.10

Especialista de Governança SOA .................................. Erro! Indicador não definido.

4.11

Gerente de Projeto ......................................................... Erro! Indicador não definido.

4.12

Analista de Processos de Negócio................................. Erro! Indicador não definido.

4.13

Analista SOA .................................................................. Erro! Indicador não definido.

4.14

Arquiteto SOA................................................................. Erro! Indicador não definido.

4.15

Desenvolvedor SOA ....................................................... Erro! Indicador não definido.

4.16

Designer de Interface de Usuário................................... Erro! Indicador não definido.

4.17

Analista de Testes .......................................................... Erro! Indicador não definido.

4.18

Especialista de Infraestrutura SOA ................................ Erro! Indicador não definido.

4.19

Administrador de Dados ................................................. Erro! Indicador não definido.

4.20

Auditor SOA .................................................................... Erro! Indicador não definido.

4.21

Especialista de Governança SOA .................................. Erro! Indicador não definido.

2

4.22

Gerente de Projeto ......................................................... Erro! Indicador não definido.

5

Estrutura funcional ............................................................................................................... 15

6

Modelagem de Negócio ....................................................................................................... 17 6.1 6.1.1

7

7.1.1 7.2 7.2.1 7.3

Analisar Inventário de Serviços ................................................................................... 37 Visibilidade do Processo de Desenvolvimento ....................................................... 62 Analisar Serviços ......................................................................................................... 63 Visibilidade do Processo de Desenvolvimento ....................................................... 78 Heurísticas para Análise Orientada a Serviço ............................................................ 79

7.3.1

Princípio da Capacidade de Composição de Serviço ............................................. 79

7.3.2

Princípio do Reuso de Serviço ................................................................................ 80

7.3.3

Padrões de Projeto para Análise Orientada a Serviço ............................................ 81

Projeto Orientado o Serviço ................................................................................................. 82 8.1.1 8.2 8.2.1 8.3

9

Visibilidade do Processo de Desenvolvimento ....................................................... 35

Análise Orientada a Serviço................................................................................................. 36 7.1

8

Modelar Negócio ......................................................................................................... 19

Visibilidade do Processo de Desenvolvimento ....................................................... 97 Projetar Arquitetura ..................................................................................................... 98 Visibilidade do Processo de Desenvolvimento ..................................................... 106 Heurísticas para Projeto Orientado a Serviço ........................................................... 107

8.3.1

Princípio de Padronização de Contrato de Serviço .............................................. 107

8.3.2

Princípio do Baixo Acoplamento ........................................................................... 108

8.3.3

Princípio da Abstração de Serviço ........................................................................ 109

8.3.4

Princípio da Visibilidade de Serviço ...................................................................... 110

8.3.5

Princípio da Autonomia de Serviço ....................................................................... 111

8.3.6

Padrões de Projeto para Projeto Orientado a Serviço .......................................... 112

Implementação ................................................................................................................... 114

3

9.1

Implementar Serviço.................................................................................................. 114

9.1.1 9.2 10

Visibilidade do Processo de Desenvolvimento ..................................................... 148 Implementar Solução................................................................................................. 149

Testes ............................................................................................................................. 160

10.1

Testar Serviço ........................................................................................................... 161

10.2

Testar Integração ...................................................................................................... 173

10.3

Teste de Aceitação .................................................................................................... 192

11

Implantação .................................................................................................................... 197

11.1

Implantar Serviço....................................................................................................... 197

11.2

Implantar Solução...................................................................................................... 203

11.2.1 12

Visibilidade do Processo de Desenvolvimento ................................................. 212

Vitalidade de Serviços .................................................................................................... 213

12.1

Exposição de Serviços do Inventário ........................................................................ 213

12.2

Gerenciar Configuração e Versionamento ................................................................ 225

12.3

Manutenção de Serviço ............................................................................................. 233

Apêndice A: Referências Bibliográficas .................................................................................... 246 Apêndice B: Glossário ............................................................................................................... 247 Apêndice C: Considerações de Gestão de Projetos SOA ............. Erro! Indicador não definido. ANEXO A: Templates ................................................................................................................ 256

4

1 OBJETIVO Estabelecer a Metodologia de desenvolvimento SOA da Core Consulting, a ser utilizada no desenvolvimento de soluções baseadas em Arquitetura Orienta a Serviços (SOA).

2 APRESENTAÇÃO Uma Metodologia é um conjunto de métodos aplicados para se realizar um determinado processo. Metodologias podem ser aplicadas nas mais diversas áreas de conhecimento, e no contexto da Metodologia de Desenvolvimento SOA (MD-SOA), trata-se de um instrumento corporativo que visa à correta definição de etapas a serem seguidas para a execução de um projeto SOA. A Metodologia de Desenvolvimento é aplicada em conjunto com outros instrumentos estruturantes da prática de software na organização. Em especial, esta metodologia encontra-se alinhada com uma Arquitetura de Referência SOA (AR-SOA) implantada e em uso na Core Consulting. A metodologia proposta leva em consideração padrões de indústria e práticas estabelecidas de desenvolvimento de software orientado a serviço. Em conjunto com a Arquitetura de Referência SOA, define-se, portanto, um conjunto de padrões corporativos de desenvolvimento, de modo a se evitar a subjetividade na abordagem e garantir os benefícios mensuráveis relacionados à qualidade das soluções orientadas a serviço. A metodologia está essencialmente organizada por processos que descrevem as atividades a serem realizadas em relação a cada uma das seguintes disciplinas de engenharia de software: Modelagem de Negócio, Análise, Projeto, Implementação, Testes e Implantação. Adicionalmente à descrição dos processos e atividades, são apresentados ainda conjuntos de heurísticas e de padrões de projeto aplicáveis como parte do processo de desenvolvimento SOA: •

•

Heurísticas: O uso de heurísticas estabelece um conjunto de considerações práticas para aplicação dos princípios de orientação a serviço que devem ser consideradas pelo analista/arquiteto ao executar tarefas em um projeto de desenvolvimento SOA. Estas heurísticas são adaptadas dos princípios de orientação a serviço, extraídos de (Erl, SOA: Principles of Service Design, 2008), (Erl, SOA Design Patterns, 2009), (Josuttis, 2007), (Portier, 2007) e (Hewitt, 2009). Padrões de Projeto: A aplicação sistemática de padrões de projeto (design patterns) de SOA resulta em melhores soluções orientadas a serviço. Recomenda-se que se desenvolva e mantenha um catálogo de padrões (design patterns catalog) com documentação acessível e regras de aplicação claramente estabelecidas. O desenvolvimento deste catálogo é igualmente indicado na Arquitetura de Referência SOA, mas sua construção não faz parte do escopo desta metodologia. Esse catálogo deverá estar sob responsabilidade e gestão do Núcleo de Governança SOA. Não obstante, alguns padrões de projeto com aplicabilidade reconhecida são apontados nas seções seguintes. Os padrões de projeto aqui elencados estão documentados em (Erl, SOA: Principles of Service Design, 2008), (Erl, SOA Design Patterns, 2009) e (SOA Patterns).

5

Esses elementos adicionais da metodologia aparecem especialmente nas atividades das disciplinas de análise e projeto com orientação a serviço. Os fluxos de processos apresentados nesse documento foram elaborados a partir da notação padrão BPMN 2.0. A MD-SOA é estruturada de modo a permitir a adoção do modelo de Fábrica de Serviço, uma adaptação do modelo de fábrica de software aplicada à terceirização da força de trabalho em processo de desenvolvimento SOA. Desse modo, espera-se que a adoção da MD-SOA favoreça maior maturidade na contratação e gestão dos contratos de Fábrica de Serviço. A metodologia proposta contém os seguintes capítulos e subcapítulos que compõem o escopo da MD-SOA: Capítulo 3: Visão Geral: Apresenta um resumo do processo geral de desenvolvimento de software com orientação a serviços, destacando as disciplinas de Engenharia de Software abordadas em cada fase do desenvolvimento. Capítulo 4: Perfis Profissionais: Indica os perfis e as capacidades dos profissionais envolvidos com os projetos de desenvolvimento de soluções SOA. Capítulo 5: Estrutura Funcional: Propõe áreas a serem instituídas na estrutura funcional de forma a garantir a plena realização dos projetos de desenvolvimento de soluções SOA. Capítulo 6: Modelagem de Negócio: Estrutura um conjunto-chave de habilidades e técnicas que possibilitam às pessoas compreender, formalizar e comunicar os principais componentes de processos de negócio. Sua principal atividade é a compreensão do processo de negócio, incluindo sua eficiência e eficácia para atendimento dos objetivos do negócio para os quais foram desenhados. Capítulo 7: Análise Orientada a Serviço: Determina quais os serviços devem ser construídos e o escopo de cada um deles, ou seja, qual a lógica deve ser encapsulada por cada um. Inclui a Análise de Inventário de Serviços, onde o desenvolvimento de serviços se dá por uma revisão constante no inventário de serviços já desenvolvidos, a fim de não criar serviços que sobrepõem o contexto funcional de outros serviços. Capítulo 8: Projeto Orientado a Serviço: esta etapa está associada ao processo formal para projetar contratos de serviço, incluindo ainda, o projeto da lógica de serviço. Uma iteração do processo de projeto orientado a serviço usualmente resulta na criação de um único contrato de serviço. Capítulo 9: Implementação de Serviço e Soluções Orientadas a Serviço: esta etapa descreve os processos “Implementar Serviço” e “Implementar de Solução”. A implementação do serviço é formatada pelas especificações do serviço e de seu projeto de lógica. Nesta etapa de implementação da solução, a camada de apresentação é realizada, bem como suas interações com as camadas de processo e de serviço, de modo a agrupar todos os componentes da solução.

Capítulo 10: Teste de Serviços e Soluções Orientadas a Serviço (em desenvolvimento) 6

Capítulo 11: Publicação e Catalogação de Serviços e Implantação de Soluções (em desenvolvimento) O presente documento traz elementos de duas áreas de conhecimento distintas que se complementam: Gestão de Processos de Negócio e Tecnologia da Informação. Nesse sentido, o Apêndice A apresenta um Glossário dos principais termos utilizados na Metodologia, com a finalidade de facilitar o entendimento dos termos e mitigar possíveis conflitos e ambiguidades de conceitos.

3 VISÃO GERAL De acordo com o CBOK1, “Processo é um conjunto de atividades interdependentes, ordenadas no tempo e no espaço de forma encadeada, que ocorrem como resposta a eventos e que possui um objetivo, início, fim, entradas e saídas bem definidas”. (ABPMP, 2015) A Figura 1 ilustra o fluxo de processos que compõem a Metodologia de Desenvolvimento SOA abordada no presente documento.

1

BPM CBOK – Guia para o Gerenciamento de Processos e Negócio – Corpo Comum de Conhecimento.

7

Figura 1 - Desenvolvimento de Soluções Orientadas a Serviço

8

O processo de desenvolvimento inicia-se pela fase de Modelagem de Negócio. Esta fase trata do entendimento da situação atual dos processos de negócio (as-is) que são objetos do desenvolvimento, seguida de análise desses processos onde se busca oportunidades de melhorias. No presente contexto do desenvolvimento de SOA, a análise busca ainda identificar no modelo de negócio quais atividades podem ser traduzidas em serviços de automação. Desse modo, o desenho de processos de negócio (to-be) é realizado com uso de princípios de SOA, especialmente no que se refere à separação de interesses e à segmentação da lógica de processo em serviços, bem como sua posterior automação. Os produtos desta fase incluem: • • • •

Modelo de Processo de Negócio: Representação projetada dos fluxos de trabalho e de informação. Modelo de Informação: Representação das estruturas de informação corporativa (entidades) envolvidas nos processos estudados. Regras de Negócio: Conjunto de regras que condicionam as decisões implícitas e explícitas no processo de trabalho. Protótipo de Telas: Desenho preliminar das interfaces de usuário, construído com objetivo de elucidar os requisitos dos processos estudados.

A fase de Análise Orientada a Serviço é dividida em dois processos que são realizados paralelamente: Analisar Inventário de Serviços e Analisar Serviço. Nesses processos, os serviços são analisados coletivamente (Análise de Inventário de Serviços) e de modo individual (Análise de Serviço). Um serviço é a unidade fundamental da lógica orientada a serviço. Uma unidade de lógica é classificada como um serviço orientação a serviço foi aplicada em uma extensão significativa. Soluções orientadas a serviço são tipicamente formadas de múltiplos serviços que formam uma composição de serviços. Esta etapa tem por objetivo a aplicação dos princípios de SOA e suas práticas e critérios de separação de interesses. Desse modo, identificam-se os serviços e as composições de serviços que fornecessem conjuntamente as capacidades computacionais requeridas na automação pretendida (candidatos a serviços). Em especial, aplicam-se padrões de projeto relacionados à separação de lógica agnóstica e lógica não agnóstica através do uso de modelos de serviço (entidade, utilitário, tarefa e processo). Os produtos desta fase são: • •

• •

Documento de Candidatos a Serviços: Descreve os serviços identificados e seu posicionamento na arquitetura de inventário de serviços. Perfil de Serviço: Apresenta a documentação detalhada de cada serviço. É um documento que acompanha o serviço em todo seu ciclo de vida. Assim, este é desenvolvido e complementado de modo incremental em cada fase. Na fase de análise, são completadas as especificações de contexto funcional e das capacidades do serviço, bem como restrições não funcionais identificadas a partir da modelagem de negócio e da análise SOA. Esse documento é construído/atualizado para cada serviço elegido para construção/adaptação, sendo de especial interesse no caso de serviços agnósticos (entidade e utilitário). Matriz de Sistemas Legados: Descreve cada serviço legado existente bem como a correlação entre cada dado e o modelo de informação proposto. Protótipo de Telas: Atualização do protótipo desenvolvido na fase anterior, tipicamente com uso de mock-ups.

9

Thomas Erl (Erl, SOA: Principles of Service Design, 2008) aponta o esforço prévio realizado na Análise como fundamental para o sucesso da implementação SOA. O maior esforço realizado nessa fase acarretará em uma melhor compreensão do negócio, trazendo resultados que alcancem maior interoperabilidade, federação, retorno do investimento, agilidade organizacional e otimização da TI. A fase de Projeto Orientado a Serviço também é dividida em dois processos que tipicamente são realizados de modo sequencial: Realizar Projeto Orientado a Serviço e Projetar Arquitetura. Serviços expressam seus propósitos e capacidades através de um contrato de serviço padronizado. A prática SOA implica em grande ênfase no projeto de contratos de serviços, e advoga o princípio de projeto “contrato primeiro”. Seu propósito é assegurar que a maneira na qual os serviços expressam funcionalidades e representam tipos de dados é mantida relativamente alinhada. O termo “projeto orientado a serviço” é utilizado nesta metodologia para descrever um processo formal de projeto de contratos de serviço. No projeto da arquitetura são especificados detalhes da arquitetura da lógica de serviço, suas composições (orquestrações) e a aplicação de padrões de projeto relacionados ao contexto arquitetural de cada serviço. São produtos desta fase: •

• • •

Contrato de Serviço: Especificação da interface técnica do serviço. Expressa meta informação sobre um serviço e estabelece os termos para seu engajamento (requisitos para invocar e interagir com o serviço). Modelo Canônico de Dados: Especificação de esquemas de dados padronizados dentro do inventário de serviços. Perfil de Serviço (atualização): Nesta etapa, atualizam-se/completam-se as informações acerca do contrato de serviço e da arquitetura da lógica de serviço. Arquitetura de Solução: Artefato opcional, utilizado para descrever adaptações da arquitetura de referência específicas para a solução (de automação) projetada.

A fase de Implementação contempla os processos Implementar Serviço e Implementar Solução, que são tipicamente executados em paralelo. Nesta metodologia esses processos consideram os princípios de análise e projeto antecipados. Desse modo, fluxos de processos, modelos de informação, contratos de serviço e arquiteturas de serviço e composições já se encontram definidas quando do início desta etapa. São produtos desta fase: •

Projeto IDE: Código fonte tipicamente escrito com uso e padrões tecnológicos da plataforma IDE.

A fase de Teste tem por objetivo verificar a qualidade do produto de software implementado, identificando defeitos e atestando o funcionamento adequado do software e de seus componentes no ambiente para o qual este foi projetado para executar. Diferentes tipos e técnicas de teste de software fazem parte desta etapa, incluindo testes unitários (Testar Serviço), de integração, de solução e de aceitação (Testar Solução). São produtos desta fase: •

•

Plano de Testes: O Plano de Testes é um documento global que contém os elementos necessários para execução de quaisquer testes gerais durante todo o ciclo de desenvolvimento SOA. Ou seja, o Plano de Teste é um documento de referência a ser utilizada na execução de quaisquer testes que envolva solução SOA. Caso de Teste: Especificação de um conjunto de condições usadas no teste de software, incluindo entradas, saídas esperadas e roteiros de testes (processo utilizado para testar o software). 10

•

•

Roteiro de Testes: O Roteiro de Testes agrega os cenários de testes a serem realizados (na forma de Casos de Testes) e que contém os elementos necessários para definição do escopo do teste específico a ser realizado Relatório de Execução de Teste: Documentação dos resultados obtidos com o teste realizado.

A fase Implantação é composta por dois processos: Publicar e Catalogar Serviço e Implantar Solução. O primeiro processo inclui a implantação do serviço propriamente dito e a coleta/atualização de metadados comunicativos que suportam a descoberta e o reuso de serviços no diretório de serviços. O segundo processo refere-se à implantação da solução (de automação), encerrando o ciclo de desenvolvimento SOA. São produtos desta fase: • • • •

Perfil de Serviço: Nesta fase são atualizadas as informações de configuração e versionamento de serviço. Implantação de Serviço: Componente de tempo de execução implantado. Configuração de Solução: Detalhamento da configuração da solução e seu versionamento. Implantação da Solução: Componente de tempo de execução implantado.

O processo de utilização de força de trabalho terceirizada deve ser suportado diretamente pela metodologia. Nesse sentido, a metodologia prevê a organização e o gerenciamento do processo com uso do modelo de fábrica de serviço. Neste modo, são utilizadas Ordens de Serviço (OS) para definir e encomendar o trabalho junto à fábrica de serviço. Para essa finalidade, são definidos três ciclos de OS dentro de um projeto de desenvolvimento SOA. Cada ciclo agrupa fases da metodologia usando um ordenamento lógico que permita a Core Consulting dividir as atividades que serão terceirizadas e as que serão realizadas pela equipe interna. São eles: • • •

OS Modelagem de Negócio e Análise: Ciclo inicial, que agrupa atividades diretamente relacionadas à análise do negócio e da solução de automação pretendida. OS Projeto e Implementação: Ciclo intermediário que agrupa atividade de natureza técnica relacionadas ao projeto, implementação e testes da solução. OS Governança e Implantação: Ciclo de transição que agrupa atividade de encerramento do desenvolvimento e início da operação (produção) das soluções desenvolvidas.

A execução da metodologia insere-se ainda no contexto de outros processos corporativos relacionados a governança, gestão de projetos, gestão de ambiente (infraestrutura), entre outros. A Figura 2 apresenta uma visão geral desses processos e suas relações com esta metodologia. Estão fora do escopo desta metodologia: • • • •

Especificação da metodologia de gestão de projetos (MGP/Escritório de Projetos). Especificação de processos associados de governança (Divisão de Governança). Especificação de processos de gestão de processos corporativos (Escritório de Processos). Especificação de processos de gestão do ambiente (Divisão de Infraestrutura).

11

Figura 2 – Processos Corporativos Relacionados com a Metodologia de Desenvolvimento SOA

12

4 PERFIS PROFISSIONAIS A metodologia não define atores (i.e. recursos humanos) específicos para realização ou gerenciamento de cada tarefa ou processo. A atribuição de recursos humanos específicos deve ser realizada projeto a projeto, como parte do planejamento, e constituição/alocação da equipe de projeto. Entretanto, a metodologia define perfis profissionais associados a tarefas, processos e subprocessos, bem como ao seu gerenciamento. Cada perfil profissional definido na metodologia está associado a um conjunto de capacidades profissionais, que indicam as competências e habilidades recomendadas e desejáveis para o profissional ao qual o perfil é atribuído. A A Tabela 1 apresenta a lista de perfis profissionais referenciados na metodologia, com suas respectivas capacidades profissionais, as quais deverão ser objeto de capacitação profissional continuada da equipe. Tabela 1 - Perfis profissionais

Perfil Profissional

Capacidade Profissional

Analista de Processos de Negócio

Gestão de Processos de Negócio (BPM) Especialista em Middleware BPM (Oracle) (desejável)

Analista SOA

Analista especializado em SOA Especialista em Middleware BPM (Oracle) (desejável)

Arquiteto SOA

Arquiteto de software especializado em SOA Especialista de Middleware SOA (Oracle)

Desenvolvedor

Desenvolvedor/Programador Especialização em desenvolvimento SOA (desejável)

Designer de Interface de Usuário

Designer de Interfaces

Analista de Testes

Analista especializado em testes Analista especializado em SOA (desejável)

Testador

Experiência em teste de software

Especialista de Infraestrutura SOA

Especialista em Middleware SOA (Oracle)

Administrador de Dados

Especialista em administração de dados

Auditor SOA

Especialista sênior em SOA Analista SOA (desejável) Arquiteto SOA (desejável)

Especialista em Governança SOA

Especialista em Governança SOA Especialista de Governança SOA (Oracle)

Gerente de Projeto

Gerência de Projetos (PMI)

13

14

5 ESTRUTURA FUNCIONAL A estrutura funcional proposta é composta por unidades funcionais que representam agrupamentos lógicos de atividades e responsabilidades dentro da Metodologia (funções). Essa estrutura não reflete, necessariamente, a estrutura organizacional formal vigente. É importante observar que as equipes de projetos normalmente serão formadas por atores que pertencem a unidades funcionais diferentes, bem como por atores ad hoc, i.e., atores que não estão relacionados a uma unidade funcional. Essa visão pretende favorecer a interoperação entre equipes de projetos diferentes e a governança da metodologia. A Figura 3 ilustra a estrutura funcional proposta.

Figura 3 - Estrutura funcional

A seguir, uma breve descrição de cada estrutura funcional sugerida: •

•

•

•

•

Gestão de Projetos de TI (Escritório de Projetos): Responsável pela metodologia de gestão de projetos e sua aplicação na área de TI. Pode conter um pool de gerentes de projetos. Gestão de Processos e Maturidade de TI (Escritório de Processos de TI): Responsável pela definição e implantação dos processos do cliente. Pode ser estendida para prover melhores práticas de gestão por processos em nível corporativo. Gestão da Informação Corporativa (Administração de Dados): Responsável pela Arquitetura de Informação corporativa, incluindo administração de dados e respectivos esquemas. Gestão de Arquitetura e Práticas de Software (Centro de Excelência SOA): compreende uma equipe focada em Arquitetura Orientada a Serviços que possui como principal função a garantia da governança e alinhamento dos projetos de desenvolvimento de soluções tecnológicas orientadas a serviço, sob uma visão corporativa. Fábrica de Serviços: responsável pela construção dos serviços e demais componentes da solução Orientada a Serviço.

15

•

•

Gestão de Infraestrutura: responsável pela disponibilização e gerenciamento de recursos de infraestrutura computacional necessários à execução das soluções tecnológicas corporativas. Gestão de Infraestrutura SOA: responsável pela disponibilização e gerenciamento de recursos de infraestrutura computacional necessários à execução das soluções Orientadas a Serviço.

16

6 MODELAGEM DE NEGÓCIO A Modelagem do Negócio consiste em um conjunto de atividades que visam compreender como a organização opera para levar valor aos seus clientes. No contexto de SOA, essa modelagem visa compreender também as oportunidades de automatização dos processos que compõem o cerne no Negócio e adaptá-lo de forma a agregar essas oportunidades ao fluxo de atividades. As atividades nesta etapa estão relacionadas com a disciplina Modelagem de Negócio (SCOTT, 2003) e utilizam os métodos e práticas preconizados no CBOK (ABPMP, 2015), cujas áreas de conhecimento são ilustradas na Figura 4. Nesta metodologia, as práticas são adaptadas ao uso de orientação a serviços, sempre que aplicável. Mais especificamente, são descritas neste documento as práticas relacionadas a: • • •

Modelagem de Processos Análise de Processos Desenho de Processos

fonte: CBOK 2.0 p.25 Figura 4 – Áreas de Conhecimento CBOK

Para o formalismo da modelagem do processo de negócio faz-se necessário seguir uma notação padrão dentre as várias existentes. A

17

Tabela 2 apresenta notações retiradas da do guia CBOK. Considerando o uso de BPMS (Oracle BPM Suite 12c), a notação BPMN 2.0 é a notação preferida.

18

Tabela 2 - Notações de modelagem de processos

Notação

Descrição

BPMN

Padrão criado pelo Object Management Group, útil para apresentar um modelo para público-alvos diferentes.

EPC

Desenvolvido como parte da estrutura de trabalho ARIS, considera eventos como “gatilhos para” ou “resultados de” uma etapa do processo; útil para modelar conjuntos complexos de processos.

UML

Mantido pelo Object Management Group, consiste em um conjunto padrão de notações técnicas de diagramação orientado à descrição de requisitos de sistemas de informação.

IDEF

Padrão da Federal Information Processing Standard dos EUA que destaca entradas, saídas, mecanismos, controles de processo e relação dos níveis de detalhe do processo superior e inferior; ponto de partida para uma visão corporativa da organização.

Value Stream Mapping

Do Lean Manufacturing, consiste em um conjunto intuitivo de símbolos usado para mostrar a eficiência de processos por meio do mapeamento de uso de recursos e elementos de tempo.

6.1 Modelar Negócio O processo Modelar Negócio é mostrado na Figura 5 e suas atividades são descritas a seguir.

Finalidade

Compreender e modelar o contexto de Negócio corporativo, apresentando modelos formais que expressam as visões atuais (as-is) e pretendidas (to-be) dos processos de negócio, as entidades e informações envolvidas e as regras de negócio.

Entradas

OS Modelagem de Negócio e Análise Documento de Visão Arquitetura de Referência

Saídas

Modelo de Processo de Negócio (as-is) (template) Modelo de Processo de Negócio (to-be) (template) Análise do Processo de Negócio (template) Modelo de Informação (template) Regras de Negócio (template) Protótipo de Telas

Perfis Participantes

R

Analista de Processos de Negócio

X

A

Analista SOA Designer de Interfaces de Usuário

C

I

X X

Gerente de Projeto

X

Auditor SOA

X

Técnicos/Usuários (Área de Negócio) Gestor (Área de Negócio)

X X

X

19

Figura 5 - Modelar Negócio

20

Coletar informações do estado atual do processo (as-is)

Finalidade

Verificar a existência de uma modelagem adequada sobre o processo a ser analisado.

Entradas

OS Modelagem Negócio e Análise

Saídas

Modelo de Processo de Negócio (Informações existentes).

Perfis Participantes

R

Analista de Processos de Negócio

X

A

C

I

Analista SOA Designer de Interfaces de Usuário Gerente de Projeto

X

Auditor SOA

X

Técnicos/Usuários (Área de Negócio) Gestor (Área de Negócio)

Descrição das Atividades

X X

X

A coleta de informações sobre o processo atual compreende a busca, nas estruturas de informações e conhecimento internos da organização, do processo a ser estudado. Ela verifica quais modelos formais a organização possui sobre o processo estudado e se estes modelos são suficientes para dar prosseguimento à análise do processo.

21

Modelar estado atual do processo

Finalidade

Elaborar um modelo do processo que represente o estado atual de execução do processo (se houver).

Entradas

Documentos, reuniões e demais insumos para descrição do processo de negócio.

Saídas

Modelagem do Processo de Negócio (as-is) (template); Informações gerais sobre o processo sob análise; Informações sobre as entradas e saídas do processo; Informações sobre os fornecedores e os clientes do processo; Informações básicas sobre as regras de negócio incidentes sobre os processos; Informações sobre os sistemas e tecnologias de informação; e O pacote de valor gerado pelo fluxo de atividades.

Perfis Participantes

R

Analista de Processos de Negócio

X

A

C

I

Analista SOA

X

Designer de Interfaces de Usuário

X

Gerente de Projeto

X

Auditor SOA

X

Técnicos/Usuários (Área de Negócio) Gestor (Área de Negócio)

X

X X

A modelagem é realizada considerando o estado atual do processo (as-is). Segundo o CBOK, “implica a representação de um determinado estado do negócio e dos respectivos recursos envolvidos, tais como pessoas, informações, instalações, automatização, finanças e insumos” (ABPMP, 2015). Indica, portanto, a representação, com maior nível possível de detalhamento, do fluxo de atividades. Descrição das Atividades

O analista de processos de negócio, responsável por essa atividade, deve focar principalmente e especialmente na representação das atividades e fluxos de trabalho, nos recursos de Tecnologia da Informação e nos indicadores de desempenho utilizados pelo processo, de forma a prover subsídios e informações adequadas às próximas atividades.

A representação de fluxo de trabalho pode ser realizada em diferentes níveis, sendo que a utilização de cada qual pode ou

22

não ser adotada de acordo com a necessidade, com o planejamento estratégico e/ou com a importância do processo no negócio da organização. São cinco níveis mais aceitos pela literatura (ABPMP, 2015): o primeiro apresenta um entendimento macro do valor do processo, percorrendo toda a organização, ponta a ponta. No segundo nível, o macroprocesso é decomposto em processos que entregam produtos importantes que compõem o valor entregue ao cliente. No terceiro nível são apresentadas as distinções das áreas funcionais e como elas se relacionam ao processo. No quarto nível, os subprocessos são divididos em atividades executadas e no quinto nível todos os detalhes são acrescentados: decomposição das atividades em tarefas, regras de negócio, legislações, entradas, saídas e outros.

23

Realizar análise no processo com foco no negócio

Finalidade

Identificar no modelo elaborado as oportunidades de melhoria e de adaptações com foco no negócio.

Entradas

Modelagem da situação presente do processo (as-is); Informações gerais sobre o processo sob análise; Informações sobre as entradas e saídas do processo; Informações sobre os fornecedores e os clientes do processo; Modelagem aprofundada das regras de negócio; Informações sobre os sistemas e tecnologias de informação; e O pacote de valor gerado pelo fluxo de atividades.

Saídas

Análise do Processo de Negócio (template).

Perfis Participantes

R

Analista de Processos de Negócio

X

Analista SOA

X

Designer de Interfaces de Usuário

X

A

C

I

Gerente de Projeto

X

Auditor SOA

X

Técnicos/Usuários (Área de Negócio) Gestor (Área de Negócio)

X X

A análise do processo modelado com foco no negócio visa trazer ao analista uma visão mais completa e profunda sobre o processo trabalhado. Ela compreende uma série de estudos que podem ser realizados de acordo com a necessidade observada pelo analista. Deve ser orientada ao tipo de transformação a ser realizada sobre o processo.

Descrição das Atividades

As boas práticas de gerenciamento de processos de negócio orientam inicialmente uma análise de alinhamento entre o processo e a estratégia da organização, de forma a se verificar se os objetivos e metas traçados com o planejamento estratégico vigente e os processos modelados são aderentes entre si. Os principais problemas de desempenho do processo podem ser identificados de várias formas, dentre elas: entrevistas com os agentes executores, pesquisas, conferências, workshops, observações diretas, simulações e/ou outros. Cada alternativa não é completa em si e deve ser escolhida de acordo com a demanda percebida. As transferências de responsabilidades na execução do processo, chamadas de hand-offs, têm um enorme potencial de 24

serem prejudiciais à eficiência do fluxo ordenado de atividades e, por isso, devem ser estudados com um cuidado especial. Naturalmente que eles estão presentes na maioria dos processos e muitos deles são necessários, porém “quanto menor for o número menor de hand-offs, menor será a sua vulnerabilidade a desconexões” (ABPMP, 2015). Análises de hand-offs costumam analisar quais são mais prováveis de atrasar o processo, se existem gargalos de informação ou serviços adicionais executados para compensá-los, se eles podem ser eliminados e quais meios existem para gerenciar o seu sequenciamento, tempo e dependências.

25

Realizar análise no processo com foco na automação

Finalidade

Identificar no modelo elaborado as oportunidades de melhoria e de adaptações com foco na automação.

Entradas

Modelagem da situação presente do processo; Informações gerais sobre o processo sob análise; Informações sobre as entradas e saídas do processo; Informações sobre os fornecedores e os clientes do processo; Modelagem aprofundada das regras de negócio; Informações sobre os sistemas e tecnologias de informação; e O pacote de valor gerado pelo fluxo de atividades.

Saídas

Análise do Processo de Negócio (template).

Perfis Participantes

R

Analista de Processos de Negócio

X

A

C

I

Analista SOA

X

X

Designer de Interfaces de Usuário

X

X

Gerente de Projeto

X

Auditor SOA

X

Técnicos/Usuários (Área de Negócio) Gestor (Área de Negócio)

Descrição das Atividades

X X

A análise do processo com foco na automação deve ser feita com o intuito de caracterizar as atividades em dois principais tipos, realização manual ou de realização automatizada. Deve buscar indicar também as características do negócio atribuídas a interfaces tecnológicas que podem ser empregadas com a intenção de tornar o processo mais eficiente e quais regras de negócio podem ser adaptadas e/ou melhoradas, principalmente com a intenção de aumentar a celeridade da sua execução. É sugerida a elaboração de um documento que identifique quais as atividades de cada tipo antes mesmo da realização do desenho do processo (to-be), como forma de garantir as boas práticas de versionamento do processo e registro da história do processo na empresa.

26

Prover informações do estado atual do processo (as-is)

Finalidade

Fornecer informações corporativas sobre o processo sob análise

Entradas

OS Modelagem Negócio e Análise

Saídas

Modelo de Processo de Negócio (existente).

Perfis Participantes

R

Analista de Processos de Negócio

A

C

X

X

I

Analista SOA

X

Designer de Interfaces de Usuário

X

Gerente de Projeto

X

Auditor SOA

X

Técnicos/Usuários (Área de Negócio)

X

Gestor (Área de Negócio)

X

Descrição das Atividades

X

X

Há situações em que o processo em análise é bem documentado e são conhecidas informações suficientes para que o desenho do processo (to-be) para automação seja bem feito. Assim, o conteúdo que pode ser fornecido pela Área de Negócios ou a Área Gestora da organização contém um conjunto de informações complementares e úteis ao Analista de Negócio.

27

Desenhar processo (to-be) para automação

Finalidade

Desenhar o processo de forma a adaptá-lo às melhorias elencadas pela análise.

Entradas

Análise do Processo de Negócio (Foco na automatização).

Saídas

Modelo de Processo de Negócio (to-be) (template).

Perfis Participantes

R

Analista de Processos de Negócio

X

A

C

I

Analista SOA

X

X

Designer de Interfaces de Usuário

X

X

Gerente de Projeto

X

Auditor SOA

X

Técnicos/Usuários (Área de Negócio) Gestor (Área de Negócio)

X X

Diversos tipos de atividades que podem ser aplicadas no momento do desenho, dependendo do contexto do processo. Há pelo menos dois tipos de abordagens: no contexto de uma iniciativa maior de gerenciamento de processos da organização; ou no contexto de um projeto de automação do processo. Esta última é tratada na presente metodologia.

Descrição das Atividades

Um processo, como fluxo ordenado de atividades, pode estar inserido na organização de forma interfuncional, isto é, percorrendo duas ou mais estruturas funcionais, caracterizando um fluxo ordenado de trabalho, executados por pessoas que compõem a cultura organizacional. Alterações nesses processos, se não realizadas com muito cuidado e observando os aspectos do gerenciamento da mudança, têm o potencial de causar verdadeiros desastres no modo operante da organização. São recomendadas revisões, simulações, profundas análises e avaliações comportamentais e outros estudos antes de efetivar as alterações propostas, de forma a se garantir sua eficiência e coerência com os demais processos. Como subsídio para as etapas seguintes do desenvolvimento de soluções orientadas a serviços, esse desenho não deve se limitar apenas a ilustração do fluxo de atividades que compõem o processo.

28

Desenhar as Regras de Negócio

Finalidade

Identificar as Regras de Negócio do Processo.

Entradas

Processo desenhado com atendimento aos requisitos solicitados pela análise; e Documentação gerada pelo processo desenhado.

Saídas

Regras de Negócio (template).

Perfis Participantes

R

Analista de Processos de Negócio

X

A

C

I

Analista SOA

X

X

Designer de Interfaces de Usuário

X

X

Gerente de Projeto

X

Auditor SOA

X

Técnicos/Usuários (Área de Negócio) Gestor (Área de Negócio)

X X

A descrição das regras de Negócio contempla a identificação dos requisitos para o desenvolvimento das atividades de forma a atender as expectativas do cliente do processo. Tal identificação compreende, para cada atividade, QUEM é o seu responsável, COMO, ONDE, QUANDO e PORQUE ela deve ser realizada. Descrição das Atividades

Uma vez que as Regras de Negócio resultantes dessa atividade serão utilizadas por todo o processo, é importante focar em algumas boas práticas na sua elaboração, principalmente no que diz respeito à sua simplicidade. Com o tempo, a maturidade da empresa no gerenciamento das Regras de Negócio tende a aumentar e, então, serão criados padrões de codificação e identificação das regras, separação por tipos e outros conceitos que ajudarão na sua elaboração e manutenção.

29

Desenhar estrutura da informação

Finalidade

Identificar o modelo de estrutura da informação do processo.

Entradas

Modelo do Processo de Negócio (to-be); e Regras de Negócio.

Saídas

Estrutura da informação (template).

Perfis Participantes

R

Analista de Processos de Negócio

X

A

C

I

Analista SOA

X

X

Designer de Interfaces de Usuário

X

X

Gerente de Projeto

X

Auditor SOA

X

Técnicos/Usuários (Área de Negócio) Gestor (Área de Negócio)

X X

A estrutura de informação do processo deve contemplar, de forma clara e concisa, a estrutura de dados e informações que são transferidas entre as diferentes atividades do processo pelos serviços a serem projetados e implementados.

Descrição das Atividades

Seu desenvolvedor deve ter em mente que essa estrutura de informações gerada será a base para todo o desenvolvimento SOA que acontecerá nas etapas seguintes. Por isso, ela deve ser capaz de informar de maneira prática e clara quais os níveis de informações e o grau de parentesco entre elas. Não é escopo desse documento a prescrição de práticas, porém, convém apresentar (por meio dos templates) tipos de estruturas de informação adequadas, com base na experiência e no conhecimento das melhores práticas da equipe autora dessa metodologia.

30

Elaborar protótipos de telas

Finalidade

Elaborar interfaces gráficas que serão utilizadas para a compreensão da usabilidade do processo automatizado pelo usuário final.

Entradas

Processo desenhado; Documentação gerada pelo processo desenhado; Regras de Negócio adaptadas; e Modelo de estrutura da informação.

Saídas

Telas de prototipação de interface.

Perfis Participantes

R

A

C

Analista de Processos de Negócio

X

Analista SOA

X

Designer de Interfaces de Usuário

I X

X

Gerente de Projeto

X

Auditor SOA

X

Técnicos/Usuários (Área de Negócio) Gestor (Área de Negócio)

Descrição das Atividades

X X

A elaboração dos protótipos de telas no desenvolvimento SOA, diferentemente de outras metodologias, não é realizada exclusivamente nas etapas de desenvolvimento. Ela é uma visão prévia da aplicação a ser desenvolvida, sendo ainda realizadas possíveis alterações futuras durante os processos da disciplina de Análise subsequentes, quando a concepção de serviços candidatos a comporem a solução já estará mais consolidada. Esta primeira prototipação deve ser realizada alinhando-se as expectativas do cliente, sendo o resultado final exposto através de telas que expressem a concepção inicial das interfaces, bem como o seu fluxo de navegação e interações entre as mesmas.

31

Prover informações sobre o processo desejado

Finalidade

Suportar o Analista de Negócios sobre o processo trabalhado para que o desenho do processo para automação seja bem sucedido.

Entradas

Processo desenhado; Documentação gerada pelo processo desenhado; Regras de Negócio adaptadas; e Modelo de estrutura da informação.

Saídas

Informações providas e eventuais dúvidas sanadas.

Perfis Participantes

R

Analista de Processos de Negócio

A

C

X

X

I

Analista SOA

X

X

Designer de Interfaces de Usuário

X

X

Gerente de Projeto

X

Auditor SOA

X

Técnicos/Usuários (Área de Negócio)

X

Gestor (Área de Negócio)

X

Descrição das Atividades

X

Durante o desenho do processo (to-be) para automação, das Regras de Negócio e da Estrutura da Informação, é possível que o Analista de Negócio tenha algumas dúvidas residuais sobre o processo trabalhado e analisado. A Área de Negócio pode vir a ser solicitada para esclarecer tais eventuais dúvidas, de forma que a eficiência do processo desenhado seja maximizada.

32

Apoiar análise, modelagem e desenho do Negócio com orientação a serviço

Finalidade

Auxiliar o Analista de Negócio no momento do Desenho do processo para automação.

Entradas

Processo desenhado; Documentação gerada pelo processo desenhado; Regras de Negócio adaptadas; e Modelo de estrutura da informação.

Saídas

Processo desenhado com maior orientação a serviço

Perfis Participantes

R

Analista de Processos de Negócio Analista SOA

A

C

X

X

I

X

Designer de Interfaces de Usuário

X

Gerente de Projeto

X X

Auditor SOA

X

X

Técnicos/Usuários (Área de Negócio)

X

X

Gestor (Área de Negócio)

X

X

Descrição das Atividades

O apoio dado pelo Analista SOA ajuda o Analista de Negócio a identificar os Serviços de Tarefa, de Entidade e Utilitários presentes no processo com maior eficácia. Dessa forma, quando do momento da Análise do Inventário de Serviços e da Análise Orientada a Serviços, o trabalho será mais facilmente realizável.

33

Aprovar modelo

Finalidade

Analisar o modelo de estrutura da informação gerado para validar a sua aderência ao processo e ao negócio modelados.

Entradas

Processo desenhado; Documentação gerada pelo processo desenhado; Regras de Negócio adaptadas; e Modelo de estrutura da informação.

Saídas

Produtos validados

Perfis Participantes

R

Analista de Processos de Negócio

A

C

X

X

I

Analista SOA

X

X

Designer de Interfaces de Usuário

X

X

Gerente de Projeto

X

Auditor SOA

X

Técnicos/Usuários (Área de Negócio)

X

Gestor (Área de Negócio)

X

Descrição das Atividades

A validação dos produtos compreende a aceitação de todos os produtos gerados pelas atividades do processo com os colaboradores da organização que estão envolvidos com a área de negócio onde o processo analisado percorre. Dessa forma, a área de negócio garante que o processo desenhado para automação, as regras de Negócio, o Modelo de informação e os protótipos de tela estão alinhados com as atividades por ela desenvolvidas

34

6.1.1 Visibilidade do Processo de Desenvolvimento A Figura 6 apresenta a visão dos artefatos de entrada e saída para esta etapa da metodologia SOA.

Figura 6 - Entradas e Saídas do processo Modelar Negócio

35

7 ANÁLISE ORIENTADA A SERVIÇO A Análise Orientada a Serviço consiste em um conjunto de atividades que visam compreender como os serviços a serem desenvolvidos irão interagir entre si com o intuito de solucionar o cenário proposto pela Modelagem do Negócio. Esta etapa será responsável pela identificação e especificação funcional de serviços. Para tanto, é utilizada a separação de interesses orientada a serviços, tipicamente pela separação de lógica agnóstica (serviços agnósticos) e de lógica não agnóstica. O uso da arquitetura de camadas do inventário e de modelos de serviço consiste em parte fundamental deste processo de abstração. Como descrito na Arquitetura de Referência SOA (AR-SOA), serviços de lógica agnóstica podem seguir dois processos de abstração: Utilitária e de Entidade; enquanto serviços de lógica não agnóstica seguem abstrações relacionadas a orquestração (composição) de serviços: Tarefa e Processo. A descrição de cada modelo de serviço é apresentada a seguir: •

•

•

•

Serviços Utilitários: são serviços que proveem funcionalidades que endereçam interesses múltiplos, enquanto mantém um escopo funcional não inerente ao negócio. Frequentemente, encapsularem recursos corporativos, tais como sistemas legados e base de dados, e os expõem em contexto único. Serviços de Entidade: são serviços relacionados a entidades de negócio. Ainda que uma capacidade de serviço de entidade possa encapsular um processo ou tarefa de negócio, seu escopo é limitado a sua associação com a entidade de negócio definidas na Modelagem de Negócio. São serviços de fácil identificação por representarem as entidades de negócio, bem como estarem associados a capacidades de criação, recuperação, atualização e remoção de informações (CRUD) inerentes à entidade. Serviços de Tarefa: são serviços que representam a lógica de processos de negócio que envolve a composição de serviços. Tais serviços são, por natureza, não agnósticos e de propósito único, agrupando lógicas agnósticas, porém em um contexto específico, possuindo, portanto, potencial de reuso limitado ou inexistente. Tipicamente, serviços de tarefa não possuem lógica interativa (lógica de usuário). Serviços de Processo: são serviços muito semelhantes aos Serviços de Tarefa, possuindo como diferença composições mais complexas e que executam em maior quantidade de tempo. Tipicamente, serviços de processo possuem lógica interativa.

Uma característica fundamental dos projetos de desenvolvimento de soluções SOA consiste na ênfase dada à necessidade de aumentar o esforço da análise antecipada. No contexto de SOA, essa análise pode ser dividida em dois processos: Analisar Inventário de Serviços e Analisar Serviço. O processo Analisar Inventário de Serviços consiste em uma análise mais ampla do processo, sendo responsável pela decomposição da lógica de solução em serviços. Neste processo, serviços são identificados usando os modelos de serviços definidos o que resulta em uma coleção de candidatos a serviço agnósticos e na definição preliminar de composições de serviços. Como resultado, o próprio modelo de processo estabelecido na Modelagem de Negócio é enriquecido e, eventualmente, aprimorado para contemplar a divisão de serviços pretendida. Nesse sentido, o processo engloba ainda um aprimoramento da concepção dos protótipos de UI e com análise de sistemas adjacentes (legado). A análise de serviços é feita considerando os serviços coletivamente, inclusive com exploração do inventário de serviços existente para

36

descoberta de serviços e definição de reuso e evolução de serviços previamente disponibilizados. O processo Analisar Serviços consiste em uma análise específica sobre cada serviço a ser desenvolvido, sendo responsável pela definição e detalhamento de candidatos a capacidades de serviço, suas respectivas mensagens (estrutura), bem como requisitos não funcionais. Este processo é executado para cada serviço individualmente, de modo a observar com maior atenção composições e dependências entre serviços. Neste processo são gerados/atualizados documentos de perfil para cada serviço proposto, bem como uma matriz de sistemas legados (mapeamento entre modelos canônicos e modelos utilizados nos sistemas adjacentes (legado) e sua lógica de transformação).

7.1 Analisar Inventário de Serviços O processo Analisar Inventário de Serviços é apresentado na Figura 7 e suas atividades são descritas a seguir.

Finalidade

Aplicar princípios de orientação a serviço para decompor a lógica de negócio e identificar serviços candidatos. Modelar de modo preliminar os serviços candidatos e composições identificadas.

Entradas

OS Modelagem de Negócio e Análise Modelo de Processo de Negócio (as-is) (template) Modelo de Processo de Negócio (to-be) (template) Análise do Processo de Negócio (template) Modelo de Informação (template) Regras de Negócio (template) Protótipo de Telas Arquitetura de Informação Corporativa Arquitetura de Dados Corporativa Arquitetura de Sistema Adjacente Arquitetura de Referência

Saídas

Modelo de dados (físico) Modelo de integração Protótipo de Telas (atualização) Documento de Candidatos a Serviço (template)

Perfis Participantes

R

A

Administrador de Dados Analista de Processos de Negócio Analista SOA Arquiteto SOA

C

I

X

X

X

X

X X

Auditor SOA Design de Interfaces Gerente de Projeto

X X X

37

Figura 7 – Analisar Inventário de Serviços

38

Revisar Modelos de Processo, Informação e Regras de Negócio

Finalidade

Revisão dos modelos de processo e demais documentos que expressem

Entradas

Modelo de Processo de Negócio (as-is) (template) Modelo de Processo de Negócio (to-be) (template) Análise do Processo de Negócio (template) Modelo de Informação (template) Regras de Negócio (template) Protótipo de Telas

Saídas

Processo revisado

Perfis Participantes

R

A

Administrador de Dados Analista de Processos de Negócio Analista SOA

C

I

X

X

X

X

X X

Arquiteto SOA Arquiteto de Software

X

Auditor SOA

X

Gerente de Projeto

X

Área de Negócio / Área Gestora

X

Descrição das Atividades

Muitos dos serviços a serem modelados e projetados serão serviços diretamente ligados aos processos finalísticos da organização, responsáveis por encapsular e expressar lógicas de negócio de forma precisa. Portanto, um dos fatores essenciais para o sucesso desta etapa é a revisão e dos processos de negócio e suas especificações elencados até o momento.

39

Analisar Sistemas Existentes

Finalidade

Identificar sistemas adjacentes legados que interagem de alguma forma como negócio mapeado

Entradas

Modelo de Processo de Negócio (as-is) (template) Modelo de Processo de Negócio (to-be) (template) Análise do Processo de Negócio (template) Modelo de Informação (template) Regras de Negócio (template) Protótipo de Telas

Saídas

Definição de Sistemas Existentes

Perfis Participantes

R

A

Administrador de Dados Analista de Processos de Negócio Analista SOA

C

I

X

X

X

X

X X

Arquiteto SOA Arquiteto de Software

X

Auditor SOA

X

Gerente de Projeto

X

Área de Negócio / Área Gestora

X

Descrição das Atividades

A avaliação dos sistemas legados desenvolvidos visa a detecção de soluções já desenvolvidas para reaproveitamento, favorecendo o retorno do investimento e evitando o descarte total e criação de novas soluções, tal como ocorre em outras abordagens.

40

Analisar Tarefas Humanas e Automáticas

Finalidade

Filtrar tarefas a serem analisadas como candidatas a serviço

Entradas

Modelo de Processo de Negócio (as-is) (template) Modelo de Processo de Negócio (to-be) (template) Análise do Processo de Negócio (template) Modelo de Informação (template) Regras de Negócio (template) Protótipo de Telas Definição de Sistemas Existentes

Saídas

Definição de Tarefas Humanas e Automáticas

Perfis Participantes

R

A

Administrador de Dados Analista de Processos de Negócio Analista SOA

C

I

X

X

X

X

X X

Arquiteto SOA Arquiteto de Software

X

Auditor SOA

X

Gerente de Projeto

X

Área de Negócio / Área Gestora

X

Descrição das Atividades

Dentro de um processo de negócio, algumas tarefas podem ser facilmente identificadas como não pertencentes à lógica que deve ser encapsulada em um candidato a serviço, como por exemplo, tarefas manuais do processo que não podem ou não devem ser automatizadas ou tarefas de processos executadas por lógica legada existente para o qual o encapsulamento por um serviço não é uma opção. A separação desses contextos auxilia na separação de tarefas a serem executadas via serviço e tarefas que não devem ser automatizadas.

41

Decompor Processos de Negócio

Finalidade

Decomposição de processo em menor nível de granularidade a fim de facilitar compreensão de composições e reusabilidade de capacidades

Entradas

Modelo de Processo de Negócio (as-is) (template) Modelo de Processo de Negócio (to-be) (template) Análise do Processo de Negócio (template) Modelo de Informação (template) Regras de Negócio (template) Protótipo de Telas Definição de Sistemas Existentes Definição de Tarefas Humanas e Automáticas

Saídas

Processo Decomposto

Perfis Participantes

R

A

Administrador de Dados Analista de Processos de Negócio Analista SOA

C

I

X

X

X

X

X X

Arquiteto SOA Arquiteto de Software

X

Auditor SOA

X

Gerente de Projeto

X

Área de Negócio / Área Gestora

X

Descrição das Atividades

Nesta atividade o processo de negócio documentado é decomposto em uma série de passos elementares. É importante que o fluxo de trabalho seja decomposto no menor nível de granularidade possível, frequentemente diferente dos níveis no qual os passos de processo são inicialmente documentados. Com isso, composições de serviços se tornarão mais claramente perceptíveis, e os benefícios de reusabilidade ficará em maior evidencia.

42

Identificar Candidatos a Serviço de Negócio - Entidades

Finalidade

Definir os candidatos a Serviço de Entidade

Entradas

Modelo de Processo de Negócio (as-is) (template) Modelo de Processo de Negócio (to-be) (template) Análise do Processo de Negócio (template) Modelo de Informação (template) Regras de Negócio (template) Protótipo de Telas Definição de Sistemas Existentes Definição de Tarefas Humanas e Automáticas Processo Decomposto

Saídas

Candidatos a Serviços de Entidade

Perfis Participantes

R

A

Administrador de Dados Analista de Processos de Negócio Analista SOA

C

I

X

X

X

X

X X

Arquiteto SOA Arquiteto de Software

X

Auditor SOA

X

Gerente de Projeto

X

Área de Negócio / Área Gestora

X

Descrição das Atividades

Neta etapa são identificados serviços centralizados nas entidades de negócio e com grande potencial de reuso, para tanto uma análise do Modelo de Processo de Negócio (to-be) deve ser realizada, tendo-se em vista as próprias entidades existentes. Estes serviços possuem contexto derivado de uma entidade de negócio específica (ex. Magistrado, Vara) ou de um grupo de entidades de negócio relacionadas

43

Analisar Inventário de Serviços e identificar oportunidades de reuso

Finalidade

Identificar os serviços existentes que podem ser utilizados de acordo com os candidatos propostos

Entradas

Modelo de Processo de Negócio (as-is) (template) Modelo de Processo de Negócio (to-be) (template) Análise do Processo de Negócio (template) Modelo de Informação (template) Regras de Negócio (template) Protótipo de Telas Definição de Sistemas Existentes Definição de Tarefas Humanas e Automáticas Processo Decomposto Candidatos a Serviços de Entidade

Saídas

Serviços com capacidade de reuso identificados.

Perfis Participantes

R

A

Administrador de Dados Analista de Processos de Negócio Analista SOA

C

I

X

X

X

X

X X

Arquiteto SOA Arquiteto de Software

X

Auditor SOA

X

Gerente de Projeto

X

Área de Negócio / Área Gestora

X

Descrição das Atividades

Esta análise verifica o Inventário de Serviços existente para identificar Serviços já construídos que possam ser aproveitados como Serviços de Entidade.

44

Identificar Candidatos a Serviço Utilitário

Finalidade

Definir os candidatos a Serviço Utilitário

Entradas

Modelo de Processo de Negócio (as-is) (template) Modelo de Processo de Negócio (to-be) (template) Análise do Processo de Negócio (template) Modelo de Informação (template) Regras de Negócio (template) Protótipo de Telas Definição de Sistemas Existentes Definição de Tarefas Humanas e Automáticas Processo Decomposto Candidatos a Serviços de Entidade

Saídas

Candidatos a Serviços Utilitários

Perfis Participantes

R

A

Administrador de Dados Analista de Processos de Negócio Analista SOA

C

I

X

X

X

X

X X

Arquiteto SOA Arquiteto de Software

X

Auditor SOA

X

Gerente de Projeto

X

Área de Negócio / Área Gestora

X

Descrição das Atividades

Nesta etapa são identificados serviços de funcionalidade com interesses múltiplos, e, portanto, com grande potencial de reuso. Frequentemente, estes serviços encapsulam recursos corporativos, tais como sistemas legados e bases de dados e os expõem em contextos únicos. É comum a definição constante de mais serviços utilitários a medida que a análise é refinada, sendo a granularidade escolhida um dos grandes desafios desta atividade.

45

Identificar Candidatos a Serviço de Negócio - Tarefa

Finalidade

Definir os candidatos a Serviço de Tarefa

Entradas

Modelo de Processo de Negócio (as-is) (template) Modelo de Processo de Negócio (to-be) (template) Análise do Processo de Negócio (template) Modelo de Informação (template) Regras de Negócio (template) Protótipo de Telas Definição de Sistemas Existentes Definição de Tarefas Humanas e Automáticas Processo Decomposto Candidatos a Serviços de Entidade Candidatos a Serviços Utilitários

Saídas

Candidatos a Serviços de Tarefa

Perfis Participantes

R

A

Administrador de Dados Analista de Processos de Negócio Analista SOA

C

I

X

X

X

X

X X

Arquiteto SOA Arquiteto de Software

X

Auditor SOA

X

Gerente de Projeto

X

Área de Negócio / Área Gestora

X

Descrição das Atividades

Identificar serviços que encapsulam a lógica de negócio específica de uma tarefa de negócio, frequentemente relacionada a atividades de processo.

46

Identificar Composições de Serviço

Finalidade

Especificação de composições de serviços

Entradas

Modelo de Processo de Negócio (as-is) (template) Modelo de Processo de Negócio (to-be) (template) Análise do Processo de Negócio (template) Modelo de Informação (template) Regras de Negócio (template) Protótipo de Telas Definição de Sistemas Existentes Definição de Tarefas Humanas e Automáticas Processo Decomposto Candidatos a Serviços de Entidade Candidatos a Serviços Utilitários Candidatos a Serviços de Tarefa

Saídas

Composições de Serviço

Perfis Participantes

R

A

Administrador de Dados Analista de Processos de Negócio Analista SOA

C

I

X

X

X

X

X X

Arquiteto SOA Arquiteto de Software

X

Auditor SOA

X

Gerente de Projeto

X

Área de Negócio / Área Gestora

X

Descrição das Atividades

Nessa tarefa, são identificados os cenários mais comuns no contexto do processo e quais as etapas para a conclusão desses. É necessário garantir que esses cenários contemplem todas as condições possíveis. As composições a serem detalhadas posteriormente devem seguir os princípios de separação de camadas de serviço, facilitando o entendimento do papel de serviços agnósticos e não agnósticos na solução proposta.

47

Analisar Requisitos não Funcionais

Finalidade

Análise prévia de termos de desempenho, usabilidade, confiabilidade, segurança, disponibilidade, manutenção e tecnologias envolvidas da solução.

Entradas

Modelo de Processo de Negócio (as-is) (template) Modelo de Processo de Negócio (to-be) (template) Análise do Processo de Negócio (template) Modelo de Informação (template) Regras de Negócio (template) Protótipo de Telas Definição de Sistemas Existentes Definição de Tarefas Humanas e Automáticas Processo Decomposto Candidatos a Serviços de Entidade Candidatos a Serviços Utilitários Candidatos a Serviços de Tarefa Candidatos a Composições de Serviço

Saídas

Requisitos não Funcionais dos Candidatos a Serviços

Perfis Participantes

R

A

Administrador de Dados Analista de Processos de Negócio Analista SOA

C

I

X

X

X

X

X X

Arquiteto SOA Arquiteto de Software

X

Auditor SOA

X

Gerente de Projeto

X

Área de Negócio / Área Gestora

X

Descrição das Atividades

Nessa tarefa, o foco está no estudo dos requisitos de processamento subjacentes de cada capacidade de serviço. Isso pode revelar a necessidade por candidatos a capacidades adicionais de serviço não ligados diretamente ao negócio.

48

Aplicar Princípios e Patterns

Finalidade

Revisão de candidatos a serviços identificados a fim de se aplicar princípios e patterns SOA

Entradas

Modelo de Processo de Negócio (as-is) (template) Modelo de Processo de Negócio (to-be) (template) Análise do Processo de Negócio (template) Modelo de Informação (template) Regras de Negócio (template) Protótipo de Telas Definição de Sistemas Existentes Definição de Tarefas Humanas e Automáticas Processo Decomposto Candidatos a Serviços de Entidade Candidatos a Serviços Utilitários Candidatos a Serviços de Tarefa Candidatos a Composições de Serviço Requisitos não Funcionais dos Candidatos a Serviços

Saídas

Revisão de Candidatos a Serviço

Perfis Participantes

R

A

C

I

Administrador de Dados

X

Analista de Processos de Negócio

X

Analista SOA

X

Arquiteto SOA

X

Arquiteto de Software

X

Auditor SOA

X

Gerente de Projeto

X

Área de Negócio / Área Gestora

X

Descrição das Atividades

Os princípios de SOA que têm significância especial, durante a modelagem de serviços, são os de Capacidade de Reuso de Serviço e de Autonomia de Serviço: - Considerações de reuso ajudam a tornar os passos dentro de contextos agnósticos em ações mais genéricas. - Considerações de autonomia relacionam-se com os sistemas legados afetados, identificados anteriormente. - Visibilidade de Serviço (capacidade de descoberta) também é levada em consideração para propósitos de meta anotação.

49

Revisar Composições e Candidatos a Serviços

Finalidade

Revisão de composições e candidatos a serviço a fim de se verificar a necessidade de nível de granularidade

Entradas

Modelo de Processo de Negócio (as-is) (template) Modelo de Processo de Negócio (to-be) (template) Análise do Processo de Negócio (template) Modelo de Informação (template) Regras de Negócio (template) Protótipo de Telas Definição de Sistemas Existentes Definição de Tarefas Humanas e Automáticas Processo Decomposto Candidatos a Serviços de Entidade Candidatos a Serviços Utilitários Candidatos a Serviços de Tarefa Candidatos a Composições de Serviço Requisitos não Funcionais dos Candidatos a Serviços

Saídas

Candidatos a Composições de Serviço

Perfis Participantes

R

A

Administrador de Dados Analista de Processos de Negócio Analista SOA

C

I

X

X

X

X

X X

Arquiteto SOA Arquiteto de Software

X

Auditor SOA

X

Gerente de Projeto

X

Área de Negócio / Área Gestora

X

Descrição das Atividades

Os cenários originais que foram identificados na Tarefa “Identificar Composições de Serviço” são revisitados. Desta vez, entretanto, são incorporados também os novos candidatos a serviços utilitários. Isso pode resultar no mapeamento de novas atividades de serviços a serem elaboradas. Deve-se manter o histórico de como candidatos a serviços de negócio relacionamse com candidatos a serviços utilitários subjacentes durante este exercício.

50

Revisar Candidatos a Capacidade de Serviço

Finalidade

Revisão de capacidades a serviço a fim de se verificar a necessidade de refinamento de análise

Entradas

Modelo de Processo de Negócio (as-is) (template) Modelo de Processo de Negócio (to-be) (template) Análise do Processo de Negócio (template) Modelo de Informação (template) Regras de Negócio (template) Protótipo de Telas Definição de Sistemas Existentes Definição de Tarefas Humanas e Automáticas Processo Decomposto Candidatos a Serviços de Entidade Candidatos a Serviços Utilitários Candidatos a Serviços de Tarefa Composições de Serviços Requisitos não Funcionais dos Candidatos a Serviços

Saídas

Revisão de Candidatos a Serviço

Perfis Participantes

R

A

C

Administrador de Dados

I X

Analista de Processos de Negócio Analista SOA

X

X

X

X

X

X

Arquiteto SOA Arquiteto de Software

X

Auditor SOA

X

Gerente de Projeto

X

Área de Negócio / Área Gestora

Descrição das Atividades

X

X

Nesta etapa são revisadas as capacidades elencadas anteriormente, tomando-se o cenário proposto, sendo reavaliada a necessidade de novas composições e decomposições. É um processo interativo, e que deve ser aprimorado visando a granularidade desejada.

51

Atualizar Modelo de Processo de Negócio e Documento de Candidatos a Serviços

Finalidade

Atualização de Modelo de Processo de Negócio quando novas considerações frente à decomposição de serviços

Entradas

Modelo de Processo de Negócio (as-is) (template) Modelo de Processo de Negócio (to-be) (template) Análise do Processo de Negócio (template) Modelo de Informação (template) Regras de Negócio (template) Protótipo de Telas Definição de Sistemas Existentes Definição de Tarefas Humanas e Automáticas Processo Decomposto Candidatos a Serviços de Entidade Candidatos a Serviços Utilitários Candidatos a Serviços de Tarefa Composições de Serviços Requisitos não Funcionais dos Candidatos a Serviços

Saídas

Modelo de Processo de Negócio (atualizado) Documento de Candidatos a Serviço

Perfis Participantes

R

A

Administrador de Dados Analista de Processos de Negócio Analista SOA

C

I

X

X

X

X

X X

Arquiteto SOA Arquiteto de Software

X

Auditor SOA

X

Gerente de Projeto

X

Área de Negócio / Área Gestora

X

Descrição das Atividades

O mapeamento dos cenários oriundos das etapas anteriores poderá acarretar em novas considerações na solução, o que poderá gerar a necessidade de refinar e alterar o agrupamento ou a definição dos candidatos a capacidades de serviço que foram previamente definidos. Essas novas considerações devem ser alinhadas com o Modelo de Processo de Negócio definido anteriormente

52

Apoiar Análise

Finalidade

Auxiliar o Analista SOA a manter o foco no negócio do processo trabalhado

Entradas

Modelo de Processo de Negócio (as-is) (template) Modelo de Processo de Negócio (to-be) (template) Análise do Processo de Negócio (template) Modelo de Informação (template) Regras de Negócio (template) Protótipo de Telas Definição de Sistemas Existentes Definição de Tarefas Humanas e Automáticas Processo Decomposto Candidatos a Serviços de Entidade Candidatos a Serviços Utilitários Candidatos a Serviços de Tarefa Composições de Serviços Requisitos não Funcionais dos Candidatos a Serviços

Saídas

Modelo de Processo de Negócio (atualizado) Documento de Candidatos a Serviço

Perfis Participantes

R

A

Administrador de Dados Analista de Processos de Negócio Analista SOA

I

X

X

X X

Arquiteto SOA

C

X X

X

Arquiteto de Software

X

Auditor SOA

X

Gerente de Projeto

X

Área de Negócio / Área Gestora

X

Descrição das Atividades

Garantir que as análises realizadas pelo Analista SOA não percam o alinhamento com o negócio. Isso implica acompanhar e estar ciente da Análise realizada sobre o inventário de Serviços, da identificação dos Serviços candidatos e garantir o alinhamento dessas atividades ao negócio.

53

Fornecer informações adicionais

Finalidade

Apoiar os Analistas SOA e de Processos de Negócio fornecendo eventuais informações que possam não ter sido coletadas previamente.

Entradas

Modelo de Processo de Negócio (as-is) (template) Modelo de Processo de Negócio (to-be) (template) Análise do Processo de Negócio (template) Modelo de Informação (template) Regras de Negócio (template) Protótipo de Telas Definição de Sistemas Existentes Definição de Tarefas Humanas e Automáticas Processo Decomposto Candidatos a Serviços de Entidade Candidatos a Serviços Utilitários Candidatos a Serviços de Tarefa Composições de Serviços Requisitos não Funcionais dos Candidatos a Serviços

Saídas

Modelo de Processo de Negócio (atualizado) Documento de Candidatos a Serviço

Perfis Participantes

R

C

I

Administrador de Dados

X

X

Analista de Processos de Negócio

X

X

X

X

X

X

Analista SOA

A

X

Arquiteto SOA Arquiteto de Software

X

Auditor SOA

X

Gerente de Projeto

X

Área de Negócio / Área Gestora Descrição das Atividades

X

Fornecer informações complementares às coletadas durante a Modelagem de Negócio de forma que os Analistas SOA e de Negócio possam realizar uma Análise Orientada a Serviço mais completa e abrangente.

54

Aplicar Considerações de Administração de Dados

Finalidade

Avaliar base de dados e considerações quanto a sua interação com as definições existente e definições necessárias para o funcionamento da solução proposta

Entradas

Modelo de Processo de Negócio (as-is) (template) Modelo de Processo de Negócio (to-be) (template) Análise do Processo de Negócio (template) Modelo de Informação (template) Regras de Negócio (template) Protótipo de Telas Definição de Sistemas Existentes Definição de Tarefas Humanas e Automáticas Processo Decomposto Candidatos a Serviços de Entidade Candidatos a Serviços Utilitários Candidatos a Serviços de Tarefa Composições de Serviços Requisitos não Funcionais dos Candidatos a Serviços

Saídas

Análise de solução proposta

Perfis Participantes

R

Administrador de Dados

X

A

C

Analista de Processos de Negócio Analista SOA

X X

Arquiteto SOA

I

X

X

X

X

Arquiteto de Software

X

Auditor SOA

X

Gerente de Projeto

X

Área de Negócio / Área Gestora

X

Descrição das Atividades

Nesta etapa o Analista e Administrador de Dados analisam o cenário proposto pela solução e ponderam quanto a viabilidade e definições já existentes.

55

Definir Modelo de Dados (físico)

Finalidade

Definição de modelo de dados físicos a serem trafegados

Entradas

Modelo de Processo de Negócio (as-is) (template) Modelo de Processo de Negócio (to-be) (template) Análise do Processo de Negócio (template) Modelo de Informação (template) Regras de Negócio (template) Protótipo de Telas Definição de Sistemas Existentes Definição de Tarefas Humanas e Automáticas Processo Decomposto Candidatos a Serviços de Entidade Candidatos a Serviços Utilitários Candidatos a Serviços de Tarefa Composições de Serviços Requisitos não Funcionais dos Candidatos a Serviços

Saídas

Definição de modelos

Perfis Participantes

R

Administrador de Dados

X

A

C

Analista de Processos de Negócio Analista SOA

X X

Arquiteto SOA

I

X

X

X

X

Arquiteto de Software

X

Auditor SOA

X

Gerente de Projeto

X

Área de Negócio / Área Gestora

X

Descrição das Atividades

Após a análise de base de dados é definido o modelo de dados a ser utilizado na para a solução dos diversos cenários propostos

56

Aplicar considerações de integração com sistemas adjacentes

Finalidade

Analisar o impacto para realização de integração de sistemas adjacentes.

Entradas

Modelo de Processo de Negócio (as-is) (template) Modelo de Processo de Negócio (to-be) (template) Análise do Processo de Negócio (template) Modelo de Informação (template) Regras de Negócio (template) Protótipo de Telas Definição de Sistemas Existentes Definição de Tarefas Humanas e Automáticas Processo Decomposto Candidatos a Serviços de Entidade Candidatos a Serviços Utilitários Candidatos a Serviços de Tarefa Composições de Serviços Requisitos não Funcionais dos Candidatos a Serviços

Saídas

Analise de sistemas adjacentes

Perfis Participantes

R

A

Administrador de Dados

C

I

X

X

Analista de Processos de Negócio

X

Analista SOA

X

Arquiteto SOA Arquiteto de Software

X

X

X

X

X

Auditor SOA

X

Gerente de Projeto

X

Área de Negócio / Área Gestora

X

Descrição das Atividades

Nesta etapa os sistemas adjacentes que irão interagir com a solução são analisados para a definição de mecanismos e transformações a serem utilizados para a comunicação destas implementações com a solução proposta.

57

Definir modelo de integração

Finalidade

Definir modelo de integração utilizado para comunicação com sistema adjacentes

Entradas

Modelo de Processo de Negócio (as-is) (template) Modelo de Processo de Negócio (to-be) (template) Análise do Processo de Negócio (template) Modelo de Informação (template) Regras de Negócio (template) Protótipo de Telas Definição de Sistemas Existentes Definição de Tarefas Humanas e Automáticas Processo Decomposto Candidatos a Serviços de Entidade Candidatos a Serviços Utilitários Candidatos a Serviços de Tarefa Composições de Serviços Requisitos não Funcionais dos Candidatos a Serviços

Saídas

Modelo de integração de sistemas adjacentes

Perfis Participantes

R

A

Administrador de Dados

C

I

X

X

Analista de Processos de Negócio

X

Analista SOA

X

Arquiteto SOA Arquiteto de Software

X

X

X

X

X

Auditor SOA

X

Gerente de Projeto

X

Área de Negócio / Área Gestora

X

Descrição das Atividades

Nesta etapa é definido o modelo de dados utilizados na comunicação com sistema adjacente, bem como protocolos a serem utilizados, autenticação, disponibilidade, etç.

58

Apoiar Análise

Finalidade

Fornecer o suporte necessário para que a solução SOA em desenvolvimento esteja de acordo com a arquitetura elaborada

Entradas

Modelo de Processo de Negócio (as-is) (template) Modelo de Processo de Negócio (to-be) (template) Análise do Processo de Negócio (template) Modelo de Informação (template) Regras de Negócio (template) Protótipo de Telas Definição de Sistemas Existentes Definição de Tarefas Humanas e Automáticas Processo Decomposto Candidatos a Serviços de Entidade Candidatos a Serviços Utilitários Candidatos a Serviços de Tarefa Composições de Serviços Requisitos não Funcionais dos Candidatos a Serviços

Saídas

Modelo de Processo de Negócio (atualizado) Documento de Candidatos a Serviço

Perfis Participantes

R

C

I

Administrador de Dados

X

X

Analista de Processos de Negócio

X

X

Analista SOA

A

X

Arquiteto SOA

X

Arquiteto de Software

X

Auditor SOA

X

X

Gerente de Projeto

X

Área de Negócio / Área Gestora

X

Descrição das Atividades

Diferentemente de outras abordagens, em uma Arquitetura Orientada a Serviços, os Analistas SOA e os Arquitetos SOA trabalham em conjunto para a elaboração da análise. O Arquiteto SOA participava ativamente dessa etapa para melhor concepção da solução.

59

Aprimorar Protótipo de Telas

Finalidade

Aprimoramento de concepção inicial de protótipo de telas tendo como base a decomposição de serviços e possíveis implicações que acarretarão da decomposição da solução em serviços.

Entradas

Modelo de Processo de Negócio (as-is) (template) Modelo de Processo de Negócio (to-be) (template) Análise do Processo de Negócio (template) Modelo de Informação (template) Regras de Negócio (template) Protótipo de Telas Definição de Sistemas Existentes Definição de Tarefas Humanas e Automáticas Processo Decomposto Candidatos a Serviços de Entidade Candidatos a Serviços Utilitários Candidatos a Serviços de Tarefa Composições de Serviços Requisitos não Funcionais dos Candidatos a Serviços

Saídas

Protótipo de Telas (atualizado)

Perfis Participantes

R

C

I

Arquiteto SOA

X

X

Arquiteto de Software

X

X

Analista de Processos de Negócio Analista SOA

A X

X

Auditor SOA

X

Designer de Interfaces de Usuário

X

Gerente de Projeto

X

Área de Negócio / Área Gestora

Descrição das Atividades

X

X

X

O mapeamento dos cenários oriundos da etapa poderá acarretar em novas considerações na prototipação inicial de telas, esta etapa permite o alinhamento dos protótipos com as novas considerações especificadas nas fases anteriores, sendo avaliada a necessidade de construção de novos protótipos ou campos de texto.

60

Aprovar análise

Finalidade

Validar todos os passos realizados na Análise de forma a atender o Negócio

Entradas

Modelo de Processo de Negócio (as-is) (template) Modelo de Processo de Negócio (to-be) (template) Análise do Processo de Negócio (template) Modelo de Informação (template) Regras de Negócio (template) Protótipo de Telas Definição de Sistemas Existentes Definição de Tarefas Humanas e Automáticas Processo Decomposto Candidatos a Serviços de Entidade Candidatos a Serviços Utilitários Candidatos a Serviços de Tarefa Composições de Serviços Requisitos não Funcionais dos Candidatos a Serviços

Saídas

Análise do Inventário de Serviços aprovado

Perfis Participantes

R

C

I

Administrador de Dados

X

X

Analista de Processos de Negócio

X

X

X

X

X

X

Analista SOA

A

X

Arquiteto SOA Auditor SOA

X

Gerente de Projeto

X

Área de Negócio / Área Gestora Descrição das Atividades

X

Analisar o Inventário de Serviços, o Modelo de Dados e o Modelo de Integração propostos e verificar se vão atender o escopo proposto. Caso se verifique que o serviço não foi bem desenvolvido ou que precisa de ajustes, pode-se solicitar uma segunda realização de uma ou mais atividades.

61

7.1.1 Visibilidade do Processo de Desenvolvimento A Figura 8 apresenta a visão dos artefatos de entrada e saída para este processo.

Figura 8 - Entradas e Saídas do processo Analisar Inventário de Serviço

62

7.2 Analisar Serviços O processo Analisar Serviço é apresentado na Figura 9 e suas atividades são descritas a seguir. Finalidade

Aplicar princípios de orientação a serviço para detalhar a análise de cada serviço individualmente.

Entradas

OS Modelagem de Negócio e Análise Modelo de Processo de Negócio (as-is) (template) Modelo de Processo de Negócio (to-be) (template) Análise do Processo de Negócio (template) Modelo de Informação (template) Regras de Negócio (template) Protótipo de Telas Documento de Candidatos a Serviços (template) Candidatos a Serviço Arquitetura de Referência

Saídas

Perfil de Serviço (template) Mapeamento de Sistema Adjacente

Perfis Participantes

R

A

Administrador de Dados Analista de Processos de Negócio Analista SOA Arquiteto SOA

C

I

X

X

X

X

X X

Auditor SOA

X

Gerente de Projeto

X

63

Figura 9 – Analisar Serviço

64

Analisar Composições

Finalidade

Analisar composições especificadas

Entradas

Modelo de Processo de Negócio (as-is) (template) Modelo de Processo de Negócio (to-be) (template) Análise do Processo de Negócio (template) Modelo de Informação (template) Regras de Negócio (template) Protótipo de Telas Candidatos a Serviço

Saídas

Composições de tarefa agrupadas

Perfis Participantes

R

A

Analista de Processos de Negócio Analista SOA Arquiteto SOA

C

I

X X X

Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

Nessa tarefa, os cenários identificados no contexto do processo são revisitados tendo uma ótica mais direcionada às trocas de mensagens entre as composições para solução. Serviços de tarefa fazem uso de outros serviços, geralmente de contexto agnóstico, porém como são projetados em um contexto específico, possuem sua capacidade de reutilização remota.

65

Analisar Capacidades

Finalidade

Especificar as capacidades do serviço de tarefa

Entradas

Modelo de Processo de Negócio (as-is) (template) Modelo de Processo de Negócio (to-be) (template) Análise do Processo de Negócio (template) Modelo de Informação (template) Regras de Negócio (template) Protótipo de Telas Candidatos a Serviço Composições de tarefa Agrupadas

Saídas

Capacidades de serviço de tarefa

Perfis Participantes

R

A

Analista de Processos de Negócio Analista SOA Arquiteto SOA

C

I

X X X

Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

Serviços de tarefa possuem granularidade grossa, em detrimento de outros serviços, e como atuam em um contexto específico, tendem a ter geralmente uma única capacidade que expresse seu propósito, como especificado na Arquitetura de Referência SOA (AR-SOA).

66

Analisar Modelos de Informação

Finalidade

Revisar Modelos de Informação definidos anteriormente

Entradas

Modelo de Processo de Negócio (as-is) (template) Modelo de Processo de Negócio (to-be) (template) Análise do Processo de Negócio (template) Modelo de Informação (template) Regras de Negócio (template) Protótipo de Telas

Saídas

Modelos de Informação (atualizado)

Perfis Participantes

R

A

Analista de Processos de Negócio Analista SOA Arquiteto SOA

C

I

X X X

Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

Nesta etapa são refinadas as informações coletadas anteriormente, pois uma ótica mais detalhada sobre tais modelos pode gerar a necessidade de algum ajuste, tendo-se em vista a ênfase em orientação a serviços. Possíveis alterações podem ser descobertas oriundas da diferença de perspectivas entre o funcionamento das informações de negócio e das informações necessárias em um modelo orientado a serviços.

67

Analisar Granularidade

Finalidade

Definir granularidade de dos serviços de entidade

Entradas

Modelo de Processo de Negócio (as-is) (template) Modelo de Processo de Negócio (to-be) (template) Análise do Processo de Negócio (template) Modelo de Informação (template) Regras de Negócio (template) Protótipo de Telas

Saídas

Definição de granularidade de serviços de entidade

Perfis Participantes

R

A

Analista de Processos de Negócio Analista SOA Arquiteto SOA

C

I

X X X

Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

Serviços de entidade estão comumente sujeitos a padrões de decomposição de serviços de modo a ajustar sua evolução em resposta a mudanças de requisitos de negócio, bem como a maturação do seu ambiente subjacente de implementação. A definição de granularidade é importante, portanto, para futuras evoluções do serviço, bem como possibilidade de reutilização do serviço e suas capacidades.

68

Analisar Capacidades (CRUD e Derivações)

Finalidade

Especificação mais aprofundada de capacidades de serviços de entidade

Entradas

Modelo de Processo de Negócio (as-is) (template) Modelo de Processo de Negócio (to-be) (template) Análise do Processo de Negócio (template) Modelo de Informação (template) Regras de Negócio (template) Protótipo de Telas Definição de granularidade de serviços de entidade

Saídas

Revisão de capacidades de serviços de entidade

Perfis Participantes

R

A

Analista de Processos de Negócio Analista SOA Arquiteto SOA

C

I

X X X

Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

Dado o alinhamento de serviços de entidade com as entidades de negócio é comum estes possuírem capacidades relacionadas às operações básicas em entidades manipuladas, como inserir, visualizar, alterar e excluir. Maiores detalhes quanto à nomenclaturas e especificações de capacidades de serviços de entidade podem ser encontrados na Arquitetura de Referência SOA (AR-SOA).

69

Analisar Estrutura de Mensagens

Finalidade

Definição de estrutura de mensagens a serem utilizadas

Entradas

Modelo de Processo de Negócio (as-is) (template) Modelo de Processo de Negócio (to-be) (template) Análise do Processo de Negócio (template) Modelo de Informação (template) Regras de Negócio (template) Protótipo de Telas

Saídas

Estrutura de mensagens de payload em serviços de entidade

Perfis Participantes

R

Analista SOA

X

Arquiteto SOA

X

A

C

Governança SOA

X

Administrador de Dados Gerente de Projetos

Descrição das Atividades

I

X X

X

X

A comunicação de entre serviços se dá através da troca de mensagens entre estes, para tanto é necessária a definição de payload a ser trafegada entre os serviços, levando-se em considerações implicações referentes ao tipo de dado, número de ocorrência do mesmo e obrigatoriedade. A definição de tais mensagens ajuda a separar os contextos de definição do modelo de informações do contexto de mensagens a serem trafegadas.

70

Analisar Capacidades Utilitárias

Finalidade

Especificação mais aprofundada de capacidades de serviços utilitários

Entradas

Modelo de Processo de Negócio (as-is) (template) Modelo de Processo de Negócio (to-be) (template) Análise do Processo de Negócio (template) Modelo de Informação (template) Regras de Negócio (template) Protótipo de Telas

Saídas

Revisão de capacidades de serviços utilitários

Perfis Participantes

R

A

Analista de Processos de Negócio Analista SOA Arquiteto SOA

C

I

X X X

Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

Serviços utilitários geralmente residem em uma hierarquia inferior da composição de serviços, uma vez que são utilizados como composição por serviços de entidade e tarefa, podendo em alguns casos serem eles mesmos compostos por outros serviços utilitários. Dado serem agnósticos e seu alto grau de reusabilidade é importante analisar também sua granularidade. Cada capacidade deve ser analisada individualmente, tendo-se como premissa evitar serviços de grande granularidade por diminuírem a possibilidade de reuso.

71

Analisar Estrutura de Mensagens

Finalidade

Definição de estrutura de mensagens a serem utilizadas

Entradas

Modelo de Processo de Negócio (as-is) (template) Modelo de Processo de Negócio (to-be) (template) Análise do Processo de Negócio (template) Modelo de Informação (template) Regras de Negócio (template) Protótipo de Telas

Saídas

Estrutura de mensagens de payload em serviços utilitários

Perfis Participantes

R

A

Analista de Processos de Negócio Analista SOA Arquiteto SOA

C

I

X X X

Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

A comunicação de entre serviços se dá através da troca de mensagens entre estes, para tanto é necessária a definição de payload a ser trafegada entre os serviços, levando-se em considerações implicações referentes ao tipo de dado, número de ocorrência do mesmo e obrigatoriedade. A definição de tais mensagens ajuda a separar os contextos de definição do modelo de informações do contexto de mensagens a serem trafegadas. No caso de mensagens de serviços utilitários deve-se levar em consideração possíveis transformações a serem executadas quando do encapsulamento de sistemas legados, por possuírem estruturas e dados em formatos diferentes ao modelo de informação proposto.

72

Analisar Sistema Adjacente

Finalidade

Especificação de correlação entre payloads de sistemas legados e modelo de informações

Entradas

Modelo de Processo de Negócio (as-is) (template) Modelo de Processo de Negócio (to-be) (template) Análise do Processo de Negócio (template) Modelo de Informação (template) Regras de Negócio (template) Protótipo de Telas

Saídas

Mapeamento de Sistema Adjacente

Perfis Participantes

R

A

Analista de Processos de Negócio Analista SOA Arquiteto SOA

C

I

X X X

Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

Diferentemente de outras abordagens, sistemas legados ou em silo são vistos como importantes para SOA, uma vez que se trata de uma forma de se obter o retorno de investimento anteriormente feito, entretanto, estes devem ser encapsuladas para o aproveitamento dos benefícios e aplicação de princípios SOA de forma significativa. Comumente, existirão diferenças entre o modelo proposto pelos sistemas legados e os modelos de informação definidos até então, portanto, é de fundamental relevância o mapeamento entre estes modelos a fim de facilitar a melhor compreensão dos dados, evitando-se transformações quando do consumo do serviço utilitário que encapsule o serviço legado em questão.

73

Elaborar Perfil de Serviço

Finalidade

Especificar/ atualizar perfil de serviço para cada serviço avaliado

Entradas

Modelo de Processo de Negócio (as-is) (template) Modelo de Processo de Negócio (to-be) (template) Análise do Processo de Negócio (template) Modelo de Informação (template) Regras de Negócio (template) Protótipo de Telas

Saídas

Perfil de Serviço

Perfis Participantes

R

A

Analista de Processos de Negócio Analista SOA Arquiteto SOA

C

I

X X X

Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

Nesta tarefa as considerações referentes a classificação em camadas dos serviços, modelos de informações, payloads de capacidades, dentre outros devem ser agrupadas em um documento para cada serviço analisado. Dado a evolução de serviços, pode ocorrer cenários onde o perfil de serviço já exista, sendo necessária a atualização do mesmo.

74

Aprovar Análise

Finalidade

Validar todos os passos realizados na Análise de forma a atender o Negócio

Entradas

Modelo de Processo de Negócio (as-is) (template) Modelo de Processo de Negócio (to-be) (template) Análise do Processo de Negócio (template) Modelo de Informação (template) Regras de Negócio (template) Protótipo de Telas

Saídas

Perfil de serviço aprovado

Perfis Participantes

R

A

Analista de Processos de Negócio X

Arquiteto SOA Gerente de Projeto Descrição das Atividades

I

X

Analista SOA Governança SOA

C

X X X Analisar o modelo de serviço sob análise e verificar se irá atender o escopo proposto. Caso se verifique que o serviço não foi bem desenvolvido ou que precisa de ajustes, pode-se solicitar uma segunda realização de uma ou mais atividades.

75

Apoiar Análise

Finalidade

Fornecer o suporte necessário para que a equipe que está desenvolvendo a solução SOA tenha um perfeito entendimento sobre o processo e o negócio trabalhado.

Entradas

Modelo de Processo de Negócio (as-is) (template) Modelo de Processo de Negócio (to-be) (template) Análise do Processo de Negócio (template) Modelo de Informação (template) Regras de Negócio (template) Protótipo de Telas

Saídas

Perfil de Serviço aprovado

Perfis Participantes

R

A

Analista de Processos de Negócio

Governança SOA Gerente de Projeto Descrição das Atividades

I

X

Analista SOA Arquiteto SOA

C

X X X X Estar disponível para sanar quaisquer dúvidas que possam surgir durante a Análise dos Serviços.

76

Elaborar Perfil de Serviço

Finalidade

Especificar/ atualizar perfil de serviço para cada serviço avaliado

Entradas

Modelo de Processo de Negócio (as-is) (template) Modelo de Processo de Negócio (to-be) (template) Análise do Processo de Negócio (template) Modelo de Informação (template) Regras de Negócio (template) Protótipo de Telas

Saídas

Perfil de Serviço

Perfis Participantes

R

Analista de Processos de Negócio Analista SOA Arquiteto SOA

A

C

I

X

X

X X

Auditor SOA

X

Gerente de Projeto

X

Descrição das Atividades

Nesta tarefa as considerações referentes a classificação em camadas dos serviços, modelos de informações, payloads de capacidades, dentre outros devem ser agrupadas em um documento para cada serviço analisado. Dado a evolução de serviços, pode ocorrer cenários onde o perfil de serviço já exista, sendo necessária a atualização do mesmo.

77

7.2.1 Visibilidade do Processo de Desenvolvimento A Figura 10 apresenta a visão dos artefatos de entrada e saída para este processo.

Figura 10 - Entradas e Saídas do processo Analisar Serviço

78

7.3 Heurísticas para Análise Orientada a Serviço Esta seção apresenta heurísticas para Análise Orientada a Serviços que devem ser consideradas pelo Analista SOA ao identificar e modelar serviços para uma iniciativa SOA.

7.3.1 Princípio da Capacidade de Composição de Serviço •

Composição de serviços

Heurística: Composições de serviço são usadas para evitar a construção de lógica de solução redundante. Heurística: Serviços são projetados para serem membros efetivos de composição, independente de eles precisarem ser imediatamente listados em uma composição. A habilidade de compor serviços com efetividade é requisito crítico para atingir alguns dos objetivos fundamentais de computação orientada a serviço. •

Granularidade

Heurística: A granularidade definida é influenciada pela capacidade de se realizar composições complexas, segundo critérios de complexidade de projeto e de desempenho. Heurística: Projetar serviços com granularidade baixa para disponibilizar serviços com alto valor ao negócio. Serviços são abstrações que escondem dos consumidores os detalhes de implementação. Entretanto, uma granularidade mais fina acarreta normalmente em um tempo de execução maior. Por essa razão, geralmente é melhor ter uma chamada de serviço transferindo todos os dados necessários entre um provedor e seu consumidor ao invés de ter múltiplas chamadas de serviço processando a mesma quantidade de dados. Serviços com granularidade grossa ajudam a separar a estrutura interna de um provedor de serviço da sua interface externa. Ter um serviço para cada um acessar um atributo de uma entidade (por exemplo, um serviço para cada setter e getter) pode resultar em objetos distribuídos que aumentam as dependências entre os sistemas distribuídos. Em termos de necessidades e capacidades, a granularidade geralmente está associada ao detalhamento do nível do problema que está sendo resolvido, ou seja, projetar num nível mais estratégico versus num nível algorítmico, e definir o nível ótimo não está relacionado em contar o número de interfaces ou o número de tipos de trocas de informação que estão conectadas a uma interface. Outro problema com a recomendação de serviços grossos tem a ver com considerações de desempenho. Processar uma quantidade de dados demanda tempo e, se o consumidor não precisa desses dados, o tempo empregado para o processamento será em vão. Para o projeto orientado a serviço, deve-se pensar na granularidade no nível do provedor (quantos serviços são providos) ou no nível da especificação do serviço. Uma especificação de serviço é um agrupamento lógico das operações do serviço ao se considerar o negócio.

79

Quando as operações dos serviços são projetadas, considere colaborações, cenários de uso e mensagens (número e tamanho delas) que irão trafegar entre provedores e consumidores de serviços. Operações com granularidade grossa fornecem mais valor de negócio e permitem modificações mais fáceis no código. Os parâmetros desse tipo de operação (que usam mensagens para entrada, saída e erro) são menos suscetíveis a erro. Usar parâmetros com granularidade fina ao invés de mensagens, contudo, é geralmente mais descritivo. Para a granularidade do serviço, deve-se considerar que serviços podem ser compostos. Isso está relacionado com a reutilização e a habilidade de prover novas funcionalidades baseadas em funcionalidades existentes. Um conjunto de serviços em certo nível de granularidade pode ser orquestrado/coreografado e o resultado pode ser outro serviço com granularidade mais grossa. Pode-se, contudo, ter-se tarefas de negócio fornecidas pelos serviços e então ter uma sequência dessas tarefas (um processo de negócio) fornecida também como um serviço. Por fim, tomar decisões de projeto sobre granularidade de serviço é sempre um tradeoff entre desempenho (por exemplo, tamanho e número de mensagens sendo trocadas e a eficiência da implementação) e potencial de reuso. Além disso, SOA contêm tanto serviços com granularidade fina (serviços atômicos) quanto grossa (serviços compostos). •

Serviço Autocontido

Heurística: Priorizar a definição de serviços autocontidos. Caso seja necessário que um serviço invoque outro serviço, considerar o impacto da realização de composição de serviços, bem como o uso de arquiteturas e tecnologias específicas para realização dessas composições (p.e. mediadores (ESB), orquestração de serviços). O objetivo, enfim, é minimizar as dependências. Quanto menos dependências, modificações ou erros em um sistema, menos consequências serão produzidas em outro sistema.

7.3.2 Princípio do Reuso de Serviço •

Serviços como recursos corporativos

Heurística: Soluções individuais devem usar (compartilhar) lógicas de solução encapsuladas por serviços (agnósticos), posicionados como recursos corporativos (em um inventário de serviços). Heurística: Projetar serviços que possam ter uma demanda maior que a esperada. Heurística: Serviços semelhantes devem ser consolidados em um único serviço. A assinatura do serviço deve ser definida de acordo com a função mais genérica. Se as funções consideram diferentes requisitos não funcionais, então deve ser considerado o requisito funcional mais restritivo. Um dos objetivos mais fundamentais de orientação a serviço consiste em estabelecer serviços como recursos corporativos. Um recurso corporativo é algo pode ser usado por mais de uma parte da corporação. Um contexto de serviço que posiciona a lógica de serviço como um recurso corporativo é agnóstico por natureza. Um contexto agnóstico não tem propósito específico e, portanto, é potencialmente útil para muitos. O reuso é o princípio mais importante no projeto de serviços. Normalmente, têm-se requisitos específicos de consumidores específicos. Contudo, quando se quer ter todas as vantagens de SOA, é necessário que os serviços que foram projetados sejam reusados por outros 80

consumidores com requisitos ligeiramente diferentes. Ou seja, não se conhece de antemão todos os consumidores de um serviço e seus requisitos durante o projeto do serviço, o que torna a tarefa muito difícil.

7.3.3 Padrões de Projeto para Análise Orientada a Serviço Os seguintes padrões de projeto devem ser observados como parte do processo de Análise Orientada a Serviço. Uma descrição mais aprofundada de cada um pode ser encontrada nas respectivas páginas do livro de Thomas Erl (Erl, SOA Design Patterns, 2009), indicadas ao lado de cada padrão: • • • • • • • • • • • •

Abstração de Entidade (175); Abstração de Processo (182); Abstração de Utilitário (168); Centralização de Lógica (136); Camadas de Serviços (143); Capacidade Agnóstica (324); Contexto Agnóstico (312); Contexto Não Agnóstico (319); Encapsulamento em Serviço (305); Inventário Corporativo (116); Inventário de Domínio (123); Normalização de Serviços (131);

81

8 PROJETO ORIENTADO O SERVIÇO A etapa de Projeto Orientado a Serviço tipicamente começa quando uma extensão significativa da análise foi completada. O termo “projeto orientado a serviço” é comumente associado com um processo formal para projetar contratos de serviço. Entretanto, esse termo também é usado em um sentido mais amplo que engloba o projeto da lógica de serviço. Em geral, é importante reconhecer que uma característica distinta primária do projeto orientado a serviço é a abordagem “contrato primeiro” para o projeto de serviços. Todo o esforço colocado nos processos de análise e modelagem de serviços resulta em uma coleção de candidatos a serviços que estabelecem o ponto de partida para o projeto de serviços. Cada candidato a serviço pode ser usado como entrada para uma instância do processo de projeto orientado a serviço. Ao contrário do processo de análise orientada a serviço, que usualmente resulta na criação de múltiplos candidatos a serviços, uma iteração do processo de projeto orientado a serviço usualmente resulta na criação de um único contrato de serviço. O foco da fase Projetar Arquitetura é a definição das escolhas de projeto de arquitetura de serviço (e de solução) que qualificam, enquadram e restringem os processos de implementação (codificação) de serviços. Destaque-se que, em um projeto de solução orientada a serviços, o projeto da solução como um todo se concretiza a partir de composições de serviços individuais e de sua integração com a camada de interface de usuário (camada de apresentação). Desse modo, esse processo de projeto de lógica (de serviço e de solução) orientada a serviço deve enfocar o uso e aplicação dos princípios de orientação a serviço. A Realizar Projeto Orientado a Serviço (processo ilustrado na Figura 11). Finalidade

Definição de contratos e modelos canônicos

Entradas

Modelo Canônico de dados Perfil de Serviço (template) Arquitetura de Referência

Saídas

Arquitetura de Referência Modelos Canônicos Contrato de Serviços Perfil de Serviço (template)

Perfis Participantes

R

A

C

Administrador de Dados

X

Analista de Processos de Negócio

X

Analista SOA Arquiteto SOA

X X

Auditor SOA Especialista em Governança SOA Gerente de Projeto

I

X X X

82

Figura 11 - Relizar Projeto Orientado a Serviço

83

Identificar Modelos Canônicos aplicáveis

Finalidade

Levantamento inicial de Modelos canônicos

Entradas

Perfil de Serviço (template) Modelos Canônicos

Saídas

Modelos canônicos aplicáveis

Perfis Participantes

R

A

C

Administrador de Dados

I X

Analista de Processos de Negócio

X

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

X

Especialista em Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

O modelo canônico é uma definição universal utilizada entre serviços que possui entre suas principais vantagens a reutilização e padronização de modelos na requisição e comunicação entre serviços. Ao se identificar, e consolidar futuramente os modelos canônicos, outra grande vantagem é a diminuição de esforço e overhead em transformações de modelos díspares de dados.

84

Revisar Modelos Canônicos aplicáveis

Finalidade

Revisar os modelos canônicos para identificar modelos que poderão ser reutilizados e novos modelos a serem desenvolvidos

Entradas

Modelos canônicos aplicáveis

Saídas

Modelos canônicos

Perfis Participantes

R

A

C

Administrador de Dados

I X

Analista de Processos de Negócio

X

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

X

Especialista em Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

Nesta etapa os modelos até então desenvolvidos são analisados novamente a fim de elencar quais serão reutilizados nas definições dos contratos, sendo possíveis três cenários distintos: modelo canônico que atende as necessidades do novo contrato, o modelo canônico que precisa ser ajustado para atender às novas demandas ou novos modelos canônicos que precisam ser criados para a definição do contrato.

85

Reusar Modelo sem Adaptações

Finalidade

Reutilizar modelo canônico existente

Entradas

Modelo Canônico

Saídas

Modelo Canônico reutilizado

Perfis Participantes

R

A

C

Administrador de Dados

I X

Analista de Processos de Negócio

X

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

X

Especialista em Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

Nesta etapa não será necessária a criação de novos modelos canônicos, dado que os modelos previamente definidos podem ser reutilizados para definição de mensagens a serem utilizadas no contrato a ser definido. Esse cenário favorece o princípio de reusabilidade, diminuindo-se assim o esforço necessário para a criação de novos contratos.

86

Adaptar Modelo

Finalidade

Atualizar modelos existentes para atenderem novas demandas em um contexto funcional existente

Entradas

Modelos canônicos existentes

Saídas

Modelos canônicos (atualização)

Perfis Participantes

R

Administrador de Dados

A

C

X

Analista de Processos de Negócio

I X

X

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

X

Especialista em Governança SOA

X

Gerente de Projeto

X

X

Geralmente é necessário ampliar um modelo canônico, seja adicionando, atualizando ou removendo tipos definidos. É interessante, no entanto, ponderar o impacto de tais estratégias: •

Descrição das Atividades

•

• •

A adição de elementos obrigatórios em uma estrutura já existente comprometerá clientes que já utilizavam a estrutura em sua concepção anterior; A adição de elementos opcionais não trará impactos a clientes que já utilizavam a estrutura em sua concepção anterior; A adição de uma nova estrutura não trará impactos a clientes; A exclusão de estrutura ou de elementos de uma estrutura comprometerá clientes que já utilizavam a estrutura em sua concepção anterior.

87

Construir Modelo

Finalidade

Construir novos modelos canônicos que servirão de base para a criação de novos contratos

Entradas

Perfil de Serviço (template) Modelos canônicos existentes

Saídas

Modelos canônicos

Perfis Participantes

R

Administrador de Dados

A

C

I

X

Analista de Processos de Negócio

X

Analista SOA

X

Arquiteto SOA

X

X

Auditor SOA

X

Especialista em Governança SOA

X

Gerente de Projeto

Descrição das Atividades

X

X

X

Por vezes, novas estruturas de modelos canônicos são necessárias para a criação de um contrato de serviço. Nestes casos, a especificação universal de modelo deverá ser definida para suprir as estruturas faltantes, de forma a atender prioridades requisitadas e possibilitar a reutilização desse mesmo modelo em futuras implementações.

88

Aplicar Padronizações e Normalizar Modelo

Finalidade

Aplicar padrões e melhores práticas a fim de construir modelos canônicos passíveis de reutilização

Entradas

Arquitetura de Referência

Saídas

Modelos canônicos (atualizados)

Perfis Participantes

R

Administrador de Dados

A

C

I

X

Analista de Processos de Negócio

X

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

X

Especialista em Governança SOA

X

Gerente de Projeto

Descrição das Atividades

X

X

Um modelo canônico é uma estrutura universal a ser adotada para definição de entidades inerentes ao negócio. Por isso, é importante considerar as possibilidades de evoluções e alterações futuras do mesmo, definindo principalmente o nível de granularidade a ser utilizado. A exposição de estruturas a serem reaproveitadas em definições futuras é uma preocupação pertinente, uma vez que alterações em modelos canônicos podem ter um impacto em cascata nos serviços de uma composição ou que interagem entre si.

89

Publicar Modelo

Finalidade

Expor o modelo canônico como definição universal a ser utilizada pelos serviços subsequentes.

Entradas

Modelos canônicos

Saídas

Modelo canônico publicado (Atualizado)

Perfis Participantes

R

A

C

Administrador de Dados

X

Analista de Processos de Negócio

X

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

X

Especialista em Governança SOA Gerente de Projeto Descrição das Atividades

I

X

X X

Definida a padronização dos modelos, estes devem ser publicados para que novas definições não sobreponham as estruturas já definidas anteriormente e tão pouco sejam criadas estruturas diferentes para um mesmo contexto funcional.

90

Projetar/Adaptar interface abstrata

Finalidade

Definição de capacidades e das mensagens contidas em cada capacidade

Entradas

Perfil de Serviço (template) Modelos Canônicos

Saídas

Contrato de Serviços (parcial)

Perfis Participantes

R

A

C

Administrador de Dados

I X

Analista de Processos de Negócio

X

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

X

Especialista em Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

A primeira etapa ao se definir um contrato é a definição de sua interface abstrata, ou seja, a definição das mensagens de entrada, de saída, de falhas, a definição das capacidades e as mensagens a ela vinculadas.

91

Projetar/Adaptar interface concreta

Finalidade

Atualização de contrato, definindo-se protocolos e endpoints

Entradas

Perfil de Serviço (template) Modelos Canônicos Contrato de Serviços (parcial)

Saídas

Contrato de Serviços (parcial)

Perfis Participantes

R

A

C

Administrador de Dados

I X

Analista de Processos de Negócio

X

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

X

Especialista em Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

A definição de interface concreta é constituída pela definição do protocolo a ser utilizado, bem como o endpoint definido do contrato.

92

Aplicar padronização de projeto

Finalidade

Realização de padronização em modelos canônicos e contratos

Entradas

Arquitetura de Referência

Saídas

Contrato de Serviços

Perfis Participantes

R

A

C

Administrador de Dados

I X

Analista de Processos de Negócio

X

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

X

Especialista em Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

A padronização de contratos visa buscar a interoperabilidade, ou seja, a facilidade em se compreender e reutilizar contratos e em se manter a evolução dos mesmos. A aplicação das melhores práticas e da padronização evita também a utilização de transformações entre composições de serviços.

93

Atualizar perfil de serviço

Finalidade

Atualização de perfil de serviço

Entradas

Perfil de Serviço

Saídas

Perfil de Serviço (template)

Perfis Participantes

R

A

C

Administrador de Dados

I X

Analista de Processos de Negócio

X

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

X

Especialista em Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

Nesta etapa, o perfil de serviços é atualizado para conter definições do contrato concreto, como, por exemplo, o protocolo de comunicação e o endpoint. Essas novas informações favorecerão o entendimento futuro e a evolução dos serviços.

94

Aprovar Projeto

Finalidade

Aprovar as definições do projeto

Entradas

Projeto orientado a serviço

Saídas

Definições aprovadas

Perfis Participantes

R

A

C

Administrador de Dados

X

Analista de Processos de Negócio

X

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

X

Especialista em Governança SOA Gerente de Projeto Descrição das Atividades

I

X X

Cabe ao Especialista em Governança SOA verificar se o contrato proposto atende à demanda requisitada, sendo verificados os modelos canônicos, contratos propostos e soluções existentes.

95

Apoiar Projeto

Finalidade

Apoiar o Projeto

Entradas

Necessidades da etapa

Saídas

Necessidades da etapa

Perfis Participantes

R

A

C

Administrador de Dados

I X

Analista de Processos de Negócio Analista SOA

X X

Arquiteto SOA

X

Auditor SOA

X

Especialista em Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

Diferentemente de outras abordagens, em uma Arquitetura Orientada a Serviços, os Analista de Processos de Negócio, Analistas SOA e os Arquitetos SOA trabalham em conjunto para a elaboração dos contratos, assim como nas etapas anteriores, onde, apesar do Analista SOA ser responsável por elencar os serviços candidatos, o Arquiteto SOA participava ativamente na compreensão do todo.

96

8.1.1 Visibilidade do Processo de Desenvolvimento A Figura 12 apresenta a visão dos artefatos de entrada e saída para este processo.

Figura 12 - Entradas e Saídas do processo Realizar Projeto Orientado a Serviço

97

8.2 Projetar Arquitetura Durante a fase “Projetar Arquitetura”, os serviços candidatos definidos durante a fase de Análise Orientada a Serviço são analisados com foco na definição da arquitetura a ser aplicada na construção do serviço. Antes de Projetar a Arquitetura, é fundamental ter em mãos a Arquitetura de Referência, onde são definidos os padrões de projeto a serem aplicados em soluções Orientadas a Serviço. O processo Projetar Arquitetura é apresentado e suas atividades são descritas a seguir (bem como ilustrado na Figura 13). Finalidade

Definir Arquitetura a ser aplicada na construção dos serviços

Entradas

Perfil de Serviço (template) Arquitetura de Referência

Saídas

Perfil de Serviço (atualizado) Arquitetura especializada

Perfis Participantes

R

A

C

Administrador de Dados

X

Analista de Processos de Negócio

X

Analista SOA Arquiteto SOA

I

X X

Auditor SOA

X

Especialista em Governança SOA

X

Gerente de Projeto

X

98

Figura 13 - Projetar Arquitetura de Serviço

99

Analisar Padrões de Arquitetura de Serviço

Finalidade

Analisar especificamente cada capacidade de serviço para a definição dos Padrões de Projeto a serem utilizados na construção do serviço

Entradas

Perfil de Serviço (template) Arquitetura de Referência

Saídas

Arquitetura de Serviços

Perfis Participantes

R

A

C

Administrador de Dados

I X

Analista de Processos de Negócio

X

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

X

Especialista em Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

A avaliação dos contratos de serviços tem por objetivo identificar quais Padrões de Projeto podem ser aplicados na construção do serviço (definidos junto a Arquitetura de Referência SOA). Cada capacidade de serviço deve ser analisada individualmente. O resultado da análise de cada capacidade leva a definição da solução para construção do serviço. Esta análise visa, além da definição da Arquitetura da Solução, a detecção de padrões de projeto disponíveis no mercado para reutilização, favorecendo o retorno do investimento e evitando a criação de novas soluções quando da já existência de soluções parciais como sistemas legados, tal como ocorre em outras abordagens.

100

Aplicar Padrões de Projeto conforme Arquitetura de Serviço Selecionada.

Finalidade

Aplicar Padrões de Projeto com base na Arquitetura de Referência SOA

Entradas

Arquitetura de serviço

Saídas

Arquitetura especializada

Perfis Participantes

R

A

C

Administrador de Dados

I X

Analista de Processos de Negócio

X

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

X

Especialista em Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

Nesta etapa, os padrões de projeto definidos são aplicados conforme Arquitetura de Referência, resultando na Arquitetura especializada (identificados junto a Arquitetura de Referência SOA).

101

Definir Arquitetura específica e Padrões de Projetos aplicáveis

Finalidade

Definir Padrões de Projeto Específicos para a construção do serviço

Entradas

Arquitetura de Serviço

Saídas

Arquitetura Especializada

Perfis Participantes

R

A

C

Administrador de Dados

I X

Analista de Processos de Negócio

X

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

X

Especialista em Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

A etapa de avaliação do serviço identificou que os Padrões de Projeto pré-definidos não são adequados à construção de um serviço em particular. Desta forma, Padrões de Projeto específicos devem ser criados para se adequarem a uma Arquitetura Especializada a ser aplicada na construção do serviço.

102

Aplicar Padrões de Projeto conforme Arquitetura Especializada

Finalidade

Aplicar Padrões de Projeto conforme Arquitetura Especializada para a construção de um serviço em particular

Entradas

Arquitetura Especializada

Saídas

Padrões aplicados

Perfis Participantes

R

A

C

Administrador de Dados

I X

Analista de Processos de Negócio

X

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

X

Especialista em Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

Nesta etapa, os padrões de projeto definidos são aplicados conforme Arquitetura de Referência resultando na Arquitetura Especializada da solução.

103

Atualizar Perfil de Serviço

Finalidade

Atualizar Perfil de Serviço

Entradas

Arquitetura de Referência Arquitetura Especializada Perfil de Serviço

Saídas

Perfil de Serviço (atualizado)

Perfis Participantes

R

A

C

Administrador de Dados

I X

Analista de Processos de Negócio

X

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

X

Especialista em Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

Nesta etapa, o perfil de serviços é atualizado para conter definições arquiteturais a serem seguidas na implementação dos serviços. Essas novas informações favorecerão o entendimento futuro e evolução dos serviços.

104

Aprovar Projeto

Finalidade

Aprovar as definições arquiteturais propostas

Entradas

Perfil de Serviço (atualizado) Arquitetura de Referência Arquitetura Especializada

Saídas

Arquitetura aprovada

Perfis Participantes

R

A

C

Administrador de Dados

X

Analista de Processos de Negócio

X

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

X

Especialista em Governança SOA Gerente de Projeto Descrição das Atividades

I

X X

Cabe ao Especialista em Governança SOA verificar se a arquitetura proposta atende à demanda requisitada, sendo verificadas a esta e às outras soluções existentes.

105

8.2.1 Visibilidade do Processo de Desenvolvimento A Figura 14 apresenta a visão dos artefatos de entrada e saída para este processo.

Figura 14 - Entradas e Saídas do processo Projetar Arquitetura

106

8.3 Heurísticas para Projeto Orientado a Serviço Esta seção apresenta heurísticas para Projeto Orientado a Serviços que devem ser consideradas pelo Analista SOA e pelo Arquiteto SOA ao projetar serviços para uma iniciativa SOA.

8.3.1 Princípio de Padronização de Contrato de Serviço •

Abordagem “Contrato Primeiro”

Heurística: Serviços dentro de um mesmo inventário de serviços estão em conformidade com os mesmos padrões para projeto de contrato. Heurística: Evitar o uso de ferramentas de geração automática de contrato a partir de lógica implementada (legada). Serviços expressam seus propósitos e capacidades através de um contrato padronizado. Isso implica em grande ênfase no projeto de contratos de serviços advogando o princípio de projeto “contrato primeiro”. Seu propósito é assegurar que a maneira na qual os serviços expressam funcionalidades e representam tipos de dados é mantida relativamente alinhada e independente (desacoplada) do projeto da lógica de solução. •

Padronizações de Projeto

Heurística: A arquitetura de referência SOA deve estabelecer diferentes padronizações de projeto (design standards), com objetivo de garantir a uniformidade dos produtos de um projeto de SOA. Heurística: Serviços dentro de um mesmo inventário de serviços devem estar em conformidade com os mesmos padrões para projeto de contrato (Princípio da Padronização de Contratos). Há dois tipos de padronização de contratos: Padronização de Representação de Dados (ou Modelo de Dados). Padronização da Expressão Funcional. •

Modelos de Dados Padronizados (Modelo Canônico)

Heurística: Definições de contrato devem compartilhar modelos canônicos comuns. Esses modelos canônicos definem a estrutura de dados de entrada e/ou saída para cada capacidade de serviço. Heurística: Antes de criar um tipo de dado no projeto do serviço, verificar os tipos de dados existentes no modelo canônico. Um objetivo fundamental dessa heurística consiste em evitar transformações através da padronização da representação de dados entre contratos de serviços. Recomenda-se ter um conjunto básico de tipos fundamentais que possam ser compostos com outros tipos (estruturas, records, etc.) e sequências (arrays). É necessário tomar cuidado com enumerações, herança e polimorfismo (mesmo quando XML suportar isto). Em resumo, deve-se ser conservador com os tipos de dados. 107

A harmonização dos tipos de dados é um grande problema em ambientes distribuídos. Não há dúvida que tudo se torna muito mais fácil se os tipos de dados estão compartilhados em todos os sistemas. Segundo Josuttis [2007], quando a orientação a objetos se tornou famosa, ter um modelo de objeto de negócio comum se tornou um objetivo geral. Entretanto, essa abordagem se tornou um problema quando aplicada a grandes sistemas. A primeira razão é organizacional: é muito difícil entrar em acordo sobre tipos de dados comuns. Existem visões e interesses que variam muito de sistema pra sistema, uma vez que os diversos sistemas possuem diferentes proprietários. Cedo ou tarde o preço da harmonização se torna muito alto, pois é muito caro manter todos os sistemas sincronizados e, quando um novo serviço for adicionado, a heterogeneidade será introduzida novamente. Se tipos de dados não estão harmonizados, então é preciso criar mapeamentos entre eles. Apesar da utilização de tipos de dados heterogêneos diminuir o acoplamento, a existência de uma diretriz organizacional para definir um modelo canônico de dados pode ser útil para manter a reusabilidade. Para a definição do contrato dos serviços, contudo, a homogeneização dos tipos de dados dificulta a criação de visão sobre os tipos de dados e pode aumentar desnecessariamente o tamanho das mensagens entre os serviços. •

Expressão Funcional padronizada (convenção de nomenclatura)

Heurística: Serviços de entidade serão nomeados em acordo com as entidades de negócio correspondentes. Heurística: Os nomes de serviços de tarefas serão baseados no processo de negócio que o serviço é responsável por automatizar. Heurística: Nomes de capacidades de serviço incluíram um verbo seguido por um nome. Heurística: Os nomes das capacidades de serviço não podem repetir o nome do serviço. Padronização da Expressão Funcional refere-se a ter cada serviço expressando detalhes de seu respectivo contexto funcional usando convenções comuns, o que facilita a descoberta e o reuso de serviços.

8.3.2 Princípio do Baixo Acoplamento •

Acoplamento Consumidor para Contrato

Heurística: Reduzir o acoplamento entre o contrato de serviço e o consumidor de serviço. Um provedor não deve ter conhecimento sobre uma instância específica de um consumidor e vice-versa. Trocar um provedor ou a implementação de um serviço deve ter efeitos mínimos nos consumidores. Uma consideração central de projeto para o estabelecimento de relações entre consumidor e serviço é se o consumidor de serviço de fato se acopla ao contrato de serviço. Deve-se enfatizar fortemente que um consumidor de serviço apenas se acople ao contrato de serviço (acoplamento Consumidor-para-Contrato). A forma negativa fundamental de acoplamento de consumidor ocorre quando o programa consumidor é projetado para ignorar o contrato de serviço, de modo a acessar partes da

108

implementação subjacente Implementação). •

do

serviço

diretamente

(acoplamento

Consumidor-para-

Acoplamento Lógica para Contrato

Heurística: Separar a especificação do serviço da sua implementação, descrevendo um modelo técnico (contrato) e um modelo conceitual (requisitos, restrições etc.). Heurística: Reduzir o acoplamento entre o contrato de serviço e sua lógica subjacente. Ao projetar serviços, os seguintes tipos de acoplamento devem ser levados em consideração de modo a atingir o nível apropriado de acoplamento global: Lógica-para-Contrato (positivo) Contrato-para-Lógica (negativo) Contrato-para-Funcionalidade (negativo) Contrato-para-Implementação (negativo) Contrato-para-Tecnologia (negativo) Tipos negativos de acoplamento de contrato são evitados de modo a maximizar a independência de governança do contrato de serviço. Um contrato de serviço completamente desacoplado pode evitar impor tipos de acoplamento negativos aos consumidores de serviço. Em última análise, qualquer forma indesejável de acoplamento permitida no projeto do contrato de serviço termina sendo imposta e proliferada através de todos os consumidores de serviço. Isso causa sérios problemas quando serviços agnósticos são largamente reusados. É importante ter todas as especificações dos serviços de forma independente de uma implementação particular, promovendo o projeto e a evolução independente da lógica de serviço. Heurística: Descrever formalmente a especificação do serviço. Heurística: Atualizar especificação do serviço com detalhamentos da fase de projeto. A especificação do serviço deve ser descrita formalmente, tanto em um formato que seja compreensível por máquinas, para que os geradores de código possam ajudar com a implementação do serviço, como também por humanos. O contrato do serviço deve estar no nível de especificação (não no nível de implementação). Para garantir uma rastreabilidade através dos processos de negócio, é interessante relacionar a especificação do serviço com a modelagem do processo de negócio o qual o serviço apoia.

8.3.3 Princípio da Abstração de Serviço Heurística: Contratos de Serviços contêm apenas informações essenciais e informações sobre os serviços são limitadas ao que está publicado nos contratos de serviços. Em um nível fundamental, esse princípio enfatiza a necessidade de esconder tanto quanto possível os detalhes subjacentes de um serviço. A informação sobre um serviço é, portanto, limitada ao que está publicado no contrato de serviço. Entretanto, abstração de serviço influencia o conteúdo do contrato de serviço.

109

Existem quatro tipos de meta abstração: Funcional: relaciona-se com metadados que descrevem o que o serviço é capaz de fazer. Tecnológica: relaciona-se com metadados que descrevem a implementação técnica da lógica de serviço subjacente. Programática: relaciona-se com metadados que descrevem como o serviço realizada suas capacidades. Qualidade de serviço: relaciona-se com metadados que descrevem o comportamento, limitações e requisitos de integração do serviço. A aplicação desse princípio envolve a necessidade de introduzir medidas de controle de acesso às especificações de projeto do serviço e ao código fonte. Isso protege tanto o serviço quanto seus consumidores de formas indesejáveis de acoplamento. O conteúdo de contratos de serviços pode ser regulado por este princípio, pois este encoraja a racionalização de meta informações e restrições. O propósito por de trás dessas limitações é maximizar a longevidade do contrato de serviço e dar liberdade de evolução da implementação subjacente aos proprietários de serviço. A aplicação deste princípio introduz a questão da “composição escondida”, onde programas consumidores de serviço não estão cientes que o serviço que eles estão invocando, de fato, encapsula uma composição inteira.

8.3.4 Princípio da Visibilidade de Serviço Heurística: Prover nomes significativos e bem descritivos do serviço e suas operações baseado no domínio do negócio, não na tecnologia. Definir padrões de nomes e descrições de acordo com as diretrizes da organização. Heurística: Publicar descrição dos serviços em um repositório de contratos. Heurística: Suplementar as especificações de serviços com metadados comunicativos pelos quais eles podem ser eficientemente descobertos e interpretados. É desejável que serviços (especialmente serviços agnósticos) possam ser facilmente localizados e entendidos de modo que eles possam ser apropriadamente reusados e recompostos. Existem dois conceitos relevantes para se obter essa característica: Capacidade de descoberta: O processo de buscar e encontrar uma lógica de solução dentro de um ambiente específico é referido como descoberta. Para que algo dentro de uma corporação possa ter capacidade de descoberta, ele precisa ser equipado com meta informação que permitirá que ele seja incluído no escopo dos mecanismos de busca da descoberta. Informação de capacidade de descoberta é essencialmente uma combinação do conteúdo de um contrato de serviço e metadados no registro do diretório correspondente. Algo que possa ser corretamente descoberto é considerado possuidor de uma medida de capacidade de descoberta. Capacidade de ser interpretado: Uma vez encontrados por um humano, é importante que o propósito e as capacidades do que foi descoberto possam ser claramente entendidos. Este nível de clareza ou “qualidade de comunicações” é referido como capacidade de ser interpretado. 110

Os passos envolvidos por um humano para avaliar os resultados de uma consulta de um processo de descoberta e, então, escolher um serviço como sendo capaz de atender requisitos de automação desejados é parte do processo de interpretação.

8.3.5 Princípio da Autonomia de Serviço Heurística: O projeto de serviços deve considerar o nível de controle sobre seu ambiente de execução subjacente. A autonomia de serviço refere-se ao: Nível de controle que se tem sobre um serviço em tempo de projeto (autonomia em tempo de projeto). Nível de controle que um serviço tem sobre seu ambiente de execução (autonomia em tempo de execução). Existem diferentes níveis atingíveis de autonomia em tempo de execução, dependendo da extensão do isolamento de uma dada implementação de um serviço. A aplicação desse princípio depende da quantidade de recursos compartilhados dos quais um serviço pode precisar ou depender. Qualquer parte do ambiente de um serviço sobre o qual este não tenha controle exclusivo pode comprometer a previsibilidade de seu desempenho e comportamento. Atingir um nível alto de autonomia é especialmente importante no caso de serviços agnósticos, tais como aqueles baseados nos modelos de serviços de entidade e utilitários. Ao compor serviços, a autonomia é automaticamente reduzida, na medida em que se aproximada dos níveis superiores em uma hierarquia de composição. •

Monitoramento de Serviço

Heurística: Definir métricas para monitoramento de serviços e utilizar ferramenta de monitoramento de serviços. Outra questão importante é a dificuldade em monitorar a quantidade de tráfego que um serviço está recebendo e de onde se não existe um software e métricas de monitoramento de SLA (Service-Level Agreement). Se o serviço é utilizado por diferentes clientes de diferentes domínios, é importante particularmente considerar que ele poderá ocorrer uma explosão de tráfego de forma repentina e inesperada devido a composição realizada por clientes fora do seu projeto. Outro problema com invocação direta é que ela adiciona complexidade na sua topografia sem dar visibilidade através de ferramentas. •

Princípio da Ausência de Estado de Serviço

Heurística: Evitar criação de serviços que guardam estados. Heurística: Em serviços onde é necessário guardar estados, pode-se utilizar a linguagem WS-BPEL para gerenciar o estado. Heurística: Utilizar a transferência de informações de estado (bases de dados, serviços utilitários, mensagens). 111

O gerenciamento de informações de estado em excesso pode comprometer a disponibilidade e a escalabilidade de um serviço. Serviços são desse modo, idealmente projetados para manter uma condição de independência de estado sempre que apropriado. Ao automatizar uma tarefa em particular, um serviço deve processar dados específicos desta tarefa. Estes são referidos como dados de estado. Um serviço pode ser ativo, mas pode não estar comprometido com o processamento de dados de estado. Nesta condição desocupada, o serviço é considerado independente de estado. Um serviço que processa ativamente ou retém dados de estado é classificado como dependente de estado. Apesar de serviços que gerenciam estados poderem ser disponibilizados, a criação dos mesmos deve ser evitada a fim de se garantir escalabilidade, independência entre instâncias do serviço, balanceamento de carga. A linguagem WS-BPEL pode ser utilizada implementar a lógica que necessidade guardar estados de serviços. Alternativamente, pode-se recorrer a um mecanismo de transferência de estado.

8.3.6 Padrões de Projeto para Projeto Orientado a Serviço Os seguintes padrões de projeto devem ser observados como parte do processo de Projeto Orientado a Serviço. Uma descrição mais aprofundada de cada um pode ser encontrada nas respectivas páginas do livro de Thomas Erl (Erl, SOA Design Patterns, 2009), indicadas ao lado de cada padrão: • • • • • • • • • • • • • • • • • • • • • • • • • • •

Abstração de Processo (182) Agente de Serviço (543) Camadas de Serviços (143) Capsula de Legado (441) Centralização de Contratos (409) Centralização de Lógica (136) Centralização de Metadados (280) Centralização de Modelo Canônico (200) Centralização de Políticas (207) Centralização de Processos (193) Centralização de Regras (216) Compensação de Transação com Serviços (631) Composição de Capacidade (504) Contratos Concorrentes (421) Contratos Desacoplados (401) Conversão de Protocolos (687) Encapsulamento de Serviços (305) Enfileiramento Assíncrono (582) Esquema Canônico (158) Fachada de Serviço (333) Implementação Redundante (345) Mensageria Confiável (592) Mensageria Direcionada por Eventos (599) Metadados de Mensageria (538) Normalização de Serviços (131) Protocolo Canônico (150) Recomposição de Capacidade (526) 112

• • • • • • •

Refatoração de Serviços (484) Replicação de Dados de Serviço (350) Repositório de Estado (242) Roteamento Intermediário (549) Transformação de Formatos de Dados (681) Transformação de Modelos de Dados (671) Transação Atômica com Serviços (623)

113

9 IMPLEMENTAÇÃO A implementação está dividida em dois processos, que são normalmente executados em paralelo: Implementar Serviço (executado para cada serviço) e Implementar de Solução.

9.1 Implementar Serviço Devido à ênfase em análise antecipada, modelagem, projeto e no uso de padronizações de projeto, o estágio de implementação de um projeto de SOA é muito mais controlado que em projetos tradicionais. Desse modo, a implementação de serviço é formatada pelas especificações de serviço e de seu projeto de lógica. O processo de implementação de serviço depende da tecnologia de implementação usada que, normalmente, vem acompanhada de suas próprias melhores práticas. De maneira geral, esta metodologia permanece independente da tecnologia. Entretanto, na Arquitetura de Referência, mais especificamente em sua Visão de Implementação, os padrões tecnológicos adotados estão especificados. Em continuidade, na prática, o processo Implementar Serviço tem sua execução dependente do modelo do serviço. A seguir, são apresentados os processos específicos para implementação de serviços agnósticos (entidade e utilitário, Figura 15) e não agnósticos (tarefa, Figura 16, e processo, Figura 17). Ainda, há processos específicos para implementação de serviços proxy (exposição de serviço no barramento de serviços), apresentado na Figura 18. Finalidade

Implementar serviços agnósticos, não agnósticos e proxy.

Entradas

Contrato de Serviço Modelo Canônico de Dados Perfil de Serviço Plano de Testes

Saídas

Código Fonte (Projeto IDE)

Perfis Participantes

R

Analista SOA

X

Arquiteto SOA

X

A

Auditor SOA

I

X

Desenvolvedor

X

Analista de Testes

X

Especialista em Governança SOA Gerente de Projeto

C

X X

114

Figura 15 - Implementar Serviço Utilitário e de Entidade

115

Figura 16 - Implementar Serviço de Tarefa

116

Figura 17 - Implementar Serviço de Processo

117

Figura 18 - Implementar Serviço de Barramento

118

Analisar Perfil de Serviço

Finalidade

Obter entendimento do negócio e do serviço a ser implementado

Entradas

Perfil de Serviço

Saídas

Avaliação de necessidade de desenvolver camada de persistência, desenvolver fachada de integração, composição entre serviços, dentre outros.

Perfis Participantes

R

A

C

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

X

Desenvolvedor

X

X

Especialista em Governança SOA Gerente de Projeto Descrição das Atividades

I

X X

O desenvolvedor avalia o perfil de serviço sob os aspectos de lógica de negócio, arquitetura, mensageria, etc.

119

Projetar Fachada de Banco de Dados (opcional)

Finalidade

Nesta etapa, o analista de BD, de posse das devidas ferramentas, implementa uma fachada para acesso a dados expondo o processamento de persistência do serviço

Entradas

Perfil de serviço

Saídas Perfis Participantes

R

Analista SOA

X

Arquiteto SOA

X

A

C

Auditor SOA

X

Administrador de Dados

X

Desenvolvedor

Descrição das Atividades

X

X

Especialista em Governança SOA Gerente de Projeto

I

X X

A fachada de banco de dados serve como uma camada de abstração do modelo de dados, abstraindo-se assim funções, pacotes, procedures etç..

120

Implementar Rotinas de Banco de Dados

Finalidade

Nesta etapa, o analista de BD, de posse das devidas ferramentas, implementa as rotinas de processamento de persistência do serviço

Entradas

Perfil de serviço

Saídas

Rotinas de Banco de Dados

Perfis Participantes

R

A

C

I

Analista SOA

X

X

Arquiteto SOA

X

X

Auditor SOA Desenvolvedor Administrador de Dados

X X X

X

X

Gerente de Projeto Descrição das Atividades

X Implementar as funcionalidades definidas no perfil de serviços, em nível de persistência.

121

Projetar Fachada de Integração

Finalidade

Projetar Fachada de Integração

Entradas

Perfil de serviço

Saídas Perfis Participantes

R

A

C

I

Analista SOA

X

X

Arquiteto SOA

X

X

Auditor SOA

X

Desenvolvedor

X

Especialista em Governança SOA Gerente de Projeto Descrição das Atividades

X X

Nesta etapa, serão definidos os campos a serem expostos na fachada de serviço para exposição da lógica de solução legada, como por exemplo protocolo de acesso, autenticação e capacidade a ser exposta.

122

Implementar Fachada de Integração

Finalidade

Implementar Fachada de Integração

Entradas

Perfil de Serviço

Saídas

Fachada de Integração

Perfis Participantes

R

A

C

I

Analista SOA

X

X

Arquiteto SOA

X

X

Auditor SOA

X

Desenvolvedor

X

Especialista em Governança SOA Gerente de Projeto

Descrição das Atividades

X X

A fachada de integração tem por objetivo expor dados de sistemas legados utilizando-se abstração necessária para que futuramente essas informações, geralmente em modelos e protocolos de comunicação diferentes dos modelos canônicos e protocolos propostos possam se comunicar com a solução, geralmente através de Capsula de Legados.

123

Implementar Adaptadores (opcional)

Finalidade

Implementar acesso às fachadas disponibilizadas

Entradas

Perfil de Serviço

Saídas

Adaptadores

Perfis Participantes

R

A

C

I

Analista SOA

X

X

Arquiteto SOA

X

X

Auditor SOA

X

Desenvolvedor

X

Especialista em Governança SOA Gerente de Projeto Descrição das Atividades

X X

Implementar adaptadores que acessem os dados fornecidos pelas fachadas disponibilizadas, via adaptador.

124

Mapear transformações de dados

Finalidade

Mapear transformações de dados

Entradas

Perfil de Serviço

Saídas

Transformações de dados

Perfis Participantes

R

A

C

I

Analista SOA

X

X

Arquiteto SOA

X

X

Auditor SOA

X

Desenvolvedor

X

Especialista em Governança SOA Gerente de Projeto

Descrição das Atividades

X X

O desenvolvedor SOA realiza o mapeamento entre o modelo de dados canônico e o modelo de dados providos pelas fachadas disponíveis. Na maioria das vezes há uma disparidade entre essas informações por virem de sistemas legados ou base de dados, essa transformação visa a congruência com o modelo canônico, facilitando assim a reutilização de tais serviços futuramente, uma vez que os modelos que foram transformados poderão ser reutilizados, não sendo necessária nova transformação, e sim um repasse direto de dados.

125

Implementar Fachada

Finalidade

Implementar Fachada

Entradas

Perfil de Serviço

Saídas Perfis Participantes

R

A

C

I

Analista SOA

X

X

Arquiteto SOA

X

X

Auditor SOA

X

Desenvolvedor

X

Especialista em Governança SOA Gerente de Projeto Descrição das Atividades

X X

O desenvolvedor SOA deverá implementar o roteamento das mensagens provenientes do modelo canônico, disponibilizado pelo contrato, para os adaptadores. Também é necessário rotear o caminho inverso das mensagens.

126

Implementar Regras de Negócio

Finalidade

Implementar regras de negócio

Entradas

Regras de Negócio

Saídas Perfis Participantes

R

A

C

I

Analista SOA

X

X

Arquiteto SOA

X

X

Auditor SOA

X

Desenvolvedor

X

Especialista em Governança SOA Gerente de Projeto Descrição das Atividades

X X

Implementar as regras de negócio alinhadas aos padrões definidos na arquitetura de referência.

127

Selecionar tecnologia de orquestração

Finalidade

Definição de tecnologia de orquestração de serviços

Entradas

Perfil de Serviço

Saídas Perfis Participantes

R

A

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

C

I

X

Desenvolvedor

X

Especialista em Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

Nesta etapa é definido o mecanismo de orquestração de serviços, uma vez que cenários como serviços de tarefa e processo geralmente são compostos por outros serviços. Nota: Em geral, deverá se optar por implementar serviços de tarefa como fluxos BPEL (visualizados através da interface de desenvolvimento) e processos de negócios como fluxos BPM/BPMS (visualizados nos Modelos de Processos de Negócio). Alguns processos de negócio automatizados (sem interface humana) são providos de forma otimizada por fluxos BPEL.

128

Definir os componentes da orquestração

Finalidade

Definir serviços da orquestração

Entradas

Perfil de Serviço

Saídas Perfis Participantes

R

A

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

C

I

X

Desenvolvedor

X

Especialista em Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

Nesta etapa os serviços que irão interagir entre si para a execução de cada capacidade deverão ser elencados, levandose em consideração as informações que deverão interagir entre si para a correta execução da capacidade. Ex: BPEL, BPMN

129

Construir lógica de orquestração

Finalidade

Especificação de lógica de orquestração

Entradas

Perfil de Serviço Modelo Canônico Contrato de Serviço

Saídas

Lógica de Orquestração

Perfis Participantes

R

A

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

C

I

X

Desenvolvedor

X

Especialista em Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

Construir lógica de orquestração de serviços participantes de composição, sendo definido estratégias, padrões de projetos e melhores práticas aplicáveis para a interoperabilidade.

130

Construir lógica de processo

Finalidade

Implementar lógica de processo

Entradas

Perfil de Serviço Modelo Canônico Contrato de Serviço

Saídas

Desenho de negócio automatizado

Perfis Participantes

R

A

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

C

I

X

Desenvolvedor

X

Especialista em Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

Construir a lógica do processo, conforme definido no perfil de serviço.

131

Definir objetos de negócio

Finalidade

Definir objetos de negócio

Entradas

Perfil de serviço

Saídas

Objetos de Negócio

Perfis Participantes

R

A

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

C

I

X

Desenvolvedor

X

Especialista em Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

Objetos de negócio são modelos de entidades de negócio reusáveis no processo de negócio. A definição é normalmente realizada a partir de objetos existentes no modelo canônico de dados.

132

Definir dados de processo

Finalidade

Definir dados de estado do processo

Entradas

Perfil de serviço

Saídas

Objetos de dados do processo

Perfis Participantes

R

A

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

C

I

X

Desenvolvedor

X

Especialista em Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

Definir os dados de estado do processo. Essas estruturas são responsáveis pelo armazenamento da informação de estado, sendo utilizadas para iniciar cada tarefa (humana ou serviço) e atualizadas após a execução destes.

133

Definir modelos de tarefa de usuário

Finalidade

Definir modelos de tarefa de usuário

Entradas

Capacidades dos serviços.

Saídas

Entrada de dados, manual, grupo, gerenciamento, aprovação, entres outros.

Perfis Participantes

R

A

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

C

I

X

Desenvolvedor

X

Especialista em Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

Nesta etapa, deverá ser definido qual o tipo de informação o usuário deverá executar. Ex: entrada de dados, manual, grupo, gerenciamento, aprovação, entres outros.

134

Implementar tarefa de usuário

Finalidade

Implementar tarefas que terão interação com o usuário e não poderão ser automatizadas

Entradas

Perfil de Serviço

Saídas

Tarefa de usuário

Perfis Participantes

R

A

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

C

I

X

Desenvolvedor

X

Especialista em Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

Nesta etapa, tarefas pertinentes a interação do usuário e que não poderão ser automatizadas deverão ser planejadas e implementadas. Essas tarefas serão o meio de comunicação a posterior camada de visão da solução.

135

Implementar composição de serviço

Finalidade

Implementar composição de serviço

Entradas

Contrato de Serviço Documento de Candidatos a Serviço ou Perfil de Serviço Arquitetura de Referência

Saídas

Lógica de orquestração

Perfis Participantes

R

A

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

C

I

X

Desenvolvedor

X

Especialista em Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

Associação dos serviços que serão consumidos para execução de tarefas com maior contexto funcional compondo capacidades com diferentes separações de interesse.

136

Implementar regras de negócio centralizadas (opcional)

Finalidade

Implementar regras de negócio centralizadas

Entradas

Regras de Negócio

Saídas

Regras de negócio centralizadas

Perfis Participantes

R

A

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

C

I

X

Desenvolvedor

X

Especialista em Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

Identificar formato da regra de negócio e avaliar tecnicamente qual a melhor opção para implementá-las, podendo ser fórmulas ou tabelas de decisão, por exemplo. (Opcional)

137

Implementar subprocesso (opcional)

Finalidade

Avaliar se existem processos que possam ser reaproveitados

Entradas

Fluxo automatizado

Saídas

Subprocessos

Perfis Participantes

R

A

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

C

I

X

Desenvolvedor

X

Especialista em Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

Avaliar a existência de processos que possam ser reaproveitados durante o ciclo.

138

Definir Business Services

Finalidade

Definição de Business Services

Entradas

Perfil de Serviços

Saídas

Business Services

Perfis Participantes

R

A

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

C

I

X

Desenvolvedor

X

Especialista em Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

Definir Business Service no projeto do Barramento, mediante ao contrato do serviço que terá suas capacidades expostas.

139

Definir Interface REST

Finalidade

Definir Interface REST conforme descrito no Perfil de Serviço.

Entradas

Perfil de Serviço

Saídas

Interface REST

Perfis Participantes

R

A

Analista SOA

X

Arquiteto SOA

X

C

Auditor SOA

I

X

Desenvolvedor

X

Especialista em Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

Definir Interface REST conforme descrito no Perfil de Serviço.

140

Desenvolver Transformações

Finalidade

Transformar modelos dispares

Entradas

Modelos canônicos Perfil de Serviços Sistema Legado Adaptadores de Dados

Saídas

Transformação de dados

Perfis Participantes

R

A

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

C

I

X

Desenvolvedor

X

Especialista em Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

Apesar da recomendação de evitar transformações, em alguns cenários, transformação de modelos e protocolos são necessários para a correta execução da capacidade. Cenários como transformação de dados provenientes de adaptadores de banco de dados, sistemas legados dentre outros usualmente possuem dados em formato diferente ao definido canonicamente, sendo a transformação necessária para comunicação.

141

Desenvolver Roteamento

Finalidade

Implementar roteamento

Entradas

Perfil de Serviço

Saídas

Mensagens de roteamento

Perfis Participantes

R

A

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

C

I

X

Desenvolvedor

X

Especialista em Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

Definir o roteamento de mensagens entre proxy e business services.

142

Desenvolver Políticas (opcionais)

Finalidade

Definir políticas de serviço

Entradas

Perfil de Serviço

Saídas

Politicas de Serviços definidas

Perfis Participantes

R

A

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

C

I

X

Desenvolvedor

X

Especialista em Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

Adicionar políticas do serviço conforme descrito no perfil de serviço.

143

Tratar erros e exceções

Finalidade

Manipulação de erros e exceções

Entradas

Perfil de Serviço Contrato de Serviço

Saídas

Erros e exceções tratados

Perfis Participantes

R

A

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

C

I

X

Desenvolvedor

X

Especialista em Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

Quando da execução de um fluxo cenários inesperados podem ocorrer, é responsabilidade do Desenvolvedor ponderar em quando os cenários inesperados devem ser tratados ou passados adiante.

144

Testar Serviço (Unitário)

Finalidade

Testar implementação de serviço

Entradas

Endpoint de serviço Perfil de Serviço

Saídas

Projeto IDE (código fonte)

Perfis Participantes

R

Analista SOA

X

Arquiteto SOA

X

A

C

Auditor SOA

X

Desenvolvedor

X

Analista de Testes

X

X

Especialista em Governança SOA Gerente de Projeto Descrição das Atividades

I

X X

X

Após a implementação da capacidade é importante validar se a capacidade se comporta como o esperado em dados cenários.

145

Apoiar Implementação

Finalidade

Apoiar a implementação

Entradas

Perfil de Serviço

Saídas Perfis Participantes

R

Analista SOA

X

Arquiteto SOA

X

A

Desenvolvedor Gerente de Projeto

Descrição das Atividades

C

I

X X Nesta etapa, o analista de governança SOA em conjunto com os arquitetos e analistas SOA, avaliam se os resultados dos produtos estão de acordo com os padrões definidos.

146

Aprovar Implementação

Finalidade

Aprovar a implementação disponibilizada.

Entradas

Perfil de Serviço Projeto IDE (código fonte)

Saídas

Aprovação

Perfis Participantes

R

Analista SOA

X

Arquiteto SOA

X

A

C

Auditor SOA

X

Desenvolvedor

X

Especialista em Governança SOA Gerente de Projeto

Descrição das Atividades

I

X X

Nesta etapa, o analista de governança SOA, avalia se os resultados dos produtos estão de acordo com os padrões definidos.

147

9.1.1 Visibilidade do Processo de Desenvolvimento A Figura 19 apresenta a visão dos artefatos de entrada e saída para este processo.

Figura 19 - Entradas e Saídas da fase Implementar Serviço

148

9.2 Implementar Solução Devido ao esforço realizado antecipadamente por parte do Analista SOA e Arquiteto SOA a etapa de implementação da Solução tem um peso muito menor em relação a outras abordagens, uma vez que os modelos de negócio, regras de negócio, protótipos de telas e demais definições já foram analisados. Nesta etapa, a camada de apresentação é realizada, bem como suas interações com as camadas de processo e de serviço, de modo a agrupar todos os componentes da solução. Finalidade

Implementar a solução completa de automação

Entradas

Modelo de Processo de Negócio Modelo de Informação Regras de Negócio Protótipo de Telas Perfis de Interface Perfis de Serviço Arquitetura da Solução Plano de Testes

Saídas

Projeto IDE (código fonte)

Perfis Participantes

R

A

C

Analista SOA

X

Arquiteto SOA

X

Auditor SOA Desenvolvedor

I

X X

Especialista em Governança SOA

X

Gerente de Projeto

X

149

Figura 20 - Implementar Solução

150

Analisar Arquitetura da Solução

Finalidade Entradas

Arquitetura da Solução Perfil de Serviço Protótipo de Tela

Saídas

Arquitetura de Solução revisada

Perfis Participantes

R

A

Analista SOA

X

Arquiteto SOA

X

C

Auditor SOA

I

X

Desenvolvedor

X

Especialista de Infraestrutura SOA

X

Especialista em Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

Nesta etapa o desenvolvedor irá buscar no perfil serviço as capacidades a serem disponibilizadas através de camada de visão.

151

Implementar Componentes de Visualização (telas)

Finalidade

Desenvolver componentes de visualização

Entradas

Perfil de Serviço Protótipo de Telas

Saídas

Componentes de visualização (telas)

Perfis Participantes

R

A

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

C

I

X

Desenvolvedor

X

Especialista de Infraestrutura SOA

X

Especialista em Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

Nesta etapa os componentes de interface gráfica são padronizados quanto ao uso. Ex: FW3, frameworks de camada de visão.

152

Implementar Controladores de Apresentação

Finalidade

Implementar controladores

Entradas

Perfil de Serviço Protótipo de Telas

Saídas

Controladores

Perfis Participantes

R

A

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

C

I

X

Desenvolvedor

X

Especialista de Infraestrutura SOA

X

Especialista em Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

Em uma solução MVC a camada de Controladoria é a intermediária entre a camada de Modelo e Visão. No caso da implementação proposta, os modelos canônicos atuam como a camada de Modelo, invocando-se após isso as capacidades de cada serviço para execução das operações desejadas.

153

Implementar Bindings de serviços

Finalidade Entradas Saídas

Definir a comunicação entre camada de visão e parâmetros necessários para comunicação com serviços Perfil de Serviço Protótipo de Telas Bindings de serviços

Perfis Participantes

R

A

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

C

I

X

Desenvolvedor

X

Especialista de Infraestrutura SOA

X

Especialista em Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

Os bindings são as ligações necessárias para a comunicação dos parâmetros passados via interface ao serviço que se deseja consumir.

154

Implementar Políticas (opcional)

Finalidade

Definir políticas de serviço

Entradas

Perfil de Serviço Políticas definidas

Saídas

Politicas implementadas

Perfis Participantes

R

A

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

C

I

X

Desenvolvedor

X

Especialista de Infraestrutura SOA

X

Especialista em Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

Adicionar políticas à camada de visão conforme descrito no perfil de serviço.

155

Testar Solução

Finalidade

Testar implementação de solução

Entradas

Modelo de Processo de Negócio Modelo de Informação Regras de Negócio Perfis de Interface Perfis de Serviço Arquitetura da Solução Plano de Testes

Saídas

Projeto IDE (código fonte)

Perfis Participantes

R

A

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

C

I

X

Desenvolvedor

X

Especialista em Governança SOA

X

Gerente de Projeto

X

Descrição das Atividades

Após a implementação da tela é importante validar se a mesma se comporta como o esperado em dados cenários.

156

Aprovar Implementação

Finalidade

Aprovar a implementação disponibilizada.

Entradas

Modelo de Processo de Negócio Modelo de Informação Regras de Negócio Protótipo de Telas Perfis de Serviço Arquitetura da Solução Projeto IDE (código fonte)

Saídas

Aprovação

Perfis Participantes

R

A

C

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

X

Desenvolvedor

X

Especialista em Governança SOA Gerente de Projeto Descrição das Atividades

I

X X

Nesta etapa, o analista de governança SOA, avalia se os resultados dos produtos estão de acordo com os padrões definidos.

157

Apoiar Implementação

Finalidade

Apoiar a implementação

Entradas

Modelo de Processo de Negócio Modelo de Informação Regras de Negócio Protótipo de Telas Perfis de Serviço Arquitetura da Solução

Saídas Perfis Participantes

R

Analista SOA

X

Arquiteto SOA

X

Descrição das Atividades

A

C

I

Diferentemente de outras abordagens, em uma Arquitetura Orientada a Serviços Analistas SOA e Arquitetos SOA trabalham em conjunto para a elaboração dos contratos, assim como nas etapas anteriores, onde, apesar do Analista SOA ser responsável por elencar os serviços candidatos, o Arquiteto SOA participava ativamente na compreensão como um todo. Nesta etapa o Arquiteto atua como referência ao Desenvolvedor, ajudando-o na compreensão da arquitetura, melhores padrões de projeto e melhores práticas como um todo.

158

Visibilidade do Processo de Desenvolvimento A Figura 21 apresenta a visão dos artefatos de entrada e saída para este processo.

Figura 21 - Entradas e Saídas do processo Implementar Solução

159

10 TESTES O processo de desenvolvimento de software envolve uma série de atividades onde as chances de falhas humanas são bastante significativas. Erros podem surgir nas diversas etapas do ciclo de vida do produto, desde a sua concepção (especificação dos requisitos) até estágios posteriores (análise, design, implementação) do desenvolvimento [Pressman, Engenharia de Software, 7ª Edição]. Dentro deste contexto, surge a necessidade de desenvolvimento de uma estratégia para testes de software. Antecipadamente, diversas tratativas sobre o que se remete aos princípios de testes estão determinadas nessa Metodologia de Desenvolvimento SOA (atividades, tarefas e notas descritas nos tópicos 9.1.e 9.2). Esses tratamentos encontram, ainda, suporte em diversas assertivas e diretrizes apontadas na Arquitetura de Referência SOA. As assertivas na AR-SOA dão suporte ao uso de ferramentas específicas selecionadas para atendimento aos devidos fins de testes. O que se espera é que nas atividades envolvidas no processo de desenvolvimento de uma aplicação SOA (assim como para uma solução tradicional) exista a formação de roteiro e scripts mínimos e específicos que possam ser executados, de forma que cada elemento da solução como serviços ou composições, fluxos representados pelos serviços de tarefas (BPEL) e fluxos de processos de negócio visualizados junto ao Modelo de Processos de Negócio (que interligam telas ou processos de negócio mais complexos) possam ser testados completamente ao final de todo ciclo de desenvolvimento de uma solução, bem como a solução como um todo. Assim, a estratégia de teste de software incorpora atividades que incluem planejamento de testes, projetos de casos de testes, execução dos testes e coleta e avaliação dos dados resultantes. A estratégia de testes deve ser elaborada de forma a acomodar testes de baixo e alto nível. Os testes de baixo nível têm por objetivo verificar a implementação de um serviço específico, enquanto os testes de alto nível buscam validar as principais funções do sistema de acordo com a especificação dos requisitos (Documento de Modelagem de Negócio e Regras de Negócio). O processo de teste consiste das seguintes atividades, que apesar de serem apresentadas sequencialmente, podem ser realizadas de forma concorrente: • • •

Planejar Testes Implementação e Execução dos Testes Validação e Documentação

Diferentes objetivos podem ser almejados com a execução de testes: • • • •

Encontrar defeitos nos serviços. Ganhar confiança sobre o nível de qualidade nos serviços Prover informações para realização das correções necessárias Garantir uma qualidade de desempenho mínimo para o serviço

De acordo com International Software Testing Qualifications Board (ISTQB), “no processo de teste, diferentes pontos de vista levam a diferentes objetivos. Por exemplo, no teste feito em desenvolvimento, o principal objetivo pode ser causar o maior número de falhas possíveis, de modo que os defeitos no software possam ser identificados e resolvidos. Em alguns casos o

160

principal objetivo do teste pode ser avaliar a qualidade do software (não com a intenção de encontrar defeitos), para prover informações sobre os riscos da implantação do sistema em um determinado momento aos gestores” [Syllabus,2011]. Reconhecido esses princípios, entende-se que para realização de teste finais - e independentes da inferência do processo de desenvolvimento - os documentos de entrada do próprio processo de desenvolvimento podem dar suporte à essa atividade finalística, a saber: •

Perfis de Serviços: documentação fundamental na definição dos serviços e suas capacidades / operações, e que detalha todas as restrições formais no atendimento de cada uma dessas (capacidades / operações).

•

Documento de Regras de Negócio: composto pela lista de requisitos funcionais e não funcionais a serem compridos pela solução.

•

Perfil de Interfaces (regras de validação nas interfaces): define padrões de tratamento de entrada de dados na interface.

•

Plano de Teste: define as estratégias de testes e de avaliação a serem adotadas para testar serviços e composições, integrações e desempenho. Podem, ainda, fornecer uma ideia das possíveis deficiências arquiteturais a serem avaliadas com mais profundidade (agregadas em processos / subprocessos de negócio). O Plano de Testes dá suporte a coordenação e condução dos testes, pois explicita ainda os níveis de teste a serem abordados de acordo com os tipos de testes a serem executados (unitários (serviços e composições), integrações, desempenho e aceitação), o escopo de requisitos à serem testados. Por fim, no Plano de Testes são definidas as ferramentas e ambientes a serem utilizados para a realização dos cenários de teste referentes a cada processo / subprocesso do negócio, com a devida disponibilização de Manuais / Especificações da Interface de das Ferramentas de Suporte a Testes.

Ainda, antes do fechamento do processo metodologicamente imposto nessa MDS-SOA, testes de carga finalísticos são executados de acordo com requisitos específicos analisados e desenvolvidos durante a atividade de Projeto de Serviços de forma a dar suporte ao cumprimento da avaliação dos requisitos não-funcionais de desempenho em carga.

10.1 Testar Serviço A Figura 22 apresenta o modelo de processo para execução de testes. As descrições das atividades são apresentadas a seguir.

161

Figura 22 - Testar Serviço

162

Planejar Testes de Serviços

Finalidade

O planejamento de testes tem por finalidade definir os roteiros de teste (cenários) e casos de testes a serem seguidos como referência durante a execução dos testes (e que é acompanhado do plano de testes que contém a estratégia e a descrição do ferramental utilizado). Nesta etapa são definidos o escopo e casos gerais (scripts ou não) para a execução de cada área de testes. O planejamento dos testes é uma atividade que pode ser iniciada durante as atividades de Modelagem de Negócio, e tem como elemento / documento de referência o Plano de Testes.

Entradas

Documento de Regras de Negócio Modelo de Processo de Negócio (BPM/BPMS) Perfis de Interface Perfil do Serviço Plano de Testes (referencial) Modelo de Informação

Saídas

Roteiro de Testes (incluindo os casos de teste)

Perfis Participantes

R

A

Analista de Processos de Negócio Analista de Testes

C

I

X X

Analista SOA

X X

X

Arquiteto SOA

X

Arquiteto de Software

X

Auditor SOA

X

Desenvolvedor SOA

X

X

Gerente de Projeto Área de Negócio / Área Gestora

Descrição das Atividades

X X

X O planejamento dos testes envolve a construção dos Roteiros de Testes (em conformidade com o Plano de Testes, e segundo as necessidades a serem realizadas, e são concretizados nos Casos de Testes). O Plano de Testes é um documento global que contém os elementos necessários para execução de quaisquer testes gerais durante todo o ciclo de desenvolvimento SOA. Ou seja, 163

o Plano de Teste é um documento de referência a ser utilizada na execução de quaisquer testes que envolva solução SOA (template). O Roteiro de Testes agrega os cenários de testes a serem realizados (na forma de Casos de Testes) e que contém os elementos necessários para definição do escopo do teste específico a ser realizado (template). O caso de teste é um conjunto de ações a serem executadas para a validação de uma funcionalidade específica. Tem por objetivo descrever uma condição particular a ser testada. Neste documento devem ser especificados os valores de entrada, pré-condições para execução do teste e os resultados esperados. A criação dos casos de teste pode, ainda, contribuir na identificação de cenários não tratados pelos requisitos do software. Os casos de teste visam garantir a realização dos princípios de testes elementares e/ou testes em composições de serviços e/ou Fluxo BPEL (template). Para cada iteração de testes (cada serviço ou grupo destes que se refiram a serviços de tarefa - BPEL, de entidade ou utilitário), são elaborados Roteiros de Testes que são a descrição dos casos de testes (cenários) a serem realizados (e/ou transformados em scripts), e é composto por um conjunto de condições usadas para testes unitário (capacidade de serviço), principalmente com o foco na descrição de condições particulares a serem testadas. A criação dos casos de teste pode, ainda, contribuir na identificação de cenários não tratados pelos requisitos levantados na fase de Análise Orientada a Serviço. Ainda, um roteiro de Teste descreve os passos necessários para a execução de um caso de teste ou um grupo de casos de testes.

164

Realizar Testes Unitários (Serviços, Composições e Fluxos BPEL) Realizar Testes Unitários (Serviços, Composições e Fluxos BPEL)

Finalidade

Realizar testes em nível estrutural da implementação do serviço que deverão ser aplicados por capacidade de forma a cobrir todos os cenários levantados em fase de Modelagem de Negócio.

Entradas

Documento de Regras de Negócio Modelo de Processo de Negócio (BPM/BPMS) Perfis de Interface Perfil do Serviço Plano de Testes (referencial) Roteiro de Teste Modelo de Informação

Saídas

Resultado dos documentação.

Perfis Participantes

testes

para

posterior R

registro A

Analista de Processos de Negócio Analista de Testes

C

/ I

X X

X

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

X

Desenvolvedor SOA Gerente de Projeto

Descrição das Atividades

X

X

X X

Realizar testes que essencialmente referem-se as atividades de testes de caixa branca, visando garantir os princípios de manutenibilidade e legibilidade dos códigos de serviços e composições de serviços ou dos fluxos de serviços de tarefa, bem como – e fundamentalmente – a execução de testes de caixa preta que serão realizados pela injeção de mensagens em todas as capacidades de serviços segundo os casos de testes elaborados e análise dos resultados obtidos.

165

Realizar Testes Mínimos de Desempenho

Finalidade

Esses testes mínimos antecedem os testes de integração pois visa garantir, mesmo em ambiente de desenvolvimento, um tempo aceitável para realização de cada serviço ou capacidade de serviço. Dependendo de seu resultado, pode envolver a interrupção dos testes e ou completa ou parcial de refatoração do serviço ou a aplicação de padrões de projeto SOA que possibilitem o atingimento de princípios mínimos aceitáveis de escalabilidade, disponibilidade e previsibilidade computacional.

Entradas

Documento de Regras de Negócio Modelo de Processo de Negócio (BPM/BPMS) Perfis de Interface Perfil do Serviço Plano de Testes (referencial) Modelo de Informação

Saídas

Resultados dos testes elementares de desempenho realizados

Perfis Participantes

R

A

Analista de Testes

X

X

C

I

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

X

Desenvolvedor SOA

X

X

Gerente de Projeto

X

Área de Negócio / Área Gestora

Descrição das Atividades

X

X

Testar o desempenho de uma determinada capacidade pode ser um grande desafio, uma vez que os ambientes de desenvolvimento, homologação e produção podem possuir arquiteturas e especificações diferentes, além do que do SLA poder não estar completamente definido. Porém existem desempenhos mínimos que uma determinada capacidade deve prover de forma que o conjunto ou parte estejam “funcionando adequadamente”, ou seja por tempo excessivo de processamento de dados ou seja, por perca de dados que podem não ser detectadas na fase de implementação. Porém, apesar de ser possível a avaliação de um desempenho mínimo aceitável, o verdadeiro desempenho da solução somente poderá ser avaliado em etapas posteriores, após integração de todos os elementos que compõem a solução, e sob ambientes de homologação e /ou produção.

166

Validar e Documentar os Resultados de Testes de Serviços

Finalidade

Esta atividade tem como objetivo dar clareza aos desenvolvedores dos resultados obtidos acerca dos testes unitários e de desempenho mínimo dos serviços / capacidades, bem como estabelece uma documentação formal de testes em geral.

Entradas

Resultados dos testes

Saídas

Relatório de Execução de Testes (template)

Perfis Participantes

R

A

Analista de Testes

X

X

Analista SOA

C

I

X

X

Arquiteto SOA

X

Auditor SOA

X

Desenvolvedor SOA

X

X

Gerente de Projeto

X X

Área de Negócio / Área Gestora

X

Esta atividade tem como ponto focal a documentação com a devida evidenciação (e.g. telas de erro, lista de registros não gravados, etc) dos erros encontrados bem como a sua quantificação para avaliação dos retrabalhos / esforços adicionais necessários.

Descrição das Atividades

Tem por função suportar a realimentação das atividades inerentes ao desenvolvimento do produto na correção das falhas e /ou identificação de requisitos não cumpridos, isto é, atender aos princípios de MANUTENÇÃO CORRETIVA. Em determinadas situações, que envolvam uma revisão intempestiva de regras de negócio ou adequação de nova infraestrutura, podem atender também os princípios de MANUTENÇÃO ADAPTATIVA.

167

Figura 23 - Realizar Testes Unitários

168

Validar entradas/saídas/Exceções

Finalidade

Validar entradas, saídas e Exceções

Entradas

Documento de Regras de Negócio Modelo de Processo de Negócio (BPM/BPMS) Perfis de Interface Perfil do Serviço Plano de Testes (referencial) Roteiro de Teste Modelo de Informação

Saídas

Resultado dos testes para posterior registro / documentação.

Perfis Participantes

R

A

Analista de Testes

X

X

C

I

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

X

Desenvolvedor SOA Gerente de Projeto

X

X

X X

Durante a execução dos testes unitários, devem ser avaliados os possíveis fluxos de dados que atravessam a interface de cada capacidade de cada serviço (entrada / processamento e saída), pois, antes que qualquer outro princípio de teste possa ser considerado válido, é necessário, antes, garantir que esse processamento ocorra corretamente. Descrição das Atividades

Assim, os casos de testes devem incluir valores de dados no cumprimento de situações de conformidade com os requisitos – DÁDOS VÁLIDOS - bem como prever situações de exceção, onde os dados não estão em conformidade – DADOS INVÁLIDOS (e.g. abaixo ou acima de máximos e mínimos de valores). Essas situações derivam nos dois passos explicitados a seguir.

169

Verificar dados válidos

Finalidade

Verificar dados válidos

Entradas

Roteiro de Testes Documento de Regras de Negócio

Saídas

Regras de Negócio Validadas Erros Identificados

Perfis Participantes

R

A

Analista de Testes

X

X

C

I

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

X

Desenvolvedor SOA Gerente de Projeto

X

X

X X

Dados válidos são entradas e saídas esperadas pelo sistema, e pertencem ao atendimento de requisitos segundo um fluxo de processo padrão (“caminho feliz”). Descrição das Atividades

A corretude e expectativas de saídas esperadas se encontram definidos junto aos casos de testes, e geram resultados que devem ser documentados de forma a evidenciar o correto funcionamento do serviço.

170

Verificar dados Inválidos

Finalidade

Verificar dados Inválidos

Entradas

Roteiro de Testes Documento de Regras de Negócio

Saídas

Regras de Negócio Validadas Erros Identificados

Perfis Participantes

R

A

Analista de Testes

X

X

C

I X

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

X

Desenvolvedor SOA

X

Gerente de Projeto

X

X X

Dados inválidos são entradas e saídas de dados não esperados pelo sistema. Neste sentido existem duas situações a serem tratadas: • Descrição das Atividades •

Ou o sistema não consegue processar o dado (gerando uma exceção). Ou o sistema comporta a entrada de dados como se não houvessem suas restrições (restrição / regra de negócio não desenvolvida).

Esses também geram resultados que devem ser documentados de forma a evidenciar o incorreto funcionamento do serviço.

171

Verificar consistência

Finalidade

Verificar consistência

Entradas

Plano de testes, RN e Perfil de serviço

Saídas

Relatório de testes

Perfis Participantes

R

A

Analista de Testes

X

X

C

I

Analista SOA

X

Arquiteto SOA

X

Auditor SOA

X

Desenvolvedor SOA Gerente de Projeto

Descrição das Atividades

X

X

X X

Verificar se todos os testes foram realizados satisfatoriamente, e se cada capacidade atende o especificado no Roteiro de Testes (e assim atende as Regras de Negócio e o Perfil de Serviço). Essa é a atividade que visa realizar o processo de síntese do observado na aplicação de dados válidos (“caminho feliz”) ou de dados inválidos (“caminhos alternativos”).

172

10.2 Testar Integração A Figura 24 apresenta o modelo de processo para execução de testes de integração e de aceitação / homologação, e suas atividades são descritas a seguir.

Figura 24 - Testar Integração

173

Planejar Testes de Integração

O planejamento de testes de integração tem por finalidade analisar as respostas esperadas na execução de fluxos de processo de negócio (BPM), fundamentalmente, no que se refere a interação / composição de tarefas que envolvem serviços genéricos (tarefas, entidade e utilitários – testados nos Testes Unitários) em conjunto com as atividades humanas (interfaces). Finalidade

Nesta etapa são planejadas as atividades desses testes sobre a forma de elaboração de cenários de manipulação de interfaces e as respostas corretas, tanto no conjunto da execução, bem como em processos referentes ao acesso à infraestrutura (persistência de dados, notificações aos usuários, entre outros). Como qualquer Planejamento de Testes, envolve os documentos Plano de Testes (template), Roteiro de Testes (template) e os seus Casos de Testes (template), anexos.

Entradas

Saídas

Documento de Regras de Negócio Modelo de Processo de Negócio (BPM/BPMS) Perfis de Interface Perfil do Serviço Plano de Testes (referencial) Modelo de Informação Roteiro de Testes

Perfis Participantes

R

A

Analista de Processos de Negócio Analista de Testes

C

I

X X

Analista SOA

X X

X

Arquiteto SOA

X

Arquiteto de Software

X

Auditor SOA

X

Desenvolvedor SOA

X

X

Gerente de Projeto Área de Negócio / Área Gestora

X X

X

174

O planejamento dos testes de integração segue os ritos das atividades inerentes ao planejamento dos testes unitários, usando-se até mesmo dos mesmos documentos para sua realização (entrada) e suas evidenciações (saída).

Descrição das Atividades

Porém, para cada iteração de testes (cada fluxo de processo de negócio BPM/BPEL), são elaborados Roteiros de Testes que são a descrição dos casos de testes (cenários) a serem realizados, e é composto por um conjunto de condições usadas para testes dos processos, principalmente com o foco na descrição de condições particulares a serem testadas (até mesmo regras de restrições nas interfaces). A criação dos casos de teste pode, ainda, contribuir na identificação de alternativas de melhor uso das interfaces na forma de MANUTENÇÂO ADAPTATIVA.

175

Realizar Testes de Integração Realizar Testes de Integração

Finalidade

Os testes de integração referem-se à interligação / composição / integração de serviços sob fluxos dos processos de negócio na forma de coreografias entre os serviços elementares, composições e atividades humanas (interfaces). Assim, testes de integração são testes de caixa preta, e que são realizados após a etapa de testes de serviços, e visam validar a conformidade da solução quando a comunicação entre/com outros serviços.

Entradas

Documento de Regras de Negócio Modelo de Processo de Negócio (BPM/BPMS) Perfis de Interface Perfil do Serviço Plano de Testes (referencial) Roteiro de Teste Modelo de Informação

Saídas

Resultado dos testes para posterior registro / documentação.

Perfis Participantes

R

A

Analista de Processos de Negócio Analista de Testes

C

I

X X

X

Analista SOA

X

Arquiteto SOA

X

Arquiteto de Software

X

Auditor SOA

X

Desenvolvedor SOA

X

X

Gerente de Projeto Área de Negócio / Área Gestora

Descrição das Atividades

X X

X Os testes de integração são testes de mais alto nível e somente fazem sentido após os testes unitários dos elementos que compõem cada fluxo de negócio. Admitemse passos antecipados de testes de apenas pequenos grupos de tarefa de fluxo (subtarefas) antes que todos os serviços terem sidos testados (obviamente que os serviços elementares usados nesse grupo já deverão estar testados).

176

Assim, de posse do documento de Modelagem de Negócio, Regras de Negócio, Perfis de Interface e Perfis de Serviços, o teste se dá pela execução total ou parcial de fluxo de processos de negócio usando as interfaces devidamente conectadas e já construídas antecipadamente. Alguns princípios de facilidade de uso podem modificar requisitos iniciais de interface e funcionamento, que podem causar impacto nos desenvolvimentos já realizados, na forma de uma MANUTENÇÃO ADAPTATIVA.

177

Realizar Testes de Desempenho em Carga

Esses testes visam garantir que, em ambiente com carga compatível com a carga real do sistema, os processos de negócio serão executados em um tempo de execução mínimo aceitável (SLA).

Finalidade

Idealmente esses testes ocorrem em ambiente de homologação, com dados compatíveis em volume e dispersão (“em Carga”) ao ambiente de produção. Dependendo de seu resultado, pode envolver a completa ou parcial refatoração do serviço ou aplicação de padrões de projeto SOA que possibilitem o atingimento de princípios de escalabilidade, disponibilidade e previsibilidade computacional.

Entradas

Documento de Regras de Negócio Modelo de Processo de Negócio (BPM/BPMS) Perfis de Interface Perfil do Serviço Plano de Testes (referencial) Roteiro de Testes

Saídas

Resultados dos testes mínimos de carga e desempenho realizados

Perfis Participantes

R

A

Analista de Testes

C

I

X

X

Analista SOA

X

Arquiteto SOA

X

Arquiteto de Software

X

Auditor SOA

X

Desenvolvedor SOA

X

Analista de Testes

X

X

Gerente de Projeto

X

Área de Negócio / Área Gestora

Descrição das Atividades

X

X

Esta etapa envolve a execução do processo de negócio (integrado) sem o foco no seu correto funcionamento, mas sim no atendimento de seleções e transporte de um volume de dados massivo (e.g. escolher situações aonde irão ser tratados o maior volume de dados possível). Um tempo excessivo de processamento de dados pode gerar a necessidade de implementação de melhorias ou otimizações nos processos sistêmicos testados.

178

Desta forma, se os tempos de respostas nessas situações são considerados “intratáveis”, isto pode resultar na necessidade de aplicação de princípios de MANUTENÇÂO CORRETIVA. Se os tempos são considerados “razoáveis”, isto pode implicar no apontamento da necessidade da execução de princípios de MANUTENÇÂO ADAPTATIVA.

179

Validar e Documentar os Resultados de Testes de Integração

Finalidade

Esta atividade tem como objetivo dar clareza aos desenvolvedores dos resultados obtidos a cerca dos testes de integração, com o apontamento de medidas que visem a boa execução dos testes de aceitação / homologação.

Entradas

Resultados dos testes

Saídas

Relatório de Execução dos Testes (template)

Perfis Participantes

R

A

Analista de Processos de Negócio Analista de Testes

C

I

X X

Analista SOA

X X

X

Arquiteto SOA

X

Arquiteto de Software

X

Auditor SOA

X

Desenvolvedor SOA

X

X

Gerente de Projeto

X X

Área de Negócio / Área Gestora

X

Esta atividade tem como ponto focal a documentação com a devida evidenciação (e.g. telas de erro, registro de tempo decorrido / timeout, etc) dos erros encontrados bem como a sua quantificação para avaliação dos retrabalhos / esforços adicionais necessários. Descrição das Atividades

Tem por função suportar a realimentação das atividades inerentes ao desenvolvimento do produto na correção das falhas e /ou identificação de requisitos não cumpridos, isto é, atender aos princípios de MANUTENÇÃO CORRETIVA. Em determinadas situações, que envolvam uma revisão intempestiva de regras de negócio, podem atender também os princípios de MANUTENÇÃO ADAPTATIVA.

180

Realizar Teste de Aceitação / Homologação

Realizar Testes de Aceitação / Homologação

Finalidade

Permitir ao usuário de negócio avaliar se solução atende aos requisitos de negócio definidos durante todo ciclo de vida de desenvolvimento da solução.

Entradas

Solução implantada em Ambiente de Homologação Modelos de Processos de Negócio (BPM/BPMS) Documento de Regras de Negócio Perfis de Interface

Saídas

Relatório de Testes. Termo de Aceite emitido pelo usuário de negócio

Perfis Participantes

R

A

C

Administrador de Dados

I X

Analista de Processos de Negócio

X

X

X

Analista SOA

X

X

X

Analista de Testes

X

X

X

Arquiteto SOA

X

Arquiteto de Software

X

Auditor SOA

X

Desenvolvedor SOA

X

Gerente de Projeto

X

Área de Negócio / Área Gestora Administrador de Dados

Descrição Atividades

das

X

X

X X

O objetivo do Teste de Aceitação / Homologação é garantir que todos os requisitos funcionais e não funcionais estão sendo atendidos pelo sistema, bem como a correta realização junto aos registros na infraestrutura (banco de dados, envio de e-mail). Essa correção deve atender aos requisitos como identificados junto ao levantamento do negócio (documento de Modelagem de Negócio e Regras de Negócio). A execução do Teste de Aceitação/Homologação é responsabilidade e propriedade do cliente ou usuário de negócio. O teste de aceitação tem início após concluídos os testes unitários e de integração e quando todos os resultados de testes tiverem sido validados/aprovados (na completa corretude de execução) e quando quaisquer ajustes adicionais ou erros de interface de usuário identificados em fases de testes anteriores já tiverem sido corrigidos. 181

De maneira geral, um teste de aceite é um encerramento no processo de entrega do produto (podendo, porém, apontar novas necessidades de ajuste), sendo a solução ou processo de negócio considerado como validado com sucesso quando funciona conforme esperado pelo usuário e apresenta conformidade com os requisitos de negócio.

182

Figura 25 - Testes de Integração

183

Preparar Testes de Integração

Finalidade

Avaliar e dar integridade as necessidades de dados e de serviços de infraestrutura suplementares, de forma ser possível realizar os testes de integração

Entradas

Solução implantada em Ambiente de Homologação Modelos de Processos de Negócio (BPM/BPMS) Documento de Regras de Negócio Perfis de Interface Roteiro de Teste Perfis de Serviço

Saídas

Checklist informal do estabelecimento das necessidades de todos os recursos (e.g., de infraestrutura, de dados, etc) para realização dos testes de integração.

Perfis Participantes

R

A

C

Administrador de Dados Analista de Testes

I X

X

X

Analista SOA

X

Arquiteto SOA

X

X

Arquiteto de Software

X

X

Desenvolvedor SOA

X

Gerente de Projeto

X

X

Administrador de Dados

X

X

Descrição das Atividades

X

X

Nesta atividade todos os papéis responsáveis pela execução completa da solução ou de um processo de negócio são responsáveis por prover as necessidades mínimas para realização completa e integral dos testes de integração. Em adição, roda essa preparação irá preparar o ambiente para a realização dos Testes de Aceitação / Homologação

Testes de Atividades de Serviço (Caminhos das mensagens)

Finalidade

Realiza os testes de todos os caminhos possíveis a serem realizados pelo fluxo de processos de negócio / da solução

Entradas

Fluxos BPM Documento de Regras de Negócio Perfil de Interfaces Perfil de Serviços Roteiro de Testes

Saídas

Relatório de Execução de Testes (template)

Perfis Participantes

C

I

Administrador de Dados

X

X

Analista de Processos de Negócio

X

X

Analista SOA

X

X

Arquiteto SOA

X

X

Arquiteto de Software

X

X

Auditor SOA

X

X

Desenvolvedor SOA

X

X

Gerente de Projeto

X

X

Área de Negócio / Área Gestora

X

X

Administrador de Dados

X

X

Analista de Testes

Descrição das Atividades

R

X

A

X

Essa atividade compreende a execução de todas as rotas possíveis do fluxo de processo / solução. "A cadeia de troca de mensagens realizada em suporte à execução de tarefas específicas (ou processos de negócio) é referida como uma atividade de serviço. Uma atividade de serviço representa apenas a troca de dados em mensagens com/entre serviços. Esse nível de abstração limita a consciência acerca da natureza do processamento subjacente de serviços participantes em composições (serviços e composições tratados junto aos testes unitários)." (SOAGlossary.com). Neste sentido, em relação à uma composição, uma atividade de serviço representa os cenários de execução que ocorrem entre serviços compostos e/ou complexos (e.g. um processo de negócio ou uma solução).

185

Uma atividade de serviço representa essencialmente "o que acontece" quando uma instância de uma composição de serviços (ou processo de negócio) está em execução. Uma parte fundamental do projeto SOA é o mapeamento de diferentes cenários de execução de atividades de serviços possíveis. (T. Erl., Módulo 3 – Certificação SOASchool) Neste sentido, os fluxos idealizados são avaliados no que se refere a troca de mensagens entre os mesmos. São então “ignorados” os processamentos realizados na lógica de cada serviço e tratado se os serviços se interagem plenamente. Um dos pontos fundamentais dessa atividade é validar as respectivas interações entre processos sistêmicos e as respostas apresentadas nas interfaces.

186

Testes de Casos-Limites e Notificações (Regras de Negócio)

Finalidade

Realiza os testes das situações de interfaces e processos que o sistema deve tratar e das corretas notificações ao usuário que uma atividade sistêmica do mesmo afeta diretamente uma ou mais Regras de Negócio.

Entradas

Fluxos BPM Documento de Regras de Negócio Perfil de Interfaces Perfil de Serviços Roteiro de Testes

Saídas

Relatório de Execução de Testes (integração)

Perfis Participantes

C

I

Administrador de Dados

X

X

Analista de Processos de Negócio

X

X

Analista SOA

X

X

Arquiteto SOA

X

X

Arquiteto de Software

X

X

Auditor SOA

X

X

Desenvolvedor SOA

X

X

Gerente de Projeto

X

X

Área de Negócio / Área Gestora

X

X

Administrador de Dados

X

X

Analista de Testes

R

X

A

X

Essa atividade compreende a execução de testes sobre as situações ao qual o usuário deve ser corretamente informado que está “ferindo” alguma Regra de Negócio (e.g. Alocar um Magistrado que se encontra no seu período de férias). Descrição das Atividades

Em diversas situações sistêmicas, os impeditivos oriundos de Regras de Negócio devem ser tratados antecipadamente, porém, nem sempre a solução é possível. Assim, o usuário deve ser corretamente informado do impeditivo, evitando que o sistema registre o evento.

187

Testes de Usabilidade (Regras de Negócio e Interface)

Finalidade

Realiza os testes de forma a garantir que a usabilidade do sistema ou processo de negócio está adequada as condições impostas pelos diversos usuários do sistema.

Entradas

Fluxos BPM Documento de Regras de Negócio Perfil de Interfaces Perfil de Serviços Roteiro de Testes

Saídas

Relatório de Execução de Testes (integração)

Perfis Participantes

C

I

Administrador de Dados

X

X

Analista de Processos de Negócio

X

X

Analista SOA

X

X

Arquiteto SOA

X

X

Arquiteto de Software

X

X

Auditor SOA

X

X

Desenvolvedor SOA

X

X

Gerente de Projeto

X

X

Área de Negócio / Área Gestora

X

X

Administrador de Dados

X

X

Analista de Testes

R

X

A

X

Essa atividade compreende a validação dos requisitos de interface segundo facilidades apresentadas aos Área de Negócio / Área Gestora durante a fase de prototipação. Descrição das Atividades

Assim, esta atividade compreende a avaliação cumprimento de compromissos assumidos consistência entre as ações sistêmicas e realizações efetivas da solução / processo negócio.

do de as de

188

Testes em Pesquisas / Filtros (Contextos)

Finalidade

Realiza testes de forma a garantir que todo filtro ou pesquisa de seleção de registros funcionem adequadamente conforme seleções realizadas pelo usuário.

Entradas

Fluxos BPM Documento de Regras de Negócio Perfil de Interfaces Perfil de Serviços Roteiro de Testes

Saídas

Relatório de Execução de Testes (integração)

Perfis Participantes

C

I

Administrador de Dados

X

X

Analista de Processos de Negócio

X

X

Analista SOA

X

X

Arquiteto SOA

X

X

Arquiteto de Software

X

X

Auditor SOA

X

X

Desenvolvedor SOA

X

X

Gerente de Projeto

X

X

Área de Negócio / Área Gestora

X

X

Administrador de Dados

X

X

Analista de Testes

R

X

A

X

Em diversas situações de sistemas de processamento de dados ou de sistemas de informações gerenciais, filtros de pesquisa/seleção de dados ocorrem naturalmente nessas soluções.

Descrição das Atividades

Esta atividade visa garantir que em qualquer atividade de filtro / seleção de dados, os mesmos resultem na apresentação de conjuntos de dados compatíveis com a seleção / filtro realizado. Isto irá impedir um mau uso do sistema / processo de negócio pelo usuário e irá prover ao mesmo o que foi efetivamente selecionado.

189

Testes de Uso Compartilhado (Acesso multiusuário)

Finalidade

Realiza testes de forma a garantir o uso da solução ou processo de negócio por diversos usuários simultaneamente, garantindo a independência de ações entre esses (tal qual provido por modelo multiinquiinos).

Entradas

Fluxos BPM Documento de Regras de Negócio Perfil de Interfaces Perfil de Serviços Roteiro de Testes

Saídas

Relatório de Execução de Testes (integração)

Perfis Participantes

C

I

Administrador de Dados

X

X

Analista de Processos de Negócio

X

X

Analista SOA

X

X

Arquiteto SOA

X

X

Arquiteto de Software

X

X

Auditor SOA

X

X

Desenvolvedor SOA

X

X

Gerente de Projeto

X

X

Área de Negócio / Área Gestora

X

X

Administrador de Dados

X

X

Analista de Testes

Descrição das Atividades

R

X

A

X

Em diversas situações sistêmicas de processos de execução em ambientes multiusuários é comum que exista um tratamento que dê garantia que a ação simultânea de um usuário não irá gerar inconsistências na execução de tarefas de negócio. Essa atividade é executada através da realização de testes por múltiplos usuários simultâneos. Ema quaisquer casos adversos a implementação desses recursos, o sistema deverá impedir a ação de usuários simultâneos.

190

Testes de Processamento em Lote (Processos sem interface)

Finalidade

Realiza testes de forma a garantir que processos sistêmicos excepcionais que não proveem interfaces (e.g. um processamento mensal de geração de Portarias) seja executado em sua completude sem erros. Essa atividade somente é aplicável em processamentos em lote sem a intervenção do usuário (inexistência de interfaces)

Entradas

Fluxos BPM Documento de Regras de Negócio Perfil de Serviços Roteiro de Testes

Saídas

Relatório de Execução de Testes (integração)

Perfis Participantes

C

I

Administrador de Dados

X

X

Analista de Processos de Negócio

X

X

Analista SOA

X

X

Arquiteto SOA

X

X

Arquiteto de Software

X

X

Auditor SOA

X

X

Desenvolvedor SOA

X

X

Gerente de Projeto

X

X

Área de Negócio / Área Gestora

X

X

Administrador de Dados

X

X

Analista de Testes

Descrição das Atividades

R

X

A

X

Algumas tarefas sistêmicas SOA são de execução automática e sem a intervenção do usuário. Essa atividade visa dar garantia da realização completa e correta de processos sistêmicos que atendem a este fim.

191

10.3 Teste de Aceitação A Figura 26 apresenta o modelo de processo para execução de testes de aceitação/ homologação, e suas atividades são descritas a seguir.

Figura 26 - Teste de Aceitação

192

Testar Solução em ambiente de Homologação

Finalidade

Validação da solução pelo Cliente em ambiente de homologação.

Entradas

Regras de Negócio Perfil de Interface Documento de Regras de Negócio

Saídas

Relatório de Testes (Aceitação ou Erros Identificados)

Perfis Participantes

R

Área de Negócio / Cliente

X

Analista de Testes

X

A X

C

I

X

X

X

X

Analista SOA

X

Arquiteto SOA

X

Descrição das Atividades

Após concluído os testes de integração, solução é disponibilizada em ambiente de homologação para validação pelo cliente. Os testes devem ser realizados com base no Documento de Modelo de processos de Negócio, documento de Regras de Negócio, Perfil de Interface, casos de teste e roteiro de teste.

193

Elaborar Relatório de Aceitação

Finalidade

Documentar Resultado da Homologação

Entradas

Resultado Testes de Homologação (Aceitação)

Saídas

Relatório de Execução de testes (template) Documento de Aceitação / Homologação

Perfis Participantes

R

A

Área de Negócio

X

X

Analista de Testes

X

C

I

X

X

Analista SOA

X

Arquiteto SOA

X

Descrição das Atividades

Após concluídos os testes em ambiente de homologação, a área de Negócio deve documentar o resultado da homologação em um Relatório de testes. O relatório tem por objetivo oficializar a aceitação ou não da solução implementada. Relatórios parciais podem ser gerados durante o processo de homologação para registro de evidências e criação de demanda para correção das possíveis falhas identificadas pelo cliente.

194

Manter Serviços

Manter Serviços

Finalidade

Realizar a Manutenção de Serviços

Entradas

Relatório de Aceitação

Saídas

Manutenção de Serviço realizada

Perfis Participantes

R

A

Administrador de Dados

C

I

X

Analista de Processos de Negócio

X

X

Analista de Testes

X

X

Analista SOA

X

X

Arquiteto SOA

X

X

Desenvolvedor

X

X

Designer de Interface de Usuário

X

X

Descrição das Atividades

As atividades devem ser executadas conforme descrito na seção 12.3

195

Realizar Testes de Integração

Realizar Testes de Integração

Finalidade

Realizar testes de integração em manutenção realizada

Entradas

Perfil de Serviço Perfil de Interface Relatório de Aceitação

Saídas

Testes de Integração realizados

Perfis Participantes

R

A

C

Administrador de Dados

I X

Analista de Processos de Negócio Analista de Testes

X X

X

Analista SOA

X

Arquiteto SOA

X

Arquiteto de Software

X

Auditor SOA

X

Desenvolvedor SOA

X

X

Gerente de Projeto

X

Área de Negócio / Área Gestora Descrição Atividades

X

das

X

As atividades devem ser executadas conforme descrito na seção 10.2

196

11 IMPLANTAÇÃO Esse processo visa transferir todos os recursos para execução de serviços SOA (de tarefas orquestradas, de tarefas, de entidade, utilitários, bem como de recursos agregados como transformações, arquivos de políticas, etc) de um ambiente de desenvolvimento local – baseado na MDS Local – para os devidos ambientes de homologação e produção, com foco na publicação de contratos dentro dos ambientes de MDS da homologação ou produção. Muito do conhecimento dos recursos e tecnologias envolvidas na implantação de serviços podem ser compreendidos na leitura antecipada da Arquitetura de Referência SOA no capítulo 8, principalmente no que se refere à seção 8.4 (com adicionais nas seções, 8.5, 8.6 e 8.7). Nota: o conhecimento dos tópicos e conteúdo sobre a implantação de serviços presentes nas seções apontadas da Arquitetura de Referência SOA são considerados importantes e mandatórios. A implantação está dividida em dois processos, que são normalmente executados em paralelo: Implantar Serviço (executado para cada serviço) e Implantar de Solução.

11.1 Implantar Serviço O processo de implantação de serviço depende da tecnologia de implementação utilizada (vide AR-SOA) e que, normalmente, vem acompanhada de suas melhores práticas específicas. De maneira geral, esta metodologia deve ser distinta e permanecer independente da tecnologia, entretanto, a Arquitetura de Referência, mais especificamente em sua Visão Física (Implantação), provê e define alguns padrões tecnológicos de referência à serem adotados (tais como o uso de MDS Local para os desenvolvedores e ambientes de MDS centralizados específicos para cada ambiente (desenvolvimento, homologação e produção). O processo é apresentado na Figura 7 e suas atividades são descritas a seguir. Finalidade

Implantar serviços agnósticos, não agnósticos e proxy.

Entradas

Arquitetura Tecnológica Corporativa Arquitetura de Referência SOA Artefatos de Governança de Serviços Projeto (IDE - código fonte)

Saídas

Implantação de Serviço

Perfis Participantes

R

Arquiteto SOA

A

C

X

Auditor SOA Especialista em Governança SOA Especialista em Infraestrutura SOA Gerente de Projeto

I X

X X

X X

197

Figura 27 - Implantar Serviço

198

Implantar Serviços

Finalidade

Implantação de Serviço (em ambiente de homologação e/ou produção).

Entradas

Projeto IDE Serviço (desenvolvidos ou homologado)

Saídas

Serviço Implantado

Perfis Participantes

R

Arquiteto SOA

X

A

Auditor SOA Especialista em Governança SOA

Gerente de Projeto

Descrição das Atividades

I

X

X

X

X

X

Especialista em Infraestrutura SOA Desenvolvedor

C

X X

X

X X

X

X

X

Realizar a implantação dos serviços e seus elementos em ambiente de produção. Neste sentido, existem regras na sequência de implantação de serviços como descritos na Arquitetura de Referência SOA que devem ser de conhecimento antecipado (AR-SOA seções 8.4, 8.5, 8.6 e 8.7)

199

Verificar e Corrigir Erros de Implantação

Finalidade

Verificar e Corrigir Erros de Implantação

Entradas

Perfil de Serviço Implantação de Serviço

Saídas

Serviço Implantado (corrigido)

Perfis Participantes

R

A

Arquiteto SOA

C X

Auditor SOA

X

Especialista em Governança SOA

X

Especialista em Infraestrutura SOA Desenvolvedor Gerente de Projeto Descrição das Atividades

I

X X

X

X X X

Mapear possíveis erros provenientes dos testes de implantação e realizar as correções necessárias, principalmente no que se refere ao acesso a datasources, e namespaces.

200

Apoiar Implantação Nota: essa atividade é válida tanto para Especialistas de Infraestrutura SOA como para Arquitetos SOA. Como a atividade é conjunta, apenas uma atividade é descrita. Finalidade

Apoiar a implantação

Entradas

Perfil de Serviço Implantação de Serviço

Saídas

Suporte ao desenvolvedor / Governança

Perfis Participantes

R

Arquiteto SOA

C

I

X

X

X

Especialista em Infraestrutura SOA

X

X

X

Desenvolvedor

X

X

X

Gerente de Projetos

Descrição das Atividades

A

X

Garantir o suporte a erros na implantação dos serviços, principalmente no que se refere ao acesso a datasources, e namespaces. Assim, especialistas de Infraestrutura e Arquitetos SOA podem ser acionados, quando necessário, para apoiar a identificação de erros não previstos que venham a ocorrer durante a implantação de um serviço.

201

Publicar e Catalogar Serviço

Finalidade

Disponibilizar serviços no portfólio de serviços da organização.

Entradas

Serviço

Saídas

Serviços publicados

Perfis Participantes

R

A

Auditor SOA

C

I X

Especialista em Governança SOA

X

X

Especialista em Infraestrutura SOA

X

Desenvolvedor

X

Gerente de Projeto

X

Descrição das Atividades

Impor que os serviços implantados estejam disponíveis para consumo no portfólio de serviços coorporativos seguindo os padrões estabelecidos pela Arquitetura de Referência. As atividades devem ser executadas conforme descrito no tópico 12.1 - Exposição de Serviços do Inventário desta MDS.

202

11.2 Implantar Solução Esse processo visa transferir todos os recursos necessários para execução de processos de negócio (e,g, recursos de interfaces, fluxos BPMS) de um ambiente de desenvolvimento local para os devidos ambientes de homologação e produção. Muito do conhecimento dos recursos e tecnologias envolvidas na implantação de soluções podem ser compreendidos na leitura antecipada da Arquitetura de Referência SOA no capítulo 8 dessa, principalmente no que se refere às suas seções 8.5, 8.6 e 8.7. Nota: o conhecimento dos tópicos e conteúdo sobre a implantação de soluções presentes nas seções apontadas da Arquitetura de Referência SOA são considerados importantes e mandatórios. A implantação está dividida em dois processos, que são normalmente executados em paralelo: Implantar Serviço (executado para cada serviço) e Implantar de Solução. Cabe-se apontar que alguns referenciais sobre a implantação de serviços e soluções encontram-se detalhados junto a Arquitetura de Referência SOA. O processo é apresentado na Figura 28 e suas atividades são descritas a seguir. Finalidade

Implantar solução de automação completa.

Entradas

Arquitetura Tecnológica Corporativa Arquitetura de Referência SOA Artefatos de Governança de Serviços Arquitetura da Solução Projeto IDE (código fonte)

Saídas

Implantação de Serviço

Perfis Participantes

R

Arquiteto SOA

A

C

I

X

Auditor SOA

X

Especialista em Governança SOA

X

Especialista em Infraestrutura SOA Gerente de Projeto

X X

203

Figura 25 - Implantar Solução

204

Verificar se a implantação de serviços necessários está correta

Finalidade

Verificar os componentes já implantados (implantação de serviços) e os a serem implantados (implantação da solução).

Entradas

Elementos de Interface e fluxo BPMS

Saídas

Lista de componentes a serem implantados

Perfis Participantes

R

A

Arquiteto SOA

C X

Auditor SOA

X

Especialista em Governança SOA

X

Especialista em Infraestrutura SOA

X

X

Desenvolvedor

X

Design de Interfaces

X

Gerente de Projeto

Descrição das Atividades

I

X Identificar o conjunto de elementos que compõem a solução. Neste sentido é analisado se os componentes da solução (serviços de tarefa, entidade e utilitários) estão corretamente instalados. Caso não estejam, reporta a Governança a necessidade de que seja verificada a atividade de “Implantar Serviços” até que a implantação dos mesmos esteja adequada. Em seguida, prossegue na verificação da realização correta do processo de “Implantar solução”.

205

Implantar Fluxos (BPMS)

Finalidade

Implantar os modelos de fluxos de processos de negócio

Entradas

Fluxo BPMS

Saídas

Fluxos Implantados

Perfis Participantes

R

A

Arquiteto SOA

C X

Auditor SOA

X

Especialista em Governança SOA

X

Especialista em Infraestrutura SOA

X

X

Desenvolvedor

X

Design de Interfaces

X

Gerente de Projeto Descrição das Atividades

I

X Implantar e disponibilizar em ambiente de homologação e de produção os fluxos de processo de negócio.

206

Implantar Interfaces

Finalidade

Implantação da Camada de Apresentação

Entradas

Camada de apresentação (IU)

Saídas

Camada de apresentação (IU) disponibilizada

Perfis Participantes

R

A

Arquiteto SOA

C

I

X

Auditor SOA

X

Desenvolvedor

X

Design de Interfaces

X

Especialista de Infraestrutura SOA Especialista em Governança SOA Gerente de Projetos

Descrição das Atividades

X X

X X

Implantar e disponibilizar em ambiente de homologação e de produção camada de Apresentação (UI). Refere-se a publicação junto ao repositório JBoss associado à camada de interface aonde consta toda os códigos referentes ao framework de interface AngularJS denominado FW3. Para realizar o processo de deploy de interface de usuário, seus artefatos (arquivos html, css e javascript e etc) são atualizados no repositório que contém o código fonte de desenvolvimento (SVN), e, em seguida, scripts internos detectam as alterações e iniciam o processo de build (Jenkins).

207

Implantar Recursos de Infraestrutura

Finalidade

Implantação de recursos de infraestrutura necessários, fundamentalmente de objetos de Banco de Dados. Outros recursos de infraestrutura (e.g. como servidores de e-mail), devem ser configurados caso sejam necessários.

Entradas

Script de Banco de Dados e configurações de outros recursos

Saídas

Banco de dados disponível para utilização, e acesso a outros recursos endereçados (configurados e resolvidos).

Perfis Participantes

R

A

Arquiteto SOA

X

Especialista de Infraestrutura SOA

X

Especialista em Governança SOA

X

Desenvolvedor

X

Design de Interfaces

X

Administrador de Banco de Dados

X

Descrição das Atividades

I

X

Auditor SOA

Gerente de Projetos

C

X

X Implantar e disponibilizar em ambiente de homologação e/ou produção quaisquer recursos de infraestrutura (e.g. a camada de persistência de dados). Como exemplo, pode ser necessária a criação/alteração de objetos de Banco de Dados como tabelas, views, pacotes, funções, entre outros. A implantação será realizada conforme regras internas de implantação e configuração de infraestrutura subjacente estabelecidas.

208

Verificar e Corrigir Erros de Implantação

Finalidade

Validar Implantação da solução como um todo

Entradas

Implantação de Solução

Saídas

Implantação de Solução

Perfis Participantes

R

A

Arquiteto SOA

C X

Auditor SOA

X

Desenvolvedor

X

Design de Interfaces

X

Especialista de Infraestrutura SOA

X

Especialista em Governança SOA

X

Gerente de Projetos Descrição das Atividades

I

X X X

A implantação da solução deve ser validada através dos testes possíveis de serem realizados em ambiente de produção. Normalmente são realizados testes funcionais em operações somente de leitura.

209

Apoiar Implantação Nota: essa atividade é válida tanto para Especialistas de Infraestrutura SOA como pata Arquitetos SOA. Como a atividade é conjunta, apenas uma atividade é descrita. Finalidade

Apoiar a implantação de solução

Entradas

Pacotes de solução de interfaces Fluxos BPMS Documentação adicional de outros recursos de infraestrutura

Saídas

Suporte ao desenvolvedor / Governança

Perfis Participantes

R

Arquiteto SOA

C

I

X

X

X

Especialista em Infraestrutura SOA

X

X

X

Desenvolvedor

X

X

X

Gerente de Projetos

Descrição das Atividades

A

X

Garantir o suporte a erros na implantação de soluções (fluxos BPMS, elementos de interfaces – UI e outros recursos de infraestrutura. Assim, especialistas de Infraestrutura e Arquitetos SOA podem ser acionados, quando necessário, para apoiar a identificação de erros não previstos que venham a ocorrer durante a implantação de soluções.

210

Liberar Solução

Finalidade

Disponibilizar a solução implantada

Entradas

Implantação de Solução

Saídas

Implantação de Solução

Perfis Participantes

R

A

Especialista de Infraestrutura SOA Especialista em Governança SOA Gerente de Projetos

Descrição das Atividades

C

I X

X

X X

Envolve uma garantia antecipada de que todos os serviços e recursos necessários para testes de soluções e, eventualmente para o Teste de Aceitação / Homologação, estejam realizados.

211

11.2.1 Visibilidade do Processo de Desenvolvimento A Figura 29 apresenta a visão dos artefatos de entrada e saída para este processo.

Figura 26 - Entradas e Saídas da fase Implantar Solução

212

12 VITALIDADE DE SERVIÇOS 12.1 Exposição de Serviços do Inventário Finalidade

Publicar serviços do inventário em repositório corporativo de serviços.

Entradas

Contrato de Serviço Perfil de Serviço

Saídas

Repositório de Serviços (atualizado)

Perfis Participantes

R

Especialista de Governança SOA Arquiteto SOA

A

C

X

X

I

X

213

Figura 27 - Exposição de Serviços do Inventário

214

Criar catálogo de serviço

Finalidade

Criar catálogo desserviços

Entradas Saídas

Catálogo de inventário criado

Perfis Participantes

R

Especialista de Governança SOA Arquiteto SOA Descrição das Atividades

A

C

X

X

I

X O ambiente para gerenciamento de configurações de catálogo de inventário é instalado e configurado

215

Consumir/ Desenvolver Serviços

Finalidade

Consumir e Desenvolver novos Serviços a serem gerenciados no inventário

Entradas

Serviços

Saídas

Gerenciar Serviços como ativos de TI

Perfis Participantes

R

A

Arquiteto SOA

X

X

Desenvolvedor

Descrição das Atividades

C

I

X

X

Uma vez configurado o repositório de serviços, ao se construir um novo serviço, informações que ajudem na sua gestão de ciclo de vida podem ser populadas, vinculando-se o serviço como um ativo da empresa. Quando da existência de um catálogo de serviços, usuários podem consumir serviços existentes através da busca taxonômica, o que favorecerá que se evite a sobreposição de contexto funcional na criação de novos serviços, favorecendo o retorno de investimento.

216

Identificar ativos a serem governados

Finalidade

Identificar os ativos de TI que serão governados pela equipe de negócio

Entradas

Serviços

Saídas

Ativos de TI

Perfis Participantes

R

Especialista de Governança SOA Arquiteto SOA Descrição das Atividades

A

C

X

X

I

X Uma vez instalado e configurado o ambiente que dará suporte à descoberta de serviços, é importante definir os ativos que serão governados pela empresa.

217

Definir metadados associados a ativos

Finalidade

Definir metadados associados a ativos de TI

Entradas

Ativos de TI

Saídas

Definição de Metadados de ativos de TI

Perfis Participantes

R

Especialista de Governança SOA Arquiteto SOA

Descrição das Atividades

A

C

X

X

I

X Os metadados são informações a respeito de um dado ativo utilizadas como auxílio na descoberta dos mesmos. Através da utilização de metadados é possível descobrir serviços já implementados através de informações que o classifiquem, sendo um facilitador para se evitar a sobreposição de contextos funcionais, dentre outros.

218

Criar taxonomia para organização de ativos

Finalidade

Criar taxonomia para organização de Ativos de TI

Entradas

Ativos de TI

Saídas

Taxonomia de Ativos de TI definida

Perfis Participantes

R

Especialista de Governança SOA Arquiteto SOA

Descrição das Atividades

A

C

X

X

I

X Taxonomia pode ser entendida como uma estrutura para classificação de forma hierárquica, facilitando a identificação e localização dos mesmos. Um dos principais objetivos de tal classificação é facilitar o acesso a informação, melhorando a comunicação entre os diversos usuários e mantenedores do sistema.

219

Popular repositório com ativos e metadados

Finalidade

Popular repositório com Ativos de TI e metadados

Entradas

Ativos de TI

Saídas

Repositório populado

Perfis Participantes

R

Especialista de Governança SOA Arquiteto SOA

Descrição das Atividades

A

C

X

X

I

X Nesta etapa, o repositório anteriormente criado deve ser populado com ativos e metadados, a fim de fomentarem carga não só para descobertas de serviços como para geração de relatórios de acompanhamento. Os benefícios da população de repositório com tais ativos são: • • •

Mais serviços podem ser definidos em um catálogo de ativos que crescem constantemente; Menor custo para popular o inventário de serviços; Maior entendimento de como e quando gerenciar um dado ativo.

220

Gerenciar o ciclo de vida dos ativos

Finalidade

Gerenciar o ciclo de vida dos ativos

Entradas

Ativos de TI

Saídas

Ativos de TI gerenciados

Perfis Participantes

R

Especialista de Governança SOA Arquiteto SOA Descrição das Atividades

A

C

X

X

I

X O processo de fluxo de ciclo de vida de um ativo se torna a base para o processo de automação. Tal gerenciamento permite o alinhamento do ciclo de vida do ativo com o ciclo de vida do desenvolvimento de software, podendo-se definir ou modificar papéis associados a usuários e responsabilidades.

221

Gerenciar alterações

Finalidade

Gerenciar alterações de Ativos de TI

Entradas

Ativos de TI

Saídas

Ativos de TI gerenciados

Perfis Participantes

R

Especialista de Governança SOA Arquiteto SOA

Descrição das Atividades

A

C

X

X

I

X O gerenciamento de ativos impacta não somente em um maior entendimento do negócio, como também na compreensão dos impactos decorrentes das alterações propostas nos ativos catalogados. Mecanismos como subscrição e notificação podem ser utilizados para facilitar a organização da empresa. Dentre os principais benefícios desta abordagem pode-se citar: • •

Redução de riscos dado entendimento do impacto proposto pelas alterações; Aumento de visibilidade e comunicação em caso de alterações.

222

Monitorar progresso com relatórios

Finalidade

Monitorar progresso com relatórios

Entradas

Ativos de TI

Saídas

Relatório de Ativos de TI

Perfis Participantes

R

Especialista de Governança SOA Arquiteto SOA

A

C

X

X

I

X A equipe de negócio pode revisar relatórios de documentação e reuso de ativos catalogados, sendo possível definir formulas para mensurar cada serviço, o que permite dentre outras coisas:

Descrição das Atividades

• • •

Capacidade de demonstrar o retorno de investimento; Habilidade de monitorar tendências e progresso de cada serviço; Consistência e uniformidade no valor de serviço.

223

Monitorar Performance em tempo de execução

Finalidade

Monitorar Performance de Ativos de TI em tempo de execução

Entradas

Ativos de TI

Saídas

Monitoramento de performance em tempo de execução de Ativos de TI

Perfis Participantes

R

Especialista de Governança SOA Arquiteto SOA

A

C

X

X

I

X A equipe de negócio pode revisar a performance das métricas em tempo de execução de serviços implantados. Essas métricas podem ajudar a avaliação de ajustes a serem desenvolvidos na solução. Dentre os principais benefícios desta etapa estão:

Descrição das Atividades

•

•

Capacidade de visualizar métricas definidas, e gerar maior credibilidade em nível de negócio para os ganhos obtidos com os serviços; Automação de processos de geração de métricas se torna benéfico por facilitar a criação e acompanhamento de novas métricas.

224

12.2 Gerenciar Configuração e Versionamento O processo de versionamento é uma etapa transversal ao desenvolvimento da solução como um todo. Problemas como a versão oficial a ser implantada em ambientes de desenvolvimento, homologação e produção, bem como o controle de acesso concorrente a arquivos, o que poderia gerar uma constante alteração e sobrescrita de arquivos que dois ou mais usuário desejem alterar ao mesmo tempo são problemas recorrentes dessa abordagem. Atualmente existem vários mecanismos para o controle de versionamento de arquivos no mercado. A Arquitetura de Referência e o processo de Governança SOA deverão definir os sistemas e padronizações de gerenciamento de versões e configuração. O processo é apresentado na Figura 28 e suas atividades são descritas a seguir. Finalidade

Gerenciamento de versões e configuração de software.

Entradas

TBD

Saídas

TBD

Perfis Participantes

R

Arquiteto SOA

C

I

X

Auditor SOA Desenvolvedor

A

X X

Especialista em Governança SOA

X

Gerente de Projeto

X

225

Figura 28 – Gerenciar Configuração e Versionamento

226

Criar repositório remoto

Finalidade

Criação de repositório remoto

Entradas

Arquivos iniciais de versionamento

Saídas

Repositório remoto definido e disponível

Perfis Participantes

R

A

C

Analista de Processos de Negócio

I X

Analista SOA

X

Arquiteto SOA

X

Auditor SOA Desenvolvedor Gerente de Projeto

Descrição das Atividades

X

X X

Nesta primeira etapa um repositório remoto é criado contendo as definições iniciais a serem versionadas e disponibilizas quando da sincronização de tal repositório. É importante não só criar o repositório e disponibilizá-lo, quanto adicionar permissões de manipulação dos diretórios e arquivos do mesmo, sendo criados usuários e grupos de usuários que irão ter perfis focados em tais manipulações no repositório remoto.

227

Criar repositório local

Finalidade

Criação de repositório local

Entradas

Dados a serem versionados

Saídas

Repositório local

Perfis Participantes

R

A

C

Analista de Processos de Negócio

I X

Analista SOA

X

Arquiteto SOA

X

Auditor SOA Desenvolvedor Gerente de Projeto

Descrição das Atividades

X

X X

Nesta etapa é criado localmente um repositório na máquina das pessoas que irão interagir com as configurações existentes no repositório remoto. O repositório local é o repositório em que as alterações de cada pessoa são testadas inicialmente e, posteriormente sincronizadas novamente com o repositório remoto a fim de disponibilizar tais alterações a todos os usuários que estão trabalhando em equipe no repositório remoto. O repositório local nada mais é que uma estrutura de diretórios utilizada para se comunicar com a estrutura dos diretórios do repositório remoto.

228

Vincular repositório local a repositório remoto

Finalidade

Sincronizar repositório local a remoto para futuras transferências de arquivos

Entradas

Repositório remoto Repositório local

Saídas

Sincronização de repositório remoto e local

Perfis Participantes

R

A

C

Analista de Processos de Negócio

I X

Analista SOA

X

Arquiteto SOA

X

Auditor SOA Desenvolvedor Gerente de Projeto

Descrição das Atividades

X

X X

Nesta etapa o repositório local será vinculado ao repositório remoto, o que permitirá a transferência de dados do repositório local para o remoto a fim de disponibilizar alterações a outros usuários do mesmo repositório, bem como a obtenção de alterações disponibilizadas por outros usuários. O acesso ao repositório remoto se dá por login e senha, que são dados intransferíveis, capazes de identificar as alterações que cada usuário executou quando da sincronização com o repositório remoto.

229

Adicionar/ Altera arquivos

Finalidade

Adicionar arquivos ao repositório local

Entradas

Arquivos a serem adicionados ou alterados ao repositório local

Saídas

Arquivos adicionados

Perfis Participantes

R

A

C

Analista de Processos de Negócio

I X

Analista SOA

X

Arquiteto SOA

X

Auditor SOA Desenvolvedor Gerente de Projeto

Descrição das Atividades

X

X X

Nesta etapa o usuário adiciona ou altera arquivos em seu repositório local que interagirão com os outros arquivos do repositório. É importante ressaltar que as alterações contidas nesses arquivos se dão ainda em repositório local, onde o usuário terá um ambiente controlado para testá-las antes de submetê-las ao repositório remoto, e deixar tais alterações passíveis de acesso a todos os demais usuários. Em ambiente local, o usuário pode testar o impacto de suas alterações na solução presente, e em demais soluções que interage com os arquivos alterados ou adicionados.

230

Publicar arquivos adicionados/ alterados

Finalidade

Submeter alterações propostas em repositório local a repositório remoto

Entradas

Arquivos adicionados/ atualizados

Saídas

Arquivos submetidos a repositório remoto

Perfis Participantes

R

A

C

Analista de Processos de Negócio

I X

Analista SOA

X

Arquiteto SOA

X

Auditor SOA Desenvolvedor Gerente de Projeto Descrição das Atividades

X

X X

Nesta etapa ocorre a sincronização de arquivos presentes no repositório remoto com arquivos do repositório local. As adições e alterações propostas anteriormente são agora sincronizadas com as alterações já existentes no repositório remoto.

231

Solucionar conflitos entre arquivos

Finalidade

Corrigir conflitos existentes entre os arquivos dos repositórios local e remoto

Entradas

Arquivos em conflito

Saídas

Conflito de arquivos solucionado

Perfis Participantes

R

A

C

Analista de Processos de Negócio

I X

Analista SOA

X

Arquiteto SOA

X

Auditor SOA Desenvolvedor Gerente de Projeto

Descrição das Atividades

X

X X

Dado acesso concorrente ao repositório remoto, não raras as vezes, dois usuários podem alterar o mesmo arquivo. O primeiro usuário a submeter as alterações terá alterado o repositório remoto, e quando o segundo usuário tentar submeter suas alterações será notificado que a versão do arquivo que este deseja alterar já se encontra em uma versão diferente de quando ele havia sincronizado os arquivos com o repositório. Neste caso, cabe ao segundo usuário comparar os pontos de conflito e corrigir os problemas da junção dos arquivos que foram submetidos anteriormente, enviando então ao servidor remoto uma nova versão do arquivo contendo não só suas alterações como as alterações do primeiro usuário.

232

12.3 Manutenção de Serviço Tradicionalmente, a manutenção de serviço é um processo que ocorre quando na realização de testes são verificadas necessidades de alterações a serem realizadas durante o Ciclo de Vida de Desenvolvimento SOA (correção de erros e bugs). Porém, este processo não está associado exclusivamente a manutenções oriundas de erros e bugs. Ocorrem, ainda, em cenários no qual mudanças de leis, normas e processo, entre outros, acarretarem evoluções do processo já existente. O processo é apresentado na Figura 32 e suas atividades são descritas a seguir. Finalidade

Manutenção de serviços existentes

Entradas

Documento de Manutenção

Saídas

Documento de Manutenção Ordem de Serviço

Perfis Participantes

R

A

Administrador de Dados Analista de Processos de Negócio

C

I

X X

X

Analista de Testes

X

X

Analista SOA

X

X

Arquiteto SOA

X

X

Desenvolvedor

X

X

Designer de Interface de Usuário

X

X

233

Figura 29 - Manutenção de Serviço

234

Elaborar Demanda

Finalidade

Formalizar solicitação de manutenção em solução SOA.

Entradas

Identificação da necessidade de manutenção.

Saídas

Demanda Registrada

Perfis Participantes

R

A

C

I

X

X

X

X

X

X

Administrador de Dados Analista de Processos de Negócio

X

Analista de Testes Analista SOA Arquiteto SOA Desenvolvedor Designer de Interface de Usuário Governança SOA Descrição das Atividades

X

X

Da análise de Relatórios de Execução de Testes, a Área de Negócio ou Governança SOA pode identificar a necessidade de manutenções (corretiva, adaptativa ou evolutiva), e deve registrar demanda para formalização da solicitação de manutenção.

235

Classificar, Priorizar e Aprovar Demanda

Finalidade

Aprovar, priorizar e classificar demanda de acordo com sua natureza em adaptativa, corretiva ou evolutiva.

Entradas

Demanda Registrada.

Saídas

Demanda Aprovada e Classificada, ou Demanda Reprovada.

Perfis Participantes

R

A

C

I

X

X

X

X

Administrador de Dados Analista de Processos de Negócio

X

Analista de Testes Analista SOA Arquiteto SOA Desenvolvedor Designer de Interface de Usuário Governança SOA

X

X

A demanda deve ser analisada sendo, então, aprovada ou arquivada (reprovada). Se aprovada, deve ser priorizada e classificada de acordo com sua natureza:

Descrição das Atividades

•

Manutenção Corretiva: Manutenção reativa realizada durante qualquer etapa do Ciclo de Desenvolvimento de Soluções Orientadas a Serviço. Tem por função suportar a realimentação das atividades inerentes ao desenvolvimento do produto na correção das falhas e /ou identificação de requisitos não cumpridos.

•

Manutenção Adaptativa: É recorrente de situações que envolvam uma revisão intempestiva de regras de negócio ou adequação de nova infraestrutura.

•

Manutenção Evolutiva: Ocorre quando é entendido que um produto deva ser reanalisado e/ou reprojetado de forma a atender novas necessidades ou novos requisitos de negócio ou tecnológicos. Envolve, em geral, a implementação de novos requisitos do usuário ou alterações relacionadas a melhorias referentes aos requisitos funcionais da solução.

Nota: ainda, da descrição desses três tipos, observa-se que as manutenções adaptativas e evolutivas são compatíveis, e que podem se reportar a revisão desde a Modelagem do Negócio (Desenvolvimento de Soluções Orientadas a Serviços).

236

Arquivar Demanda

Finalidade

Arquivar demanda não aprovadas após avaliação da Governança SOA.

Entradas

Demanda Reprovada

Saídas

Demanda Arquivada

Perfis Participantes

R

A

C

I

X

X

X

X

Administrador de Dados Analista de Processos de Negócio

X

Analista de Testes Analista SOA Arquiteto SOA Desenvolvedor

X

Designer de Interface de Usuário

X

Governança SOA Descrição das Atividades

X

X

X

X

Em alguns cenários, demandas evolutivas e/ou adaptativas podem ser classificadas como inviáveis (e.g. um alto custo ou altíssima complexidade para implementação, entre outros casos). Na ocorrência destes cenários, a demanda pode ser arquivada.

237

Analisar Solicitação

Finalidade

Analisar Solicitação de Manutenção para encaminhamento para atividade de implementação.

Entradas

Documento de Manutenção

Saídas

Documento de Manutenção (atualização)

Perfis Participantes

R

A

Analista de Processos de Negócio

X

X

Analista de Testes

X

C

I

X

X

Administrador de Dados

Analista SOA Arquiteto SOA

X

Desenvolvedor

X

Designer de Interface de Usuário

X

Descrição das Atividades

Nesta etapa considerações referentes a solução a ser adotada são analisadas de acordo com Metodologia de Desenvolvimento e Arquitetura de Referência SOA. Em Manutenções corretivas não é necessária a análise prévia de viabilidade de manutenção, uma vez que a não aplicação da correção impacta diretamente no funcionamento da solução.

238

Analisar Viabilidade de Manutenção

Finalidade

Analisar Viabilidade de Manutenção proposta

Entradas

Documento de Manutenção

Saídas

Documento de Manutenção (atualização)

Perfis Participantes

R

A

Analista de Processos de Negócio

X

X

Analista de Testes

X

C

I

X

X

Administrador de Dados

Analista SOA Arquiteto SOA

X

Desenvolvedor

X

Designer de Interface de Usuário

X

Descrição das Atividades

Em caso de manutenções adaptativas ou evolutivas uma avaliação prévia deve ser realizada com o objetivo de definir a viabilidade ou não de implementação da solicitação. Se a solicitação é considerada inviável, a demanda e arquivada. Caso contrário, é encaminhada para implementação.

239

Implementação (Fluxo Principal)

Finalidade

Executar os subprocesso “Implementar Serviço” e “Implementar Solução”, parte da etapa do subprocesso “Implementação” definida no modelo geral desta metodologia SOA.

Entradas

Demanda para solicitação de manutenção Corretiva

Saídas

Manutenção corretiva realizada

Perfis Participantes

R

A

C

I

Administrador de Dados Analista de Processos de Negócio

X

Analista de Testes Analista SOA

X

Arquiteto SOA

X

Desenvolvedor

X

Designer de Interface de Usuário

Descrição das Atividades

X X

Manutenções corretivas são enviadas diretamente para correção para a equipe de desenvolvimento, uma vez que são consideradas demandas cujo objetivo é correção de erros em códigos, fluxos e/ou em outros elementos desenvolvidos, e que estão implementados e disponibilizados para utilização do usuário. As atividades devem ser executadas conforme descrito nas seções 9.1, 9.2 e 9.3.

240

Desenvolvimento de Soluções Orientadas a Serviço

Finalidade

Executar o processo de “Desenvolvimento de Soluções Orientadas a Serviço”, definida no modelo geral desta metodologia SOA (processo global).

Entradas Saídas Perfis Participantes

R

A

C

I

Administrador de Dados Analista de Processos de Negócio Analista de Testes Analista SOA Arquiteto SOA Desenvolvedor Designer de Interface de Usuário

Descrição das Atividades

Manutenções adaptativas e evolutivas, cuja viabilidade é determinada e aceita, essas manutenção podem envolver incorporação/alteração de serviços, composições, fluxos, etc, que podem até mesmo já existir junto ao Inventário de Serviços. Assim entende-se que manutenções evolutivas e adaptativas requerem que o processo metodológico para sua realização siga todas as etapas do Ciclo de Vida de Desenvolvimento SOA, mesmo que alguns passos possam ser ignorados por ser considerados já completos (e.g. se a manutenção evolutiva ou adaptativa não impacta em nenhum esforço de Análise SOA, todo processo de Análise pode ser ignorado). Nota: Considera-se que esta etapa pode ser suportada por toda documentação metodológica da solução ora implantada para consulta durante as atividades de Análise e Projeto de Soluções Orientadas a Servço.

241

Disponibilizar Alteração para Validação

Finalidade

Disponibilizar solução com alterações solicitadas para validação da equipe de Governança e SOA, e posteriormente área de negócio.

Entradas

Solicitação de manutenção concluída

Saídas

Solicitação de manutenção concluída e disponível para implantação

Perfis Participantes

R

Administrador de Dados

X

A

C

I

X

X

Analista de Processos de Negócio Analista de Testes

X X

Analista SOA

X

X

Arquiteto SOA

X

X

Desenvolvedor

X

X

X

Designer de Interface de Usuário

X

X

X

Governança SOA

X

Descrição das Atividades

X

Refere-se as atividades inerente dos Desenvolvedores e/ou dos Designers de Interface de Usuário de empacotamento dos serviços em geral e/ou fluxos observada as atividades inerentes de Governança associada, tais como a atividade de "Gerenciar Configuração e Versionamento" conforme descrito na seção 12.2.

242

Implantar Solução em Ambiente de Homologação

Finalidade

Implantar solução em ambiente de homologação para posterior validação do usuário da solicitação de manutenção solicitada.

Entradas

Solicitação de Manutenção Concluída

Saídas

Solicitação de Manutenção disponível em ambiente de homologação.

Perfis Participantes

R

Administrador de Dados

A

C

I

X

Analista de Processos de Negócio

X

Analista de Testes

X

Analista SOA Arquiteto SOA Desenvolvedor

X

Designer de Interface de Usuário

X

Analista de Infraestrutura Descrição das Atividades

X As atividades devem ser executadas conforme descrito nas seções 11.1 e 11.2. Além disso, deve ser realizada a atividade para a “Exposição de Serviços do Inventário" conforme descrito na seção 12.1.

243

Implantar Solução em Ambiente de Produção

Finalidade

Implantar solução em ambiente de produção para finalização do processo de manutenção.

Entradas

Relatório de Execução de Testes (Testes de Aceitação / Homologação)

Saídas

Solução instalada

Perfis Participantes

R

Administrador de Dados

X

A

C

I

X

X

Analista de Processos de Negócio Analista de Testes

X X

Analista SOA

X

X

X

Arquiteto SOA

X

Desenvolvedor

X

X

X

Designer de Interface de Usuário

X

X

X

Descrição das Atividades

X

X

As atividades devem ser executadas conforme descrito nas seções 11.1 e 11.2. Além disso, deve ser realizada a atividade para a “Exposição de Serviços do Inventário" conforme descrito na seção 12.1.

244

Teste de Aceitação

Finalidade

Validação pela área de negócio da manutenção de serviço solicitada.

Entradas

Manutenção disponibilizada em ambiente de homologação.

Saídas

Manutenção Aprovada ou Reprovada (Devolvida)

Perfis Participantes

R

A

C

Administrador de Dados

I X

Analista de Processos de Negócio

X

X

X

Analista SOA

X

X

X

Analista de Testes

X

X

X

Arquiteto SOA

X

Arquiteto de Software

X

Auditor SOA

X

Desenvolvedor SOA

X

Gerente de Projeto

X

Área de Negócio / Área Gestora Descrição das Atividades

X

X

X

As atividades devem ser executadas conforme descrito na seção 10.3.

245

APÊNDICE A: REFERÊNCIAS BIBLIOGRÁFICAS ABPMP. (2015). BPM CBOK (3ª ed.). Erl, T. (2008). SOA: Principles of Service Design. Crawfordsville, Indiana, EUA: Prentice Hall. Erl, T. (2009). SOA Design Patterns. Crawfordsville, Indiana, EUA: Prentice Hall. Hewitt, E. (2009). Java SOA Cookbook. O'Reilly Media, Incorporated. Josuttis, N. M. (2007). SOA in Practice. Sebastopol, Califórnia, EUA: O'Reilly. Portier, B. (2007). Building SOA Solutions Using the Rational SDP. IBM. SOA Patterns. (s.d.). Fonte: http://www.soapatterns.org van den Heuvel, W.-J., Zimmermann, O., Leymann, F., Lago, P., Schieferdecker, I., Zdun, U., et al. (05 de 2009). Software Service Engineering. PESOS’09, pp. 26-33. SCOTT, Kendall. O Processo Unificado Explicado. 1ª ed. São Paulo: Bookman, 2003. PRESSMAN, RS. Engenharia de software. ... Gerenciamento de Projetos. 7 edição. Rio de Janeiro: Brasport, 2009. Certified Tester Foundation Level Syllabus, Versão 2011br. Tradução realizada pela TAG01 Documentação do BSTQB baseada na versão 2011 do Certified Tester Foundation Level Syllabus do ISTQB.

246

APÊNDICE B: GLOSSÁRIO AGENTE DE SERVIÇO: é um programa direcionado por eventos, capaz de interceptar de forma transparente e processar mensagens enviadas ou recebidas por serviços. Dependendo da plataforma de SOA adotada, agentes de serviços podem ser chamados de “mediadores”, “escutas (listeners)”, “interceptadores”, “manipuladores (handlers)”. A maioria das plataformas de SOA modernas prove um conjunto de agentes de serviços de sistema, mas agentes de serviço podem ser também desenvolvidos. Agentes de serviço não têm uma interface técnica (ou contrato) e, portanto, não são explicitamente invocados. Eles geralmente provêm lógicas altamente reutilizáveis; cada agente é usualmente reusado por muitos serviços e composições de serviços. De uma perspectiva de composição de serviços ou atividade de serviços, agentes de serviço são quase sempre classificados como intermediários. Funções comuns executadas por agentes de serviço incluem roteamento, registro de eventos (logging), validação e processamento relacionado com segurança. Agentes de serviço podem ser parte de uma arquitetura de serviço e podem residir entre arquiteturas de serviço como parte de arquiteturas de composições e inventário. Podem ter eles mesmos sua própria especificação de arquitetura, que podem ser referenciadas pela arquitetura de serviço. Durante o projeto de uma SOA (de qualquer tipo), é preciso determinar a extensão em que os serviços dependerão de agentes de serviços. É possível transferir funções utilitárias comuns para agentes de serviços. Seu uso pode resultar em redução do tamanho de composição de serviços (usualmente pela redução da quantidade de serviços utilitários). AMBIENTE DE DESENVOLVIMENTO: ambiente utilizado por desenvolvedores para a criação do software. O propósito desse ambiente é o desenvolvimento inicial de funcionalidades a serem validadas posteriormente por especialistas que mensurarão se a solução desenvolvida se encontra alinhada com a solução esperada, para depois serem feitos testes no ambiente do usuário final. AMBIENTE DE HOMOLOGAÇÃO: ambiente intermediário entre os ambientes de desenvolvimento e produção. O propósito desse ambiente é a validação da solução proposta em ambiente de desenvolvimento, a fim de evitar inconsistência quando da produção em ambiente de produção. AMBIENTE DE PRODUÇÃO: ambiente final de aplicação, destinado aos usuários finais da mesma. A separação de camadas para implantação da aplicação de solução tem por finalidade o aumento de confiabilidade quando da implantação da solução em ambiente de produção, evitando-se erros e bugs descobertos anteriormente em outros ambientes. ANÁLISE DE PROCESSO: conjunto de atividades que buscam entender e identificar oportunidades de melhoria no processo mapeado/diagramado/modelado. ANÁLISE DE SERVIÇOS CANDIDATOS: etapa da metodologia SOA onde é realizada a concepção global prévia dos serviços a serem criados e dos serviços existentes, a fim de se propor um conjunto de serviços capazes de solucionar um dado cenário proposto. O foco dessa etapa não

247

está na definição precisa dos serviços a serem criados, mas sim em uma proposta inicial a ser validada em etapas posteriores. ANÁLISE DE INVENTÁRIO DE SERVIÇOS: etapa da metodologia SOA focada principalmente na avaliação da necessidade de criação de um serviço. Antes de se criar um serviço é importante constatar se este já existe ou se não sobrepõe o contexto funcional de outro serviço já publicado. Para tanto, consultas no inventário devem ser efetuadas. APLICAÇÕES COMPOSTAS: são soluções de software SOA que realizam os padrões de projeto de abstração e centralização de processos, implementando composições coordenadas de serviço com uso de tecnologia de orquestração e mediação de serviços. Aplicações compostas frequentemente enfatizam o reuso de serviços existentes no inventário de serviços e são implementadas com modelos de processos BPMN 2.0 (Business Process Modeling 2.0) e BPEL (Business Process Execution Language) executados diretamente na Plataforma de SOA e no BPMS (Business Process Management System). ARTEFATO: subproduto concreto produzido e/ou utilizado durante o desenvolvimento de software. Alguns artefatos descrevem a função, a arquitetura e/ou o design do software (ex. contrato de serviço, especificação técnica de serviço, documento de arquitetura de serviço, manual de usuário, código fonte, código executável etc.). Outros estão relacionados com o próprio processo de desenvolvimento (ex. plano de projeto, documento de visão, súmula de reunião etc.). AS-IS: forma informal de se referir ao processo no momento da sua modelagem. Faz referência ao estado “como está” sendo executado o processo pela organização ou estado atual. ATIVIDADES: conjunto de tarefas realizado pelo ator do processo que, em conjunto com as tomadas de decisão e eventos próprios, compõem o processo. ATOR: recurso humano que executa determinada tarefa ou processo. Atores são instâncias de um perfil profissional requerido em determinada parte do processo. AUTOMATIZAÇÃO DE PROCESSO: atitude de tornar o processo automatizado com a utilização da tecnologia, eliminando a interação com os recursos humanos e otimizando o desempenho do mesmo. BPM (GERENCIAMENTO DE PROCESSOS DE NEGÓCIO): disciplina gerencial que integra estratégias e objetivos de uma organização com expectativas e necessidades de clientes, focando em processos ponta a ponta. Engloba estratégias, objetivos, cultura, estruturas organizacionais, papéis, políticas, métodos e tecnologias para analisar, desenhar, implementar, gerenciar desempenho, transformar e estabelecer a governança de processos. BPMN (BUSINESS PROCESS MODEL AND NOTATION): é um padrão aberto internacional de notação gráfica para modelar e desenhar processos de negócios. CAPACIDADE DE SERVIÇO: cada serviço possui seu contexto funcional próprio e distinto, que é constituído de um conjunto de funcionalidades relacionadas ao seu contexto. Essas funcionalidades são referidas como capacidades do serviço. Assim, como serviços são coleções de capacidades relacionadas a um contexto funcional, são as capacidades que resolvem interesses individuais. Um serviço pode ter uma ou mais capacidades. Capacidades associadas ao contexto de um serviço são posicionadas dentro daquele serviço. Capacidades de serviço 248

podem ser expressas em um contrato de serviço. Logo, cada solução orientada a serviço pode ser modelada a partir de ou decomposta em uma coleção lógica com seguintes elementos básicos: • • • •

Capacidades: unidades de trabalho. Serviços: coleção de unidades de trabalho. Processos: agregação coordenada de unidades de trabalho. Mensagens: unidades de comunicação responsável por envolver unidades de trabalho.

Um consumidor de serviço frequentemente invocará uma capacidade específica, ou seja, ele invocará apenas um subconjunto das funcionalidades que um serviço tem para oferecer, e essa funcionalidade associada com uma capacidade pode variar em escopo. CAPACIDADE PROFISSIONAL: define um conjunto de habilidades e competências que serão demandas em um determinado perfil. Essas podem ser recomendadas (capacidades normalmente requeridas para o desempenho da atividade profissional associada ao perfil) ou desejáveis (capacidades complementares que agregam valor à atividade profissional do perfil). CLIENTE: no contexto de Gerenciamento de Processos de Negócio, cliente é a quem são direcionadas as atividades do processo, sendo por elas beneficiado. Pode ser externos ou internos à organização, sendo o foco de uma tarefa, de uma atividade, de um subprocesso, de um processo ou de um macroprocesso. COMPOSIÇÃO DE SERVIÇO: é um agregado de serviços coletivamente composto para automatizar uma tarefa ou processo de negócio em particular. Para qualificar uma composição, pelo menos dois serviços participantes e um iniciador da composição devem estar presentes, senão a interação de serviço representa apenas uma troca ponto a ponto. A composição de serviços depende da habilidade de serviços consumirem-se uns aos outros sem a perda da autonomia de seus contratos e ocultando a lógica dos serviços subsequentes. Todos os princípios de projeto de orientação a serviço são direcionados a suportar serviços como membros de composições complexas. No topo da composição encontramos serviços caracterizados como os controladores de composição (frequentemente referido apenas como "controlador“ ou “mediador”). O projeto do controlador de composição gira em torno da definição de interações efetivas de serviços e da lógica de composição, integrada ao gerenciamento do estado da atividade. COMPOSITE APPLICATIONS: ver Aplicações Compostas. CONTRATO DE SERVIÇO: expressa as meta-informações sobre um serviço e estabelece os termos para seu uso (requisitos para invocar e interagir com o serviço). Para um consumidor de serviço acessar e interagir com um serviço, este deve estar ciente e em conformidade com os requisitos estabelecidos no contrato do serviço. A parte fundamental de um Contrato de Serviço é sua interface técnica, que constitui o contrato técnico do serviço (WSDL + Esquemas de Dados + Políticas). Ele pode (e deve) ser composto ainda de outras informações adicionais, tal como um Acordo de Nível de Serviço (SLA), que descreve características de qualidade de serviço, seus comportamentos e limitações.

249

Em orientação a serviço, o projeto e padronização de contratos de serviço são de fundamental importância, de tal maneira que o princípio de projeto de Padronização de Contrato de Serviço é dedicado à definição padronizada de contratos de serviço. COREOGRAFIA: formaliza a coordenação das interações entre os participantes (entidades envolvidas). Tem natureza colaborativa, onde cada participante envolvido descreve a parte que ele desempenha na interação, não prevalecendo, portanto, a primazia individual. CULTURA ORGANIZACIONAL (CULTURA DA ORGANIZAÇÃO): conjunto de valores, capacidades e/ou conhecimentos internos à organização, que, de forma consciente ou inconsciente, agem no modo com que as atividades são realizadas. DESENHO (DE PROCESSO): no contexto de Gerenciamento de Processos de Negócio, consiste no conjunto de atividades que definem como o processo será realizado após a sua modelagem e análise. DIAGRAMA (DE PROCESSO): representação dos fluxos de atividades que compõem os Processos de Negócios em um nível mais baixo de detalhamento, ilustrando apenas as principais atividades do fluxo e omitindo informações mais detalhadas do fluxo de trabalho. DISCIPLINA: define um conjunto de atividades que podem ser associadas a um corpo de conhecimento em desenvolvimento de software ou em gerenciamento de projeto. ENTRADAS DE PROCESSO: são os artefatos usados pelas atividades do processo, podendo ter uso direto ou indireto. Entradas diretas são aquelas que serão usadas diretamente nas atividades, sem as quais o processo não pode completar. Entradas indiretas fornecem estrutura, informações complementares e restrições. Essas estão normalmente ligadas à forma como o trabalho deve ser realizado e à sua gestão (i.e. escopo, tempo, custo, qualidade, riscos etc.). Para o caso de processos de projetos de soluções orientadas a serviço, a Metodologia de Desenvolvimento de Solução Orientada a Serviço e a Arquitetura de Referência SOA são sempre entradas indiretas de processo. EQUIPE: conjunto de perfis profissionais que compõem o time técnico da Unidade Funcional, conforme as responsabilidades definidas para cada unidade. Inclui o responsável pela Unidade Funcional. EQUIPE DE PROJETO: conjunto de atores que atuam em um determinado projeto. ETAPA: define um conjunto de processos relacionados que atendem, parcialmente ou totalmente, uma disciplina da metodologia. Essas etapas podem ser vistas ainda sob a ótica de gerenciamento de projeto, onde são utilizadas as etapas clássicas de iniciação, execução, monitoração e controle e encerramento. FLUXO DE ATIVIDADES: forma ordenada de se representar uma sequência lógica de atividades, tomadas de decisão e eventos. FORNECEDOR: ator que fornece os insumos para o processo ou atividade. Pode ser interno ou externo à organização.

250

HAND-OFFS: momentos em que as atividades no processo mudam de lane (raia) e, consequentemente, de executor, aumentando a possibilidade de haver perda na eficiência global do processo. HEURÍSTICAS: O uso de heurísticas estabelece um conjunto de considerações práticas para aplicação dos princípios de orientação a serviço que devem ser consideradas pelo analista/arquiteto ao executar tarefas em um projeto de desenvolvimento SOA. INSUMOS: são quaisquer informações, documentos, matérias-primas ou qualquer outro tipo de entrada utilizada pelo processo ou atividade que terá o seu valor incrementado na saída. INVENTÁRIO DE SERVIÇOS: Inventário de Serviços é uma coleção de serviços complementares independentemente padronizados e governados dentro de uma fronteira que representa uma corporação ou um segmento significativo de uma corporação. Quando uma organização tem múltiplos inventários de serviços, este termo é qualificado adicionalmente como Inventário de Serviços de Domínio. A dinâmica fundamental que um inventário de serviços deve suportar com sucesso é a composição e recomposição de serviços. Para atingir isso, o próprio inventário deve ser suportado por tecnologias, plataformas e infraestrutura com capacidade adequada. LANE (RAIA): estrutura visual que delimita as atividades que serão realizadas pelos diferentes atores dos processos. M ACROPROCESSO: composição de um conjunto de processos que entrega um produto importante na organização. M APA (DE PROCESSO): representação do fluxo de atividades do processo com nível de detalhamento intermediário, maior que o diagrama e menor que o modelo, fornecendo uma visão abrangente dos principais componentes do processo. Agrega maior detalhe acerca do processo e de alguns dos relacionamentos mais importantes com outros elementos, tais como atores, eventos e resultados. MIDDLEWARE SOA: Plataforma de SOA ou Middleware SOA é um conjunto de sistemas operativos que implementam diversos autômatos, agentes de serviços (mediadores) e serviços utilitários relacionados com a execução de tarefas comuns em SOA. Esses componentes de tempo de implantação e execução permitem que diversas partes da lógica de solução sejam centralizadas na plataforma, evitando que estas sejam desenvolvidas explicitamente durante o projeto e construção de serviços. Uma plataforma de SOA pode conter diversos módulos funcionais, que implementam diferentes padrões de projeto de SOA. Dentre estes, os mais comuns são: •

Barramento Corporativo de Serviços (Enterprise Service Bus – ESB): Middleware de processamento de mensageira e mediação de composições entre serviços, que implementa, entre outros, os seguintes padrões de projeto: o Transformação de Modelos de Dados; o Transformação de Formatos de Dados; o Conversão de Protocolo; o Roteamento Intermediário; o Enfileiramento Assíncrono; 251

•

•

o Balanceamento de Carga; o Mensageria Confiável; o Centralização de Políticas; o Centralização de Regras; e o Mensageria Direcionada por Eventos. Orquestrador ou Motor de Processos de Negócio: Middleware para orquestração de serviços, que implementa, entre outros, os seguintes padrões de projeto: o Abstração de Processo; o Centralização de Processo; o Centralização de Regras (Business Rules); o Processamento de Eventos Complexos (CEP); o Repositório de Estado; o Compensação de Transação com Serviços; e o Transação Atômica com Serviços. Diretório de Serviços (Service Registry): Middleware para disponibilização de contratos e demais metadados comunicativos de serviços. Normalmente associado à realização do padrão centralização de contratos e à implementação de registry, conforme o modelo UDDI.

MODELAGEM (DE PROCESSO): ato de criar um modelo de processo. MODELO (DE PROCESSO): representação de um determinado estado do negócio e dos respectivos recursos envolvidos, tais como pessoas, informação, instalações, automatização, finanças e insumos. MODELO DE ESTRUTURA DA INFORMAÇÃO: formato padrão de estrutura da informação, capaz de organizar de forma clara e concisa uma sequencia de níveis. MODELO DE NEGÓCIO: conjunto de informações que estruturam o negócio da empresa, isto é, o conjunto de atividades que buscam levar um valor específico ao cliente. OMG (OBJECT M ANAGEMENT GROUP): é uma organização internacional que define padrões abertos para aplicações orientadas a objetos e de modelagem (programas, sistemas e processos de negócio). ORIENTAÇÃO A SERVIÇOS: Orientação a Serviço é um paradigma de projeto que tem por objetivo a criação de unidades de lógica de solução individualmente projetadas que permitem sua utilização coletiva e reutilizável, em suporte à realização de um conjunto específico de objetivos estratégicos e benefícios associados com SOA e a Computação Orientada a Serviço. A lógica de solução projetada, em acordo com os princípios de orientação a serviço, pode ser qualificada com ‘orientada a serviço’ e unidades de lógica de solução orientadas a serviços são chamadas de serviços. A Orientação a Serviços é composta de uma série de princípios de projeto que coletivamente estabelecem essas características. ORQUESTRAÇÃO: Descreve as interações ocorridas no serviço no nível de mensagem, incluindo a lógica de negócio e a ordem de execução. A orquestração refere-se a um processo executável, onde este processo é sempre controlado a partir da perspectiva de um dos participantes. Diferentemente da coreografia, na orquestração há uma primazia de condução por parte de um dos participantes.

252

PADRÕES DE PROJETO: A aplicação sistemática de padrões de projeto (design patterns) de SOA resulta em melhores soluções orientadas a serviço. Recomenda-se que se desenvolva e mantenha um catálogo de padrões (design patterns catalog) com documentação acessível e regras de aplicação claramente estabelecidas. O desenvolvimento deste catálogo é igualmente indicado na Arquitetura de Referência SOA da Fábrica de Serviços, mas sua construção não faz parte do escopo desta metodologia. Esse catálogo deverá estar sob responsabilidade e gestão do Núcleo de Governança SOA. PAYLOAD: em computação, se refere à carga de uma transmissão de dados. Em SOA está comumente associado ao conteúdo de mensagens de entrada e saída enviadas quando da execução de uma capacidade de serviço. PERFIL ENVOLVIDO: Perfil que participa de determinada tarefa. PERFIL EXECUTOR: Perfil Responsável pela efetiva execução de determinada tarefa. PERFIL PROFISSIONAL: define um tipo de profissional, com suas respectivas capacidades profissionais associadas a um conjunto de atividades da unidade funcional (para unidades funcionais, a metodologia não define atores). PROCESSO: descreve um conjunto de atividades previamente estabelecidas com objetivo de determinar como o trabalho será realizado. Um processo possui é constituído de tarefas relacionadas entre si de forma lógica e coerente. Para cada processo, é apresentado um modelo de processo que define essa organização lógica, na forma de um fluxo de trabalho. Um processo possui um conjunto de entradas (de processo) e produz um conjunto de saídas (de processo) que geram valor à organização. Um processo ou uma tarefa complexa podem ser decompostos em subprocessos. PROCESSOS FINALÍSTICOS: também chamados de processos primários, são os processos relacionados às atividades fim da organização. PRODUTO: objeto entregue pela atividade ou processo realizado completamente. Nesse documento, pode ser considerado como algo tangível ou não. PROVEDOR: • •

Definição do W3C: Pessoa ou organização que está provendo o serviço; Definição do OMG: É a entidade que modela o tipo de provimento do serviço em uma relação consumidor/provedor. O provedor é o participante que entrega o resultado de uma interação com o serviço.

RECURSOS: meios utilizados para se realizar uma tarefa, atividade ou processo. Podem ser físicos, humanos, de conhecimento, informacionais ou outros. REGRAS DE NEGÓCIO: conjunto de diretrizes que orientam o executor do processo, seja ele humano ou máquina, a tomar decisões que estejam alinhadas ao Modelo de Negócio adotado. REQUISITANTE: •

Definição do W3C: Pessoa ou organização que deseja usar o serviço de um provedor;

253

•

Definição do OMG: Representa uma capacidade de um participante que é o consumidor de um serviço.

RESPONSABILIDADE: define atribuições específicas de uma unidade funcional no projeto de desenvolvimento de soluções orientadas a serviço. RESPONSÁVEL: perfil profissional que responde pela Unidade Funcional. REST (REPRESENTATIONAL STATE TRANFER): É um estilo (uma abordagem) alternativo para a construção de Web Services. SAÍDAS DE PROCESSO: artefatos gerados pelo processo. Muitos dos artefatos possuem templates definidos na metodologia. SERVIÇO (WEB): É a abstração do trabalho a ser provido em uma relação específica entre a entidade provedora e a requisitante. •

•

Definição do W3C: É um recurso abstrato que representa uma capacidade de efetuar tarefas que representam uma funcionalidade coerente do ponto de vista de entidades provedora e requisitante. Para ser usado, um serviço deve ser realizado por um agente provedor concreto; Definição do OMG: Representa uma capacidade de um participante que é a oferta de um serviço de um participante para outro, usando bem definidos termos, condições e interfaces.

Serviços são os elementos constitutivos básicos de uma SOA. Encapsulam capacidades (equivalente aos métodos) de forma discreta e autônoma e as expõem ao consumidor por uma ou mais interface definidas no Contrato de Serviço. Serviços são projetados de uma maneira bastante específica, aplicando-se a abordagem de projeto orientado a serviço, e são disponibilizados através de um ciclo de vida. Assim, no contexto de SOA e de orientação a serviço, o termo "serviço" tem conotações específicas relacionadas com uma única combinação de qualidades de projeto. Exemplos dessas qualidades incluem: independência, diferenciação, multi-propósito, compatibilidade, previsibilidade. Por definição, serviços são unidades de lógica de solução orientada a serviço. Uma lógica é considerada orientada a serviço quando orientação a serviço foi aplicada em seu projeto em uma extensão significativa. A criação e definição de serviços resultam de um processo de decomposição baseado na teoria da separação de interesses. Assim como em orientação a objetos, orientação a serviço tem sua própria abordagem para realizar a separação de interesses. SOA (SERVICE ORIENTED ARCHITECTURE): É um estilo de arquitetura de software cujo princípio fundamental estabelece que as funcionalidades implementadas pelas aplicações devem ser disponibilizadas na forma de serviços e descreve a disposição e os princípios que regem os elementos para provisão e intercâmbio de serviços entre entidades provedoras e requisitantes. A arquitetura SOA é fundamentada nos princípios da computação distribuída e utiliza o paradigma request/reply para estabelecer a comunicação entre as aplicações consumidoras e as aplicações que implementam os serviços. A Arquitetura Orientada a Serviço representa um modelo arquitetural que tem por objetivo melhorar a agilidade e a efetividade de custos de uma corporação enquanto reduz a peso da TI 254

na organização. SOA realiza isso posicionando serviços como meios primários de representação da lógica de solução e suporta Orientação a Serviço na realização de objetivos estratégicos associados com computação orientada a serviço. SOA é um modelo de arquitetura tecnológica para aplicações distribuídas com características próprias para suportar a realização de orientação a serviço. As características fundamentais de SOA são: ser direcionada pelo negócio, ser centrada na corporação e ser centrada na composição. SOAP (SIMPLE OBJECT ACCESS PROTOCOL): É um protocolo baseado em XML, destinado à troca de informação estruturada em ambiente distribuído. Ele pode operar sobre diversos protocolos, especialmente o HTTP, quando se trata de trocas de mensagem em Web Services. SQL (STRUCTURED QUERY LANGUAGE): É uma linguagem de pesquisa declarativa para banco de dados relacional (base de dados relacional). Muitas das características originais do SQL foram inspiradas na álgebra relacional. SUBPROCESSO: são processos menores, que compõem outros processos de maior complexidade. TAREFA: descreve um trabalho que deve ser executado por um determinado conjunto de atores (em determinado prazo e com determinado esforço/custo). TEMPLATE: modelo de artefato de software. TO-BE: forma informal de se referir ao processo no momento do desenho. Faz referência ao estado futuro, de “como será” executado o processo pela organização. UNIDADE FUNCIONAL: agrupamentos lógicos de atividades e responsabilidades relacionadas ao processo de desenvolvimento de soluções orientadas a serviço. Unidades funcionais são classificadas ainda em dedicadas (aquelas que existem exclusivamente no contexto de atividades de desenvolvimento de soluções orientadas a serviço) e corporativas (aquelas cujas atividades se estendem a outros domínios funcionais, não exclusivos ao desenvolvimento de soluções orientadas a serviço). W3C (WORLD WIDE WEB CONSORTIUM): É a principal organização de padronização da World Wide Web. Consiste em um consórcio internacional, agregando empresas, órgãos governamentais e organizações independentes com a finalidade de estabelecer padrões para a criação e a interpretação de conteúdos para a Web. WEB SERVICES: Tecnologia que permite a interoperabilidade entre diferentes sistemas, independente de plataforma e linguagem de programação. WSDL (WEB SERVICES DESCRIPTION LANGUAGE): É uma linguagem baseada em XML utilizada para descrever Web Services funcionando como um contrato do serviço. Trata-se de um documento escrito em XML que além de descrever o serviço, especifica como acessá-lo e quais as operações ou métodos disponíveis. XML (EXTENSIBLE MARKUP LANGUAGE): É uma linguagem de marcação recomendada pela W3C para a criação de documentos com dados organizados hierarquicamente, tais como textos, banco de dados, etc. O XML traz uma sintaxe básica que pode ser utilizada para compartilhar informações entre diferentes computadores e aplicações.

255

13 ANEXO A: TEMPLATES

256