Frameworks e Modelos de Projeto em Arquitetura Orientada a Serviços

Ariel Da Silva Dias FRAMEWORKS E MODELOS DE PROJETO Sumário INTRODUÇÃO Nessa unidade aprenderemos os conceitos fun damentais para entender e diferenciar os tipos de frameworks e modelos de projeto relacionados a arquitetura orientada a serviços Apresentaremos os conceitos relacionados aos contextos e modelos de projeto em arquitetura orientada a serviços e esclareceremos os principais aspectos sobre frameworks de aplicações como TOGAF e Zachman Além disso delinearemos a engenharia de requi sitos e engenharia reversa e por fim trataremos de padrões de projeto ou design patterns para a arquitetura orientada a serviços e ESB 3 FAM ONLINE CONTEXTOS E MODELOS DE PROJETO Do ponto de vista de negócios e tecnologia a arqui tetura orientada a serviços SOA é uma arquitetura de negócios conceitual em que a funcionalidade de negócios ou lógica de aplicativo é disponibiliza da para usuários ou consumidores de SOA como serviços compartilhados e reutilizáveis em uma rede de tecnologia de informação TI De modo geral em SOA um serviço é descrito em um estilo padronizado publicado no registro de serviço descoberto e invocado por um consumidor de serviço O provedor o consumidor e o agente de serviços são três elementos principais na SOA O provedor é quem publica uma descrição de serviço e for nece a implementação para o mesmo Então um solicitante de serviço ou consumidor encontra uma descrição de serviço no registro então ele demanda o serviço e o fornecedor envia o regis tro do mesmo No entanto o agente de serviço é opcional e o consumidor do serviço pode obter a interrupção dele diretamente do provedor Os termos orientado a serviços e SOA surgi ram antes da chegada do serviço Web que é a tecnologia mais adequada para SOA de sucesso 4 mesmo não se limitando aos serviços da Web Por exemplo Common Object Request Broker Architecture CORBA e sistemas de Middleware orientados a mensagens como o IBM Message Queue Series e o Java Messaging Service JMS podem ser aplicados mas os serviços da Web em comparação com outros têm interfaces mais fracamente acopladas Os serviços da Web fornecem a tecnologia de base para SOA e muitas empresas e organizações executam seus processos em grupos o que limita sua eficiência e capacidade de fornecer serviços econômicos aos clientes No pensamento orien tado a serviços os serviços compartilham sua capacidade ao quebrar o processo de negócio do grupo em serviços recicláveis e implementálos com SOA Os sistemas atuais são executados em várias tecnologias e os aplicativos de software atuais são na maioria das vezes sistemas não modula res Com relação a isso os sistemas orientados a serviços podem ser divididos em módulos para controle gerenciamento e desenvolvimento Como resultado a modularidade do sistema pode ser aplicada a serviços web que podem ser atuali zados ou substituídos sem distribuir os serviços independentes funcionais ou integrais Vários métodos para modelagem orientada a serviços 5 foram propostos para usar SOA em aplicações industriais e de negócios Existem algumas abordagens de modelagem como The Reference Model for SOA SOARM The Reference Architecture Foundation for SOA SOARFA Open Group SOA Ontology Service oriented Modeling Framework SOMF Modelo independente de plataforma para SOA PIM4SOA SOA Modeling Language SoaMl e Modelagem e Arquitetura Orientada a Serviços SOMA O SOARM é um padrão OASIS que pretende fornecer um vocabulário comum para capturar a essência do SOA Ele foi projetado explicitamente para não ser implementado diretamente mas sim fornecer uma estrutura conceitual e terminológica comum para todos que trabalham na modelagem orientada a serviços Além disso esse modelo de referên cia definiu aspectos de metamodelo de serviços relacionados à descrição e políticas de serviço SOARFA é atualmente uma especificação do co mitê OASIS que é uma arquitetura de referência abstrata e básica que aborda o negócio via visão de serviço SOARFA começou a vida e no rascunho inicial como a Arquitetura de Referência SOA mas foi deixado para que outras Arquiteturas de Refe rência pudessem coexistir refletindo o domínio do paradigma de implementação Consequentemente 6 foi renomeado adicionando a palavra Foundation que fornece um vocabulário comum para entender a importância da visão do ecossistema dentro do paradigma SOA e mostra como o sistema baseado em SOA pode ser realizado de forma abstrata A Ontologia SOA é um padrão Open Group que de fine o conceito terminologia e semântica de SOA em termos técnicos e de negócios Ele contém propriedades correspondentes ao conceito central de SOA como objeto classe e relacionamento entre eles que é suportado pela Web Ontology Language OWL O SOMF é uma metodologia orientada a modelos com notação de modelagem especializada para auxiliar os serviços de modelagem análise e identificação Ele fornece um método formal de identificação de serviços em diferentes níveis de abstração incluindo conceito de metamodelo e notação específica O PIM4SOA é desenvolvido com base em um me tamodelo para SOA que consiste em um conjunto de aspectos importantes de descrição de serviços incluindo acesso operação e tipos o processo or dem lógica em termos de ação fluxos de controle e interação de serviço as informações mensagem ou troca estruturada de serviço qualidade de serviço qualidades extrafuncionais em relação a serviço 7 informação e processos O objetivo principal do metamodelo PIM4SOA é definir uma linguagem para descrever SOA como um nível independente de plataforma O Object Management Group OMG propôs a SoaML em 2009 para representar artefatos SOA usando Unified Modeling Language UML como um padrão de modelagem central Além disso um metamodelo e um perfil UML são fornecidos em SoaML para a especificação e design de serviço para SOA Já a SOMA é uma técnica de modelagem para de senvolvimento e construção de sistemas baseados em SOA proposta pela IBM em 2004 Os focos das atividades do SOMA incluem a identificação do serviço descobrindo o serviço candidato e interação entre eles a especificação do serviço a tomada de decisão para expor serviços e realização do serviço O maior foco do método SOMA está no serviço componentes de serviço e fluxos com ênfase na reutilização de serviços Como observado existem diversas abordagens de modelagem Cada uma com suas particularida des e características que atendem uma demanda específica 8 FRAMEWORKS DE APLICAÇÕES TOGAF E ZACHMAN Os frameworks de aplicação consistem em estru turas de software usadas por programadores para implantar uma estrutura padronizada do software do aplicativo O framework de aplicação se tornou popular com o advento das Interfaces Gráficas de Usuário GUI ou Graphical User Interface que buscavam proporcionar uma estrutura padrão para aplicativos É muito mais simples para os desenvolvedores criarem ferramentas automatizadas de criação de GUIs ao usar uma estrutura padronizada pois isso define uma estrutura de código subjacente do aplicativo de forma antecipada Geralmente os programadores usam técnicas de Programação Orientada a Objetos OOP ou ObjectOriented Programming para implantar estruturas de modo que as partes exclusivas de um aplicativo sejam herdadas de classes já existentes na estrutura TOGAF que significa The Open Group Architecture Framework é uma estrutura que permite que as empresas projetem planejem desenvolvam e im plementem sua infraestrutura com menos erros e dentro do orçamento 9 O Open Group desenvolveu sua estrutura em 1995 e a oferece às organizações para utilizála gratuita mente mas não podem usála para fins comerciais ou seja é permitido que a utilizem internamente Esse consórcio global também fornece ferramen tas e cursos certificados que as empresas podem usar para implementar o TOGAF Ele também apresenta o Método de Desenvolvimento de Arquitetura ADM que é um método resultado das contribuições contínuas de diferentes espe cialistas do TOGAF O ADM ajuda os arquitetos a desenvolverem uma empresa que atenda à maioria dos requisitos organizacionais e de sistema Para conseguir isso as empresas precisam trabalhar com profissionais treinados e certificados que se comunicam com os vários chefes de departamento para garantir um processo de design perfeito Eles também projetam e implementam uma estratégia que melhor se adapte às suas necessidades de ne gócios O papel central dos arquitetos certificados pelo TOGAF é desmistificar os processos comple xos e técnicos de desenvolvimento de arquitetura Por meio da certificação é possível dominar todos os princípios da arquitetura empresarial Essa ha bilidade permite que eles ajudem organizações e empresas no desenvolvimento de estratégias de 10 longo prazo e também os ajuda a gerenciar todo o portfólio de infraestrutura Especialistas certificados auxiliam na construção de um roteiro que orienta uma organização com base nos padrões do Open Group Architecture Framework Eles definem todos os aspectos da tecnologia e garantem que todos os processos dentro de uma empresa funcionem sem problemas Seu papel inclui garantir que haja um alinhamen to entre os objetivos de uma organização e sua tecnologia supervisionando os ciclos de vida da tecnologia em uma empresa especialmente quan do há novas atualizações versões ou alterações Como arquiteto corporativo é necessário saber como usar o Open Group Architecture Framework Como o TOGAF é a estrutura líder mundial obter a certificação coloca o profissional no topo do cam po da arquitetura corporativa pois ele fornece as habilidades para desenvolver corrigir e organizar a infraestrutura da sua empresa Ser certificado nos frameworks permite que uma pessoa trabalhe e colabore com outros arquitetos do TOGAF Isso ocorre porque a certificação é exclu siva para profissionais de arquitetura corporativa Planejar e implementar a estrutura requer excelentes habilidades de comunicação O profissional deve 11 ser capaz de explicar os elementos e princípios da estrutura para profissionais e não profissionais As organizações procuram continuamente manei ras de concluir tarefas com o mínimo de tempo e esforço A certificação em TOGAF ensina como atender adequadamente às necessidades de uma empresa sendo possível determinar como as empresas gastam o orçamento e identificar áreas onde é possível cortar os custos O TOGAF também ensina como organizar uma equipe para funcionar como uma unidade É pos sível otimizar processos e reduzir o atrito para garantir que todos os departamentos trabalhem com eficiência Com esses aspectos bem definidos a gestão de uma empresa fica mais fácil ou seja basicamen te o Open Group Architecture Framework oferece a capacidade de simplificar as operações em empresas Além disso a principal vantagem do TOGAF é que a estrutura é personalizável para atender às neces sidades de uma organização Também é escalá vel pois a equipe pode distribuílo para todos os outros departamentos sem grandes ajustes Mais importante ainda o Open Group lança atualizações e versões regulares para manter a empresa segura em relação a futuros riscos que possam ocorrer 12 O framework não é uma ferramenta milagrosa mas fornece a estrutura que as equipes precisam para implementar novas tecnologias No entanto só pode funcionar se os profissionais certos a im plementarem Isso é importante para organizações que estão se direcionando para a agilidade O Zachman Framework não é exatamente uma metodologia pelo menos não do jeito que a maioria dos frameworks de gestão de tecnologia da infor mação são pois não oferece processos específicos para manipulação de dados Em vez disso é con siderado uma ontologia ou esquema para ajudar a organizar artefatos de arquitetos corporativos como documentos especificações e modelos A estrutura considera quem é afetado pelo artefato como o proprietário do negócio e compara isso com o problema que está sendo tratado Originalmente desenvolvido por John Zachman na IBM em 1987 o Zachman Framework foi atualizado várias vezes desde então Destinase a organizar e analisar dados resolver problemas planejar o futuro gerenciar a arquitetura corporativa e criar modelos analíticos Apesar do tempo o Zachman Framework continua relevante para as empresas atuais em grande parte porque os ambientes de tecnologia se tornaram cada vez mais complexos com tecnologia legada 13 e informações espalhadas por toda a organização muitas vezes perdidas para funcionários que migra ram para outros sistemas e soluções Observemos a seguir um exemplo de Zachman Framework Figura 1 Zachman Framework Contextual Conceptual Logical Physical As Built Functioning What How Where Who When Why Contextual Conceptual Logical Physical As Built Functioning What How Where Who When Why Fonte Adaptado de Wikimedia Tal esquema ou ontologia conta com algumas regras são elas y Regra 1 As colunas não têm ordem y Regra 2 Cada coluna tem um modelo simples e básico y Regra 3 Modelo básico de cada coluna é único y Regra 4 Cada linha representa uma visão distinta 14 y Regra 5 Cada célula é única y Regra 6 Combinar as células em uma linha forma uma descrição completa dessa visualização Com a matriz de 36 colunas do Zachman Fra mework é possível catalogar toda a arquitetura de uma organização o que pode ajuda a organização a permanecer ágil e flexível diante de mudanças fornecendo informações detalhadas sobre os ativos de TI de sua empresa O Zachman Framework usa 36 categorias para descrever qualquer coisa desde produtos e ser viços a hardware e software As categorias são organizadas em seis linhas por seis colunas conforme a imagem apresentada formando uma matriz bidimensional com 36 células que auxiliam a visualização do tema problema ou produto As colunas de um modelo do Zachman Framework descrevem as questões fundamentais em torno da arquitetura em questão enquanto as linhas repre sentam as perspectivas de cada tipo de stakeholder envolvido no projeto A matriz finalizada é então preenchida com processos materiais necessários funções importantes locais relevantes e quaisquer metas ou regras associadas ao projeto com base na questão fundamental e na perspectiva repre sentada em cada célula 15 SAIBA MAIS Para conhecer outros aspectos da sobre TOGAF e Za chman assista ao vídeo Como decorar as 6 partes do TOGAF disponível em httpsyoutubeKwi6yc7KPI0 A partir dessas informações precisamos manter mos em mente que a arquitetura corporativa a ser escolhida depende da abordagem desejada A estrutura TOGAF fornece uma abordagem sis temática para definir o processo de criação ou melhoria de uma arquitetura corporativa Com seu ADM o framework oferece um processo para implementar as escolhas de decisão para produzir o modelo desejado O Zachman Framework é mais uma ontologia um conjunto estruturado de expressões que descrevem como os artefatos podem ser categorizados e assim criados operados e alterados Ao contrário do TOGAF Zachman usa várias perspectivas cor porativas para definir o escopo e planejar detalhes sobre subconjuntos individuais de seu sistema corporativo Uma organização pode optar por usar um ou optar por ambos Juntos os frameworks podem se com plementar com o TOGAF descrevendo o processo SAIBA MAIS 16 detalhado para criar a arquitetura corporativa e Zachman categorizando os artefatos 17 ENGENHARIA DE REQUISITOS E ENGENHARIA REVERSA Conforme temos discutido a SOA tem recebido atenção significativa recentemente e à medida que a computação em nuvem e o marketing na nuvem estão crescendo a SOA atrai mais dedicação de profissionais e pesquisadores Projetar serviços de acordo com a necessidade do cliente é crucial nesta arquitetura Eles devem ser independentes e reutilizáveis por isso precisamos conhecer o objetivo exato do sistema e é aí que entra a engenharia de requisitos A engenharia de requisitos é o processo de eliciar as necessidades e desejos das partes interessadas desenvolvendoas em um conjunto acordado de requisitos detalhados que podem servir de base para todas as atividades de desenvolvimento subsequentes O objetivo das metodologias de engenharia de requisitos é tornar o problema que está sendo declarado claro e completo além de garantir que a solução seja correta razoável e eficaz As abordagens de engenharia de requisitos são processos que transformam problemas do mundo 18 real em soluções do mundo digital Cada aborda gem tem seu pensamento especializado sobre o problema do mundo real e segue um processo único para construir a especificação do sistema como solução A engenharia de requisitos é frequentemente considerada como uma atividade de frontend no processo de desenvolvimento de sistemas de software Isso geralmente é verdade embora aconteça de os requisitos mudarem durante o de senvolvimento e evoluírem depois que um sistema estiver em operação por algum tempo Portanto a engenharia de requisitos desempenha um papel importante na gestão da mudança no desenvolvimento de software No entanto a maior parte do esforço de engenharia de requisitos ocorre no início do ciclo de vida de um projeto motivado pela evidência de que erros de requisitos como requisitos incompreendidos ou omitidos são mais caros para corrigir depois nos ciclos de vida do projeto Antes que um projeto possa ser iniciado alguma preparação é necessária No passado era comum que os métodos de engenharia de requisitos assu missem que a ela fosse executada para um cliente específico que poderia assinar uma especificação de requisitos 19 No entanto a engenharia de requisitos é realmente realizada em uma variedade de contextos incluindo desenvolvimento de produtos orientados para o mercado e desenvolvimento para um cliente es pecífico com a eventual intenção de desenvolver um mercado mais amplo O tipo de produto também afetará a escolha do método pois a engenharia de requisitos para sistemas de informação é muito diferente da en genharia de requisitos para sistemas de controle embutidos que também é diferente da engenharia de requisitos para serviços genéricos como redes e sistemas operacionais Além disso é necessário realizar alguma avaliação da viabilidade de um projeto e dos riscos asso ciados e a engenharia de requisitos desempenha um papel crucial nessa avaliação Muitas vezes é possível estimar os custos cronogramas e viabili dade técnica do projeto a partir de especificações precisas de requisitos Também é importante que os conflitos entre os objetivos de alto nível de um sistema imaginado surjam cedo a fim de estabelecer o conceito de operação e limites de um sistema É claro que o risco deve ser reavaliado regularmente ao longo da vida de desenvolvimento de um sistema uma 20 vez que mudanças no ambiente podem alterar os riscos de desenvolvimento associados O trabalho de base compreende também identifi car um processo apropriado para a engenharia de requisitos e a escolha de métodos e técnicas para as várias tarefas de engenharia de requisitos O termo processo é usado aqui para evidenciar uma instância de um modelo de processo que é uma descrição abstrata de como conduzir uma coleção de atividades descrevendo o comportamento de um ou mais agentes e seu gerenciamento de recursos Por isso preciso mantermos em mente que uma técnica prescreve como realizar uma atividade específica e se necessário como descrever o produto dessa atividade em uma notação especí fica Um método fornece uma prescrição de como realizar uma coleção de atividades focando em como um conjunto relacionado de técnicas pode ser integrado e fornecer orientação sobre seu uso Podemos utilizar a engenharia de requisitos para especificar metas e requisitos para obter serviços De fato a engenharia de requisitos evoluiu de méto dos clássicos para ServiceOriented Requirement Engineering SORE ou Engenharia de Requisitos Orientada a Serviços Os requisitos do sistema são a descrição das fun cionalidades que se espera que sejam fornecidas 21 Esses requisitos são os objetivos da organização e dos clientes que devem estar satisfeitos pela aplicação Podemos classificar os requisitos em dois grupos principais os requisitos do usuário e requisitos do sistema Os requisitos do usuário devem especi ficar requisitos funcionais e não funcionais sem jargões e fáceis de entender para os usuários Além disso devem definir o comportamento externo do sistema e evitar detalhes do projeto do sistema Os requisitos do sistema são uma versão desen volvida dos requisitos do usuário que podem ser usados como ponto inicial para a aplicação do projeto do sistema Esses contêm detalhes do sis tema e descrevem como os requisitos do usuário devem ser suportados Tais requisitos devem ser especificados de forma precisa e completa e para diminuir uma suposta ambiguidade é melhor descrevêlos usando lingua gens naturais e estruturadas que sejam capazes de conter tabelas e modelos de sistema A enge nharia de requisitos descobre modela especifica e documenta esses requisitos para um sistema e seu domínio A engenharia de requisitos possui quatro fases o estudo de viabilidade a elicitação e análise de requisitos a especificação de requisitos e a vali 22 dação de requisitos Geralmente a engenharia de requisitos especifica se o sistema é conveniente para o negócio desejado e em caso afirmativo descobre os requisitos e os padroniza E finalmente na fase de validação avalia se os requisitos são o que os clientes desejam Para todos os novos sistemas o processo de engenharia de requisitos deve começar a partir do estudo de viabilidade Requisitos de negócio primários descrição geral do sistema e a forma como o sistema irá suportar o negócio são entradas para esta fase O resultado será um relatório para tomar uma base de decisão para determinar se o desenvolvimento do sistema seria justo ou não Na elicitação e análise de requisitos os engenhei ros entram em contato com os clientes e usuários finais para coletar informações sobre o domínio do sistema funcionalidades do sistema serviços que devem ser fornecidos restrições do sistema entre outros detalhes O objetivo da especificação de requisitos é alcançar um entendimento comum dos requisitos Nesta fase os requisitos devem ser documentados em diferentes níveis para uso de diferentes usuários Por exemplo documentos que são usados por de senvolvedores devem conter detalhes do sistema e questões técnicas para fornecêlos 23 No entanto não há necessidade de colocar a solução técnica em um documento usado pelos testadores Documentos de requisitos descrevem o sistema e seu domínio que podem ser usados como critérios para processos futuros como projeto de detalhes do sistema casos de teste validação e verificação e gerenciamento de mudanças A validação de requisitos examina se as funcionali dades fornecidas são relevantes para os requisitos do cliente ou não Esta fase é um pouco sobreposta à análise de requisitos pois a fase de validação se concentra em descobrir problemas e conflitos entre requisitos e verificar sua compatibilidade Lembremos que essa fase é muito importante pois quando um problema não descoberto for detectado na fase de desenvolvimento ou depois disso o custo de sua correção será enorme A ideia principal de SOA é baseada na composição de arquitetura orientada a objetos e arquitetura base de componentes Nessa arquitetura os desenvolvedores são divididos em três grupos independentes mas cooperativos que são os construtores de aplicativos ou clientes de serviços os intermediários de serviços e os provedores de serviços A tarefa dos provedores de serviços é fornecer serviços independentes e fracamente acoplados 24 O dever dos corretores de serviços é a introdução e marketing do serviço Os construtores de aplica tivos encontram seus serviços necessários para construir seus aplicativos por meio de agentes para que os serviços possam ser colocados no centro de SOA Dessa forma os provedores fornecem alguns serviços e os construtores de aplicativos podem selecionar serviços publicados por meio de intermediários para construir um aplicativo No entanto a SOA pode ser centrada no consumi dor Dessa forma os construtores de aplicativos anunciam seus requisitos e os provedores os for necem por serviços Na verdade o objetivo mais importante da SOA é fornecer serviços que sejam exatamente o que os consumidores desejam e sejam tão independentes e reutilizáveis quanto possível e sem depender de plataformas específicas podem tornar o processo de desenvolvimento mais rápido para que o custo de desenvolvimento diminua Os serviços devem apoiar as atividades no processo de negócios Assim em SOA os processos de ne gócio devem ser especificados em primeiro lugar e depois de identificar as atividades necessárias para cada um deles devemos decidir para qual dessas atividades os serviços devem ser projetados É possível que o designer decida projetar vários serviços para uma atividade porque alguma parte 25 dessa atividade pode ser usada em outros proces sos de negócios ou é possível projetar um serviço para várias atividades O principal princípio do desenvolvimento de um aplicativo é ser baseado nos requisitos dos clientes Especificar e suprir os requisitos dos clientes têm sido os assuntos que preocupam os desenvolve dores afinal os requisitos de fornecimento variam para diferentes ciclos de vida do software Por exemplo na abordagem linear a primeira fase é dedicada à especificação dos requisitos enquanto que nos modelos espirais em cada iteração os requisitos do cliente devem ser considerados Como mostra a engenharia de requisitos esta não é uma especificidade para uma única fase é na verdade uma atividade que abrange todas as fases envolvidas no ciclo de vida do produto Nas organizações que se baseiam em serviços de TI existem dois grandes grupos envolvendo serviços que tem os usuários como responsáveis pela funcionalidade de negócios e precisam de suporte de TI para isso que os apoia fornecendo serviços trabalhando no projeto e implementação desses serviços Esse grupo sempre procura for necer serviços que sejam apresentados a vários suplicantes ou utilizáveis para suprir requisitos comuns entre diferentes processos de negócios 26 No entanto a utilização de serviços existentes ainda é um problema para muitas organizações porque simplesmente os serviços não podem suprir suas necessidades A principal razão é que os serviços sejam projetados para serem muito específicos e com observação limitada e isso causa mais res trições na reutilização de serviços Por outro lado na definição de novos projetos as potencialidades dos serviços existentes são negligenciadas e enquanto os serviços existentes podem suprir alguns requisitos novos serviços são projetados para processos de negócios Isso significa que a reutilização de serviços existentes é ignorada pela equipe do projeto A engenharia de requisitos em SOA é uma interface entre a engenharia de serviço e a engenharia de aplicação Na verdade a Engenharia de Requisitos Orientada a Serviços SORE ou Service Orien ted Requirements Engineering está aplicando a engenharia de requisitos clássica tanto para o grupo de consumidores de serviços quanto para os fornecedores de serviços Considerando que a SORE está sendo aplicada em um ambiente orientado a serviços com uma infraestrutura orientada a serviços será diferente com a engenharia de requisitos clássica nas enti 27 dades que descobre e nos métodos que usa para descobrir entidades Em vez de descobrir objetos e classes a SORE especifica serviços e fluxos de processos de ne gócios O efeito disso na diminuição do controle e gerenciamento de mudanças nos processos de negócios faz com que a SORE se torne mais im portante Assim se projetamos serviços com base em requisitos e idealmente como as aplicações são baseadas em serviços com pequenas altera ções nos serviços podemos projetar as alterações desejadas através de uma aplicação Para otimizar o efeito da engenharia de requisitos na arquitetura orientada a serviços é possível seguir alguns passos que são a especificação de metas a especificação do requisito do usuário a especificação de processos de negócios a espe cificação do domínio do processo de negócio e por fim a divisão de domínios em subsistemas Na especificação de metas as metas são partes vitais da engenharia de requisitos e têm um papel fundamental para o sucesso ou fracasso de um projeto Especificar metas completas e precisas considerando as políticas da organização é difícil mas essencial para ajudar na identificação dos requisitos Às vezes é possível dividir objetivos em alguns subobjetivos para facilitar sua identificação 28 Na especificação do requisito do usuário os requi sitos podem ser divididos em requisitos do usuário e requisitos do sistema Nessa etapa os requisitos do usuário devem ser especificados de acordo com os objetivos caracterizados na etapa anterior e os acionistas devem avaliálos e verificálos Já na especificação de processos de negócios para suprir os requisitos dos clientes é preciso especifi car os processos de negócios e entender bem suas tarefas Essa etapa é crucial pois os engenheiros de software podem ter um conhecimento limitado sobre o negócio Consequentemente um assunto óbvio para os clientes tem outro significado para os engenheiros isso é essencial para que o produto final não seja baseado em opiniões pessoais dos engenheiros de software Nessa etapa devese modelar os processos de negócios e validálos pelos acionistas Para a especificação do domínio do processo de negócio é necessário conhecer suas atividades Para projetar serviços reutilizálos e alterálos com menor custo é preciso considerarmos vários domínios para processos de negócios Nessa etapa especificar o domínio de cada processo de negócio é importante porque acaba por considerar os serviços existentes no domínio especificado ou projetar serviços com uma visão mais ampla que tem efeito na reutilização dos serviços 29 SAIBA MAIS Para conhecer mais sobre engenharia de requisitos as sista O que é Engenharia de Requisitos disponível em httpsyoutubeQK0GppsvZ4 e O que é Engenharia de Requisitos Engenharia de Software 01 disponível em httpsyoutubei5WR9xFKg70 Na divisão de domínios em subsistemas como o próprio nome diz dividimos um domínio em subsistemas para que a modularidade do sistema seja preservada e sua gestão e manutenção sejam mais fáceis Agora que entendemos de maneira geral a enge nharia de requisitos é preciso aprendermos um pouco sobre engenharia reversa A engenharia reversa é um processo projetado para extrair dados suficientes de um produto para depois reproduzilo Pode envolver a mudança para criar um produto do zero ou a partir de com ponentes prédesenvolvidos e pode ser aplicada a qualquer produto como tecnologia de computador produtos manufaturados produtos biológicos produtos químicos buscando determinar como os componentes são montados e como funcionam SAIBA MAIS 30 Figura 2 Exemplo de engenharia reversa Fonte Wikimedia As razões para empregar a engenharia reversa são inúmeras Algumas são legais e éticas mas muitas não são Ela pode por exemplo ser aplicada pelo criador de um produto quando ele não consegue se lembrar das etapas empregadas para criar um produto em primeiro lugar Da mesma forma pode ser usada para clonar o produto e fabricálo mais barato do que o original Algumas das razões comuns para engenharia reversa incluem o desenvolvimento de interfaces 31 para interoperabilidade de sistemas e a moderni zação de produtos de software O desenvolvimento de interfaces para interopera bilidade de sistemas geralmente pode ser usado quando sistemas legados estão envolvidos ou se a documentação original não estiver disponível Os sistemas legados podem se beneficiar da en genharia reversa quando o conhecimento original de como um desafio específico foi enfrentado e perdido para uma empresa A engenharia reversa também pode ajudar na migração de sistemas legados para novas plataformas por exemplo SAIBA MAIS Para conhecer mais sobre engenharia reversa assista aos vídeos O que é ENGENHARIA REVERSA dispo nível em httpsyoutubea31lsE73A e Papo Binário 2 Engenharia Reversa disponível httpsyoutube Sp6Y83rdISo SAIBA MAIS 32 DESIGN PATTERNS PARA SOA E ESB ENTERPRISE SERVICE BUS Para iniciarmos nossas discussões é necessário apresentar definições de padrões de projeto ou design patterns em SOA Os padrões de projetos podem ser definidos como uma concepção útil em um domínio prático que possivelmente também será útil em vários outros momentos Padrões de projeto são considerados respostas reaproveitáveis para possíveis problemas comuns de um projeto de software e são boas construções para projetar serviços da Web desde a sua introdução no final da década de 1980 vários padrões foram reconhecidos e documentados e muitas implementações SOA usam serviços da Web Além disso padrões de design aceleram o proces so de desenvolvimento através da implementação de soluções testadas e comprovadas e podem desempenhar um papel importante na implemen tação de SOA especialmente na padronização do design de serviço As empresas têm muito a ganhar com a implemen tação de design patterns ou padrões de projeto SOA pois padrões de projeto fornecem orientações 33 rápidas para resolver problemas recorrentes além de construir melhores soluções SOA À medida que os ecossistemas de negócios se tornam mais complicados com serviços adicionais controles de segurança validação transformações e demandas de infraestrutura as empresas precisam otimizar sua estrutura SOA À medida que surgem desafios com governança SOA conectividade de API Interface de Programação de Aplicações ou Application Programming Interface e automação geral de processos de negócios os padrões de design desempenham um papel críti co A governança SOA garante que os processos de negócios sejam executados de acordo com as melhores práticas e regulamentações ao mesmo tempo em que fornece visibilidade aos negócios dos serviços e aplicativos Com padrões de projeto SOA comprovados as organizações podem gerenciar e otimizar melhor os processos de negócios tornando a governança SOA um processo automatizado Além disso à medida que mais e mais aplicativos APIs serviços sistemas e fontes de dados desempenham um papel na empresa aumentam as preocupações com a segurança SOA Desse modo as empresas podem utilizar padrões de design SOA para otimi zar a segurança em toda a empresa para proteger terminais e APIs 34 Para o bom funcionamento dos padrões de um projeto existem preocupações quanto ao uso bem sucedido de padrões de projeto A infraestrutura de negócios o conhecimento do desenvolvedor e os requisitos de negócios contribuem para o sucesso dos padrões de projeto SOA Sem um ambiente de negócios bem estabelecido desen volvedores competentes e processos de negócios simplificados os padrões de design podem não atingir seu potencial O ambiente de implementação para padrões de projeto SOA deve permitir acoplamento flexível e a reutilização de soluções de integração Os desenvolvedores devem ter conhecimento sobre padrões de projeto SOA comuns e saber como e quando utilizálos Por fim para que os padrões de projetos SOA sejam implementados com sucesso os requisitos de negócios devem ser abordados e compreendidos em toda a empresa Diversos softwares oferecem suporte para mui tos padrões de projeto de integração por meio de plataformas que facilitam a integração para as organizações conectarem dados aplicativos sistemas e dispositivos A implementação de padrões reduz o esforço necessário para criar integrações do zero dando 35 aos desenvolvedores tempo e energia para se concentrarem na criação de soluções melhores Existem diversos padrões que podem ser mapea dos como os estilos de integração os sistemas de mensagens os canais de mensagens o roteamento de mensagens a transformação de mensagem os pontos de extremidade de mensagem a adminis tração de sistemas entre outros A governança e a segurança da SOA podem ser melhor gerenciadas e automatizadas com padrões de design garantindo que os ecossistemas de negócios permaneçam seguros e protegidos en quanto seguem as melhores práticas A partir de nossa discussão sobre os conceitos básicos de padrões de projeto ou design patterns analises os fundamentos de ESB ou Enterprise Service Bus O Enterprise Service Bus ESB é uma arquitetura de software que conecta todos os serviços em uma infraestrutura semelhante a um barramento Ele atua como centro de comunicação na SOA permitindo vincular vários sistemas aplicativos e dados e conectar vários sistemas sem interrupção conforme observamos na figura a seguir 36 Figura 3 Exemplo de ESB Fonte Wikimedia O design do ESB imita um barramento de hardware na arquitetura de um computador que atua como uma ponte de comunicação entre vários dispo sitivos periféricos Em suma o ESB serve como um barramento de comunicação estável entre os serviços e como não é um padrão ou um produ to tangível mas sim um padrão de arquitetura e comunicação ele fornece um plano conceitual com um conjunto de diretrizes para orquestração e mediação entre componentes de software que representam serviços de negócios garantindo desacoplamento adequado 37 O ESB foi concebido como um componente interno da SOA Portanto para o usuário final é uma caixa preta invisível As únicas pessoas que interagem com o ESB são os desenvolvedores de aplicativos e engenheiros de TI Os desenvolvedores de aplicativos são respon sáveis por definir as interfaces dos serviços que desenvolvem Tais interfaces tornamse os pontos de acesso de serviço para que outros serviços se comuniquem com eles por meio do ESB Enquanto que os engenheiros de TI são responsáveis por implantar manter e monitorar a infraestrutura do ESB para garantir o máximo desempenho com o crescente número de serviços vinculados a ela Os desafios de fornecer comunicação perfeita entre dois ou mais aplicativos não são novos Muitos padrões foram propostos e aplicativos e protocolos proprietários foram construídos ao longo dos anos A evolução do ESB está alinhada com as tendências de implantação de aplicativos corporativos baseados em SOA que remontam quase ao início da World Wide Web Portanto é anterior às tecnologias atuais da era da nuvem Embora o ESB possa ser percebido como desatua lizado ainda é relevante para a integração de TI e a transformação digital No entanto com o advento de tecnologias de nova geração é essencial traçar 38 paralelos para esclarecer as virtudes e limitações do ESB Devido à falta de padronização uma arquitetura uniforme do ESB não está disponível pois diferentes fornecedores têm suas maneiras de segregar um sistema ESB em seus subsistemas Portanto não é fácil reunir um conjunto padrão de componentes para apresentar uma arquitetura consistente entre os fornecedores Considerando as capacidades previstas pelos pro ponentes do SOA a seguir estão os componentes críticos do ESB y Broker como qualquer camada de orquestração o ESB segue um modelo de comunicação hub and spoke Um componente central atua como um hub e os raios são compostos por produtores e consu midores de serviços Dependendo dos requisitos de escalabilidade um modelo de hub de várias camadas também é possível No entanto esta é apenas uma hierarquia lógica de comunicação Não é o mesmo que uma topologia em estrela onde vários raios se conectam fisicamente a um hub central A principal função do broker é gerenciar assinaturas e roteamento de mensagens entre os serviços participantes y Serviço de mensagens o ESB conta com um sistema de mensagens Ele transporta as mensagens 39 publicadas e funciona emulando um barramento de hardware na forma de uma fila O componente de mensagens cria várias filas de entrada e saída e segue um mecanismo de pesquisa para trocar mensagens entre as filas para passálas até que atinjam o ponto de extremidade destinado y Mediador o ESB foi projetado para interoperar com vários serviços incluindo aplicativos internos e de terceiros Portanto garantir a santidade de todos os serviços participantes é de suma importância O componente de mediação consegue isso por meio de um conjunto de verificações prédefinidas para autenticar e autorizar os serviços e assinaturas de serviços Vários componentes do mediador podem estar presentes em um ESB para lidar com respon sabilidades de auditoria adicionais e gerenciar os aspectos gerais de segurança do ESB y Adaptador a transformação do protocolo e da mensagem são os principais requisitos para que o ESB faça interface com serviços externos e são os adaptadores que oferecem essa funcionalidade Vários componentes adaptadores baseados em software executam funções específicas como transformação de formato de mensagem de e para ESB usando um formato consistente como XML Sendo parte das tecnologias de geração mais an tiga o papel do ESB foi amplamente substituído por estruturas arquitetônicas mais recentes No 40 entanto os aplicativos legados estão sendo exe cutados no modelo SOA onde o ESB ainda atende bem Enquanto esses aplicativos não passarem por uma atualização tecnológica o ESB terá um papel fundamental A influência do ESB na formação dos novos mo delos de arquitetura para computação distribuída não pode ser ignorada Os conceitos e mecanis mos propostos como parte do ESB para lidar com a comunicação entre serviços continuam válidos na atual era da nuvem Portanto não será errado dizer que os conceitos da geração atual como service mesh e iPaaS estão nos ombros de um gigante chamado ESB 41 EXERCÍCIO RESOLVIDO Exercício LOPES 2018 A manipulação do código fonte para engenharia reversa pode ser feita com diversas ferramentas algumas pagas e outras gratuitas como o ILSpy httpsgithubcomicsharpcodeILSpy que é uma ferramenta open source O ILSpy suporta o Reflexil e será usado para exemplificar o máximo de ações possíveis na DLL CSharpModeloDDD Domaindll A estrutura sugerida para teste é incluir a DLL CSharpModeloDDDDomaindll no projeto do console em seguida criar um projeto de console chamado FWConsole e incluir a DLL acima Um assembly SystemManagementAutomation dll foi instalado via Nuget no projeto de console e projeto de domínio ou seja em FWConsole e CSharpModeloDDDDomain esse procedimento ajudará a entendermos os riscos de manter refe rências desnecessárias Esta montagem representa uma classe Powershell usada para executar scripts e comandos Desse modo baixe o código fonte de exemplo em httpsgithubcompetterlopes CSharpModeloDDDgit Depois disso adicione métodos conforme sugerido nas figuras a seguir e compile o projeto 42 static void Main string args Cliente cliente new Cliente clienteAtivo true clienteClienteId 0001 clienteDataCadastro DataTimeNow clienteNome Iron Man especial cliente public static void especial Clientecliente if clienteClienteEspecialcliente ConsoleWriteLineEspecial clienteNome ConsoleWriteLineVocê tem acesso total à área restrita ConsoleReadLine else ConsoleWriteclienteNome não é especial ConsoleReadLine Resolução A ideia principal é criar uma nova classe criar novos métodos modificar métodos existentes e finalmente gerar um novo executável e uma nova DLL resultado da importação do executável na imagem pode ser vista a estrutura interpretada pelo ILSpy Uma das práticas mais comuns em adulterar DLLs é feita por crackers que são criminosos e frequentemente alteram o programa para burlar 43 as validações como modificar a entrada de dados em jogos pagos para tornálos livres de cobranças ilegais Para simular esse cenário vamos mudar o método ClienteEspecial na DLL CSharpModeloDDDDomain dll para que no método especial do FWConso leexe cliente Homem de Ferro clienteNome Iron Man do método Main é considerado um cliente especial Para isso neste método vamos adicionar um condicional if onde o nome será comparado desta forma if clienteNome Iron Man return true Com essa mudança o clien te Iron Man será sempre considerado especial Navegue para o método como exemplificado na figura a seguir 44 50 public bool ClienteEspecial Cliente cliente 51 52 If clienteAtivo 53 54 return false 55 56 int result 57 if clienteAtivo 58 59 DateTime dateTime DateTimeNow 60 int year dateTimeYear 61 DateTime clienteDataCadastro 62 result year dateTimeYear 5 1 0 63 64 else 65 66 result 0 67 68 return byte result 0 69 Quando o código fonte for exibido na aba direita vá no Reflexil e clique com o botão direito do mouse na aba Instuctions depois no menu escolha a opção Replace all with code Uma janela será aberta com a compilação onde o novo código será adicionado 45 Em seguida exclua o conteúdo do método adicio ne a nova validação e clique no botão Compilar conforme a figura a seguir sugere bool ClienteEspecial CSharpModeloDDDDomainEntities Cliente cliente if ClientegetNome EqualsIron Man return true if clientegetAtivo return false return clientegetAtivo DateTimeNowYear clientegetDataCadastro Year 5 Quando a edição do código estiver concluída será necessário salvar a DLL ou o executável dessa forma o procedimento estará completo Com a DLL salva apenas faça o teste e veja se foi possí vel obter a mensagem cliente especial então vá para o diretório de origem e execute o programa conforme a figura a seguir sugere 46 Além do exemplo apresentado você encontrará diversos exercícios resolvidos ou que poderão ser resolvidos sobre alguns dos assuntos apresentados nesta unidade Interfaces Gráficas de Usuário GUI httpsdocenteifrnedubrnickersonferreiradisciplinas programacaocomacessoabancodedados3oano exerciciodevoltaasaulas httpspandaimeuspbraulasPythonstaticaulasPy thonaula18htmlexercicio181 httpspandaimeuspbraulasPythonstaticaulasPy thonaula19html httpspooperrottifandomcomptbrwiki ExercC3ADcioseexemplos httpsgithubcomRobsonViniciusengenhariaderequi sitosblob75a6635c91bd8beacecc9de12f8c6fc270e a604cEngenharia20de20Requisitos2020como20 levantar2C20documentar20e20validar420 ValidaC3A7C3A3o20de20requisitosmd SAIBA MAIS 47 CONSIDERAÇÕES FINAIS Nessa unidade estudamos os principais concei tos sobre os frameworks e modelos de projeto relacionados a arquitetura orientada a serviços Estes conceitos são fundamentais para entender suas diferenças Percebemos como funcionam os contextos e modelos de projeto em SOA pois existem várias abordagens de modelagem e cada uma delas pos sui particularidades e características que atendem uma demanda específica dentro da SOA Conhecemos as aplicações sobre frameworks o TOGAF que é uma estrutura que pode ser aplicada em empresas e que é possível usar Zachman jun tamente com TOGAF pois são complementares Discutimos os conceitos de engenharia de requisitos e engenharia reversa A engenharia de requisitos orientada a serviços especifica serviços e fluxos de processos de negócios e a engenharia reversa busca estudar um produto seja esse de qualquer tipo para entender como foi construído Ambos os conceitos são cruciais para a SOA E por fim entendemos como funcionam os padrões de projeto ou design patterns para a arquitetura orientada a serviços e ESB Enterprise Service Bus Os padrões de projeto são úteis para resolvermos 48 problemas recorrentes rapidamente além de cons truir melhores soluções SOA entendendo que o ESB consiste em uma arquitetura de software que conecta todos os serviços em uma infraestrutura de barramento e age como um padrão de arquitetura e comunicação 49 Referências Bibliográficas Consultadas COMO decorar as 6 partes do TOGAF Evolve Gestão Empresarial 14 set 2020 1 vídeo 2min22 Disponível em httpsyoutube Kwi6yc7KPI0 Acesso em 26 jul 2022 DENNIS A WIXOM B ROTH R M Análise e projeto de sistemas 5 ed Rio de Janeiro LTC 2014 Ebook Minha Biblioteca ENGENHARIA Reversa Papo binário 26 jun 2016 1 vídeo 19min40 Disponível em https youtubeSp6Y83rdISo Acesso em 26 jul 2022 ERL T SOA Princípios e Design de Serviços São Paulo Pearson 2009 Biblioteca Virtual FUGITA H S HIRAMA K SOA modelagem análise e design Rio de Janeiro Grupo GEN 2012 EBook Minha Biblioteca GALLOTTI G M A Arquitetura de software São Paulo Pearson Education do Brasil 2016 Biblioteca Virtual GALLOTTI G M A Qualidade de Software São Paulo Pearson Education do Brasil 2016 Ebook Biblioteca Virtual LOPES P Engenharia Reversa e Injeção de Código manipulando DOT NET Perícia computacional 31 mai 2018 Disponível em httpspericiacomputacionalcomengenharia reversaeinjecaodecodigodotnet Acesso em 26 jul 2022 MARINHO A L Análise e modelagem de sistemas São Paulo Pearson Education do Brasil 2016 Ebook Biblioteca Virtual O QUE é engenharia de requisitos Fatto Consultoria e Sistemas 16 jul 2015 1 vídeo 11min17 Disponível em httpsyoutube QK0GppsvZ4 Acesso em 26 jul 2022 O QUE é engenharia reversa Guia Anônima 21 mai 2022 1 vídeo 8min57 Disponível em httpsyoutubea31lsE73A Acesso em 26 jul 2022 O QUE é engenharia de requisitos Tecnologia em vídeo 18 mar 2019 1 vídeo 10min23 Disponível em httpsyoutubei5WR9xFKg70 Acesso em 26 jul 2022 PRESSMAN R S MAXIM B R Engenharia de Software uma abordagem profissional 9 ed Porto Alegre Bookman 2021 Ebook Minha Biblioteca SOMMERVILLE I Engenharia de software 10 ed São Paulo Pearson Brasil 2019 Ebook Biblioteca Virtual