Modelagem de Sistema: Conceitos Fundamentais e Arquitetura Orientada a Serviços

Ariel Da Silva Dias MODELAGEM DE SISTEMA Sumário INTRODUÇÃO Nesta unidade aprenderemos alguns conceitos fundamentais sobre os tipos de modelagem de sistemas e como elas podem ser aplicadas na arquitetura orientada a serviços Com base em arquitetura orientada a serviços estudaremos também os conceitos básicos re lacionados à modelagem orientada a objetos e a serviços e a modelagem de componentes de software e conceitos relacionados a isso Por fim investigaremos com exemplos a modelagem e arquitetura orientada a serviços que consiste em uma metodologia de modelagem de aplicativos em arquitetura orientada a serviços 3 MODELAGEM ORIENTADA A OBJETOS E A SERVIÇOS A Arquitetura Orientada a Serviços SOA ou Service Oriented Architecture em inglês nos per mite descrever e entender como as pessoas a organização e os componentes de um sistema trabalham juntos usando serviços para atingir os objetivos de negócios A SOA é uma maneira de organizar e entender representações de organizações comunidades e sistemas para maximizar a agilidade escala e interoperabilidade A abordagem SOA é simples e envolve pessoas organizações e sistemas que fornecem serviços uns aos outros Nesse contexto um serviço é uma oferta de valor a uma pessoa por meio de uma interface bem definida e disponível para uma comunidade que pode ser o público em geral ou seja resulta em um trabalho prestado de uma pessoa ou instituição para outra Os serviços também nos permitem oferecer nossas capacidades a outros em troca de algum valor o que estabelece uma comunidade processo ou mercado O paradigma SOA funciona tão bem para integrar capacidades existentes quanto para criar e integrar novas capacidades 4 Figura 1 A arquitetura orientada a serviços e elementos relacionados Plataforma Processo Integração Prática Sistema Pessoas Arquitetura Fonte Adaptado de httpsstockadobecombrimages soaserviceorientedarchitecture112617289 A Modelagem Orientada a Objetos OOM ou ObjectOriented Modeling é uma abordagem para modelar um aplicativo usada no início do ciclo de vida do software por meio de uma abordagem orientada a objetos para o desenvolvimento do software O ciclo de vida do software é normalmente dividido em estágios que vão desde descrições abstratas do 5 problema até projetos código e teste e finalmente a implantação A modelagem que é realizada no início do processo antes de escrever o código são várias auxilia na comunicação e na abstração A necessidade da comunicação vem dos problemas de interpretação por parte dos usuários que nor malmente não conseguem entender a linguagem de programação ou código Por isso os diagra mas de modelo podem ser mais compreensíveis e permitirem que os usuários forneçam feedback aos desenvolvedores sobre a estrutura apropriada do sistema Um dos principais objetivos da abordagem orien tada a objetos é diminuir a lacuna semântica entre o sistema e o mundo real usando a terminologia que é a mesma das funções que os usuários exe cutam A modelagem é uma ferramenta essencial para facilitar o alcance desse objetivo Ter em mente a abstração é crucial na OOM pois um dos objetivos da maioria das metodologias de software é primeiro abordar as questões o quê e em seguida abordar as questões como Desse modo primeiro é necessário determinar a funcionalidade que o sistema deve fornecer sem considerar as restrições de implementação e em seguida é preciso considerar como tomar essa descrição abstrata e treinála em um design 6 e código implementáveis dadas as restrições como tecnologia e orçamento A modelagem pro porciona isso ao permitir descrições abstratas de processos e objetos que definem sua estrutura e comportamento essenciais A modelagem orientada a objetos geralmente é feita por meio de casos de uso e definições abstratas dos objetos mais importantes A linguagem mais comum usada para fazer modelagem orientada a objetos é a Unified Modeling Language UML do Object Management Group OMG A UML é uma linguagem de modelagem de uso geral e de desenvolvimento no campo da engenharia de software que se destina a fornecer uma maneira padrão de visualizar o projeto de um sistema A criação da UML foi originalmente motivada pelo desejo de padronizar os diferentes sistemas de notação e abordagens para o projeto de software Foi desenvolvido na Rational Software Corporation entre 19941995 com desenvolvimento adicional liderado por eles até 1996 Em 1997 a UML foi adotada como padrão pelo Object Management Group e tem sido gerenciada por esta organização desde então Em 2005 a UML também foi publicada pela International Organi zation for Standardization ISO como um padrão ISO aprovado Desde então o padrão é revisado 7 periodicamente para cobrir a última revisão da UML Na engenharia de software a maioria dos profissionais não usa UML mas produz diagramas informais desenhados à mão Esses diagramas no entanto geralmente incluem elementos da UML A UML vem evoluindo desde a segunda metade da década de 1990 e tem suas raízes nos métodos de programação orientados a objetos desenvolvidos no final da década de 1980 e início da década de 1990 Sua linha do tempo destaca a história dos métodos e notação de modelagem orientada a objetos Ela é originalmente baseada nas notações do mé todo Booch a Técnica de Modelagem de Objetos OMT ou ObjectModeling Technique e Engenha ria de Software Orientada a Objetos OOSE que integrou uma única linguagem A Rational Software Corporation contratou James Rumbaugh da General Electric em 1994 depois disso a empresa se tornou a fonte de duas das abordagens de modelagem orientada a objetos mais populares da época a técnica de modelagem de objetos de Rumbaugh OMT e o método de Grady Booch Eles logo foram auxiliados em seus esforços por Ivar Jacobson o criador do método de engenharia de software orientada a objetos 8 OOSE que se juntou a eles na Rational Software Corporation em 1995 Sob a liderança técnica de Rumbaugh Jacobson e Booch um consórcio chamado UML Partners foi organizado em 1996 para completar a especifi cação UML e propôs o Object Management Group para padronização A parceria também continha outras partes interessadas como a HP DEC IBM e Microsoft O projeto UML 10 da UML Partners foi proposto ao OMG em janeiro de 1997 pelo consórcio Durante o mesmo mês os Parceiros UML formaram um grupo projetado para definir o significado exato das construções de linguagem presidido por Cris Kobryn e administrado por Ed Eykholt para finalizar a especificação e integrála a outros esforços de padronização O resultado de todo este trabalho a UML 11 foi submetido ao OMG em agosto de 1997 e adotado pelo órgão em novembro de 1997 Após o primeiro lançamento uma forçatarefa foi criada para aprimorar a linguagem que lançou várias revisões menores a 13 14 e 15 Os padrões que produziu bem como o padrão original foram apontados como ambíguos e inconsistentes 9 A revisão principal da UML 20 substituiu a versão 15 em 2005 que foi desenvolvida com um consórcio ampliado para melhorar ainda mais a linguagem em busca de refletir a nova experiência no uso de seus recursos Figura 2 Diagrama UML Diagrama Diagrama de estrutura Diagrama de comportamento Diagrama de classe Diagrama de comportamento Diagrama de objeto Diagrama de atividade Diagrama de pacote Diagrama de sequência Diagrama de perfil Diagrama de estrutura composta Diagrama de desenvolvimento Diagrama de comunicação Diagrama de visão geral da interação Diagrama de casos de uso Diagrama de interação Diagrama de timing Diagrama de estado da máquina Fonte Adaptado de Wikimedia Embora a UML 21 nunca tenha sido lançada como uma especificação formal as versões 211 e 212 apareceram em 2007 seguidas pela UML 22 em fevereiro de 2009 A UML 23 foi lançada formal mente em maio de 2010 A UML 241 foi lançada formalmente em agosto de 2011 A UML 25 foi lançada em outubro de 2012 como uma versão em andamento e foi lançada oficialmente em junho 10 de 2015 A versão formal 251 foi adotada em dezembro de 2017 Embora originalmente destinada à documentação de projeto orientada a objetos a UML foi estendida a um conjunto maior de documentação de projeto e foi considerada útil em muitos contextos Ela não é um método de desenvolvimento por si só no entanto ela foi projetada para ser compatível com os principais métodos de desenvolvimento de software orientado a objetos de sua época como o OMT método Booch Objectory e especialmente RUP que foi originalmente destinado a ser usado quando o trabalho começou no Rational Software É crucial notarmos as diferenças entre o modelo UML e o grupo de diagramas em um sistema que são uma reprodução gráfica somente parcial do modelo de um sistema Um conjunto de dia gramas não precisa necessariamente abranger completamente o modelo Além disso a exclusão de um diagrama não altera o modelo em si que também pode conter documentação que orienta os elementos e diagramas do modelo Os diagramas UML simbolizam duas vertentes diferentes de um modelo de sistema a visão es tática e a visão dinâmica A visão estática ou baseada em estrutura enfatiza a estrutura estática do sistema usando objetos 11 atributos operações e relações Engloba diagramas de classe e diagramas de estrutura composta A visão dinâmica ou comportamental enfatiza a conduta dinâmica do sistema mostrando cola borações entre objetos e mudanças nos estados internos dos objetos Essa visão compreende diagramas de sequência diagramas de atividades e diagramas de máquina de estado Os modelos UML podem ser trocados entre fer ramentas UML usando o formato XML Metadata Interchange XML Na UML uma das principais ferramentas para mo delagem de comportamento é o modelo de casos de uso por meio de OOSE Os casos de uso são uma maneira de especificar os usos necessários de um sistema Normalmente eles são usados para capturar os requisitos de um sistema ou seja o que um sistema deve fazer A UML 2 tem muitas variedades de diagramas que são categorizados em dois tipos Alguns deles descrevem informações estruturais e os demais representam tipos gerais de comportamento envolvendo alguns que representam diferentes aspectos das interações Os diagramas de estrutura representam os as pectos estáticos do sistema Eles enfatizam as 12 coisas que devem estar presentes em um sistema que está sendo modelado Como os diagramas de estrutura representam a estrutura eles são usados extensivamente na documentação da arquitetura de software de sistemas de software Por exemplo o diagrama de componentes descreve como um sistema de software é dividido em componentes e mostra as dependências entre esses componentes Os diagramas de comportamento representam o aspecto dinâmico do sistema Eles destacam o que deve acontecer no sistema que está sendo modelado como os diagramas de comportamento ilustram o comportamento de um sistema e são usados extensivamente para descrever a funciona lidade dos sistemas de software Por exemplo o diagrama de atividades descreve o passo a passo das atividades de negócios e operacionais dos componentes em um sistema Os diagramas de interação que são um subgrupo de diagramas de comportamento realçam o fluxo de controle e dados entre os elementos no sistema que está sendo criado Por exemplo o diagrama de sequência mostra como os objetos se comunicam entre si em relação a uma sequência de mensagens O OMG criou uma arquitetura para executar uma metamodelagem com o foco de estabelecer a UML Esta é a MetaObject Facility MOF A MOF foi 13 desenvolvida como uma arquitetura composta por quatro camadas No topo há um modelo chamado M3 que é a linguagem usada pelo MetaObject Facility para construir metamodelos os chamados modelos M2 Um dos exemplos mais conhecidos de um mode lo de recursos de metaobjetos de camada 2 é o metamodelo UML que descreve a própria UML Esses modelos M2 formam os componentes da camada M1 e portanto os modelos M1 Estes seriam por exemplo modelos descritos em UML A última camada é a camada M0 ou camada de dados que é usada para explicar instâncias de tempo de execução do sistema O metamodelo pode ser estendido usando um mecanismo chamado estereotipagem que foi criticado como insuficienteinsustentável por Brian HendersonSellers e Cesar GonzalezPerez em uma de suas obras sobre o assunto Mesmo assim a UML foi comercializada e adaptada para muitos contextos principalmente corporativos Ainda que tenha sido tratado às vezes como uma bala de prata de design o uso indevido da UML com excessos pode levar a problemas pois projetar cada parte do sistema com ela é desnecessário Além disso ao utilizála é possível assumir que leigos podem projetar com ela 14 É considerada uma linguagem grande e complexa com muitas construções que pode ser considerada uma das características que dificultam o aprendi zado e consequentemente seu uso A partir disso entendamos melhor a modelagem orientada a serviços que é a disciplina de modela gem de sistemas de negócios e software que tem como finalidade projetar e especificar sistemas de negócios orientados a serviços dentro de uma variedade de estilos e paradigmas de arquitetura como arquitetura de aplicativos arquitetura orien tada a serviços microsserviços e computação em nuvem Qualquer método de modelagem orientada a serviços normalmente inclui uma linguagem de modelagem que pode ser empregada tanto pela organização do domínio do problema o negócio quanto pela organização do domínio da solução o departamento de Tecnologia da Informação TI cujas perspectivas únicas influenciam a vida do desenvolvimento do serviço a estratégia de ciclo e os projetos implementados usando essa estratégia A modelagem orientada a serviços normalmente se esforça para criar modelos que forneçam uma visão abrangente da análise design e arquitetura de todas as entidades de software em uma or 15 ganização que podem ser compreendidas por indivíduos com diversos níveis de conhecimento técnico e de negócios A modelagem orientada a serviços geralmente incentiva a visualização de entidades de software como ativos os ativos orientados a serviços e se refere a eles coletivamente como serviços Uma das principais preocupações do design de serviço é encontrar a granularidade de serviço correta tanto no nível de negócios o domínio quanto no nível técnico de contrato de interface Existem algumas abordagens populares da mode lagem orientada a serviços como a SDDM SOMA e SOMF 16 MODELAGEM DE COMPONENTES DE SOFTWARE A Engenharia de Software Baseada em Compo nentes CBSE ou ComponentBased Software Engineering em inglês também conhecida como Desenvolvimento Baseado em Componentes CBD ou ComponentBased Development é um ramo da engenharia de software que enfatiza o di recionamento de uma ampla variedade de funções disponíveis onde a segmentação é realizada em um determinado sistema de software É uma vertente baseada em reutilização para definir implementar e compor componentes in dependentes em um sistema Essa é uma prática projetada para trazer benefícios igualmente amplos de curto e longo prazo para o próprio software e as organizações que o patrocinam Profissionais de engenharia de software consideram os componentes como parte de uma plataforma básica orientada a serviços Os componentes desempenham esse papel em serviços da Web e mais recentemente em SOAs 17 Tais componentes são transformados de serviços da Web em serviços e em seguida herdam recur sos além dos componentes comuns SAIBA MAIS Para conhecer mais sobre a engenharia de software baseada em componentes assista aos vídeos a seguir Engenharia de software disponível em httpsyoutubeenHRCIB9PWw e Engenharia de sof tware Baseada em Componentes disponível em httpswwwyoutubecomwatchv1QBvGIl3LDM Os componentes podem gerar ou consumir eventos e podem ser usados em uma Arquitetura Orientada a Eventos EDA ou EventDriven Architectures em inglês Um único componente de software é um pacote de software serviço da Web recurso da Web ou módulo que encapsula um conjunto de funções ou dados relacionados SAIBA MAIS 18 Figura 3 Exemplo de Engenharia de Software Baseada em Componentes CBSE ComponentBased Software Engineering Checkout Saída CarProcessing Processamento Fonte Adaptado de Wikimedia Todos os processos do sistema são colocados em componentes separados portanto todos os dados e funcionalidades em cada componente são semanticamente relacionados bem como o conteúdo da classe Devido a esse princípio os componentes são muitas vezes referidos como modulares e coesos Em relação à coordenação em todo o sistema os componentes se comunicam entre si por meio de 19 interfaces Quando um componente fornece servi ços para o resto do sistema ele adota a interface fornecida para especificar os serviços que outros componentes podem usar e como eles podem ser usados Essa interface pode ser pensada como uma as sinatura de componente em que os clientes não precisam conhecer o funcionamento interno e a implementação do componente para usálo Esse princípio dá origem aos chamados componentes embalados SAIBA MAIS Para entender mais sobre o conceito de EDA ou arqui tetura orientada a eventos leia os artigos O que é uma arquitetura orientada por eventos disponível em httpswwwredhatcomptbrtopicsintegrationwhat iseventdrivenarchitecture EDA Arquitetura Orientada a Eventos disponível em httpsmediumcomalexribeiroedaarquiteturaorien tadaaeventosff197b2b429c e Elaborando projetos com a Arquitetura Orientada a Eventos disponível em httpswwwdevmediacombrelaborandoprojetoscom aarquiteturaorientadaaeventos32810 SAIBA MAIS 20 No entanto quando um componente precisa usar outro para funcionar ele adota uma interface de uso para especificar os serviços de que precisa Em alguns casos a interface usada é representada por uma notação de soquete aberto anexada à borda externa dele Outra propriedade importante dos componentes é que eles são substituíveis de modo que um componente pode substituir outro considerando o tempo de design ou tempo de execução se um componente sucessor atender aos requisitos do componente inicial como representado por uma interface Desse modo um componente pode ser substituído por uma versão atualizada ou alterna tiva sem quebrar o sistema no qual o componente opera Como regra geral para substituição de componentes o componente B pode substituir imediatamente o componente A se o componente B fornecer pelo menos tanto componente A quanto fornecido e não forem usados mais componentes do que o componente A Os componentes de software geralmente assumem a forma de objetos e não de classe ou coleções de objetos da programação orientada a objetos em alguma forma binária ou textual seguindo alguma Linguagem de Descrição de Interface IDL uma 21 linguagem de descrição de interface na qual os componentes podem ser independentes de outros componentes que existem Em outras palavras o componente é executado sem alterar seu códigofonte embora o compor tamento do códigofonte do componente possa mudar dependendo da extensibilidade do aplicativo fornecida por seu autor Quando um componente deve ser acessado ou compartilhado em contextos de execução ou links de rede técnicas como serialização ou empaco tamento são frequentemente empregadas para entregar o componente ao seu destino A reutilização é uma característica crucial de um componente de software considerado de alta qualidade Os programadores devem projetar e implementar componentes de software de tal forma que muitos programas diferentes possam reutilizálos Além disso testes de usabilidade baseados em componentes devem ser considerados quando os componentes de software interagem diretamente com os usuários É preciso esforço e conscientização significativos para escrever um componente de software que 22 seja efetivamente reutilizável Dessa forma os componentes precisam ser y Totalmente documentados y Exaustivamente testados y Robustos com verificação abrangente de va lidade de entrada y Capazes de devolver mensagens de erro apro priadas ou códigos de retorno y Projetados com a consciência de que serão colocados em usos imprevistos Por volta dos anos 60 os programadores construí ram bibliotecas de subrotinas científicas que eram reutilizáveis em uma ampla gama de aplicações científicas e de engenharia Embora essas biblio tecas de subrotinas reutilizassem algoritmos bem definidos de maneira eficaz elas tinham um domínio de aplicação limitado Os sites comerciais criavam rotineiramente programas de aplicativos a partir de módulos reutilizáveis escritos em linguagem assembly COBOL PL1 e outras linguagens de segunda e terceira geração usando bibliotecas de aplicativos do sistema e do usuário A partir de 2010 os componentes reutilizáveis modernos encapsulam as estruturas de dados e os algoritmos que são aplicados às estruturas de dados A engenharia de software fundamentada em componentes baseouse em teorias anterio 23 res de objetos arquiteturas estruturas e padrões de projeto de software além da extensa teoria da programação orientada a objetos e o projeto orientado a objetos de todos eles Acreditase que os componentes de software como a ideia de componentes de hardware usados por exemplo em telecomunicações podem em última análise tornarse intercambiáveis e confiáveis Por outro lado pode ser considerável um erro focar em componentes independentes ao invés do fra mework sem o qual eles não existiriam 24 MODELAGEM DE ARQUITETURA ORIENTADA A SERVIÇO Primeiramente é preciso termos em mente a SOA arquitetura orientada a serviços que é um para digma de arquitetura para definir como pessoas organizações e sistemas fornecem e usam serviços para alcançar resultados Várias abordagens foram propostas especifica mente para projetar e modelar serviços incluindo SDDM SOMA e SOMF A Metodologia de Design e Desenvolvimento Orientada a Serviços SDDM ou ServiceOriented Design and Development Methodology em inglês é um método de fusão criado e compilado por Michael Papazoglou e WillemJan van den Heuvel Tal método é importante pois entendemos que não se pode esperar que designers de SOA e desenvolvedores de serviços supervisionem um projeto complexo de desenvolvimento orientado a serviços sem contar com uma metodologia sólida de design e desenvolvimento Nele uma visão geral dos métodos e técnicas usados no design orientado a serviços é fornecida uma metodologia de desenvolvimento de serviços 25 do ponto de vista de produtores e solicitantes de serviços é abordada e a variedade de elementos SDDM disponíveis para essas funções deve ser analisada A Modelagem e Arquitetura Orientada a Servi ços SOMA ou ServiceOriented Modeling and Architecture em inglês é usada na modelagem de aplicativos de arquitetura orientada a serviços A SOMA é um método de análise e projeto de ponta a ponta que estende os métodos tradicionais de análise e projeto orientados a objetos e baseados em componentes baseado em três fases principais a identificação a especificação e a realização Tais fases são usadas para modelar os três prin cipais elementos de SOA que são os serviços os componentes que realizam os serviços também conhecidos como componentes de serviço e os fluxos que podem ser usados para compor serviços necessários em uma aplicação SOA Ela valida cada etapa da fase de projeto garantindo uma infraestrutura de negócios SOA totalmente integrada flexível e responsiva A IBM anunciou modelagem e arquitetura orien tada a serviços SOMA como sua metodologia relacionada a SOA em 2004 e publicou partes dela posteriormente 26 Baseada em vários anos de experiência prática que a IBM desenvolveu ao trabalhar com empresas que adotaram antecipadamente a SOA entende mos que a SOMA é uma abordagem flexível para resolver problemas corporativos que oferece o máximo retorno sobre o investimento A SOMA ajuda as empresas a implementar SOA para ter melhor visibilidade de seus processos de negó cios fornecendo as ferramentas necessárias para melhorar e crescer Se referindo ao domínio mais geral de modelagem de serviço necessário para projetar e criar a SOA ela abrange um escopo mais amplo e implementa a Análise e Design Orientado a Serviços SOAD ou Service Oriented Analysis and Design por meio da identificação especificação e realização de serviços e componentes que realizam esses ser viços também conhecidos como componentes de serviço além de fluxos que podem ser usados para compôlos A SOMA inclui um método de análise e design que estende os métodos tradicionais de análise e design orientados a objetos e são baseados em componentes para incluir preocupações relevantes e de suporte a SOA Além disso é um método SOA de ponta a ponta para a identificação especificação realização e 27 implementação de serviços incluindo serviços de informação componentes fluxos e processos Baseiase em técnicas atuais de áreas como aná lise de domínio agrupamento de áreas funcionais modelagem de processos de análise orientada a variabilidade desenvolvimento baseado em com ponentes análise orientada a objetos e design e modelagem de casos de uso apresentando novas técnicas como modelagem de serviço de meta criação de modelo de serviço e teste decisivo de serviço para ajudar a determinar a granularidade de um serviço A SOMA identifica serviços limites de componentes fluxos composições e informações por meio de técnicas complementares que incluem decompo sição de domínio modelagem de serviço objetivo e análise de ativos existentes O ciclo de vida do serviço em SOMA consiste nas fases de identificação especificação realização implementação implantação e gerenciamento nas quais os blocos de construção fundamentais da SOA são identificados refinados e implementados em cada fase Tais blocos consistem em serviços componentes fluxos e relacionados a eles infor mações políticas e contratos Já a Estrutura de Modelagem Orientada a Serviços SOMF ou ServiceOriented Modeling Framework 28 foi concebida pelo autor Michael Bell como uma linguagem de modelagem holística e antropo mórfica para desenvolvimento de software que emprega disciplinas e uma linguagem universal para fornecer soluções táticas e estratégicas para problemas corporativos O termo linguagem holística referese a uma lin guagem de modelagem que pode ser empregada para projetar qualquer aplicativo ambiente de negócios e tecnológico local ou distribuído Essa universalidade pode incluir o design de soluções de nível de aplicativo e de nível empresarial incluindo cenários SOA computação em nuvem ou ambien tes de big data O termo antropomórfico por outro lado afilia a linguagem SOMF à intuitividade de implementação e simplicidade de uso A SOMF é uma metodologia de ciclo de vida de desenvolvimento orientada a serviços um processo de modelagem específico de disciplina Ela oferece uma série de práticas e disciplinas de modelagem que contribuem para o desenvolvimento e mode lagem bemsucedidos do ciclo de vida orientado a serviços durante um projeto Ele ilustra os principais elementos que identificam os aspectos do que fazer de um esquema de de senvolvimento de serviços Esses são os pilares de modelagem que permitirão aos profissionais 29 elaborar um plano de projeto eficaz e identificar os marcos de uma iniciativa orientada a serviços seja um negócio de pequena ou grande escala ou um empreendimento tecnológico Existem quatro seções da estrutura de modelagem que identificam a direção geral e as unidades de trabalho correspondentes que compõem uma estratégia de modelagem orientada a serviços as práticas as de ambientes as disciplinas e as de artefatos Esses elementos revelam o contexto de uma ocupação de modelagem e não necessariamente descrevem o processo ou a sequência de ativi dades necessárias para cumprir os objetivos de modelagem Eles devem ser resolvidos durante o plano do projeto ou seja a estratégia de ciclo de vida de desenvolvimento orientada a serviços que normalmente define os limites da iniciativa prazo responsabilidades e marcos alcançáveis do pro jeto Observemos tais análises na figura a seguir 30 Figura 4 Estrutura de Modelagem Orientada a Serviços SOMF ServiceOriented Modeling Framework Práticas de modelagem orientadas a serviços Disciplina de conceituação de serviço Disciplina de arquitetura conceitual Serviço conceitual Arquitetura conceitual Serviço de solução Disciplina de descoberta e análise de serviços Disciplina de integração de negócios Serviço de análise Disciplina de design de serviço Disciplina de arquitetura lógica Disciplina de design Arquitetura lógica Arquitetura da solução Soluções de modelagem Fonte Adaptado de Wikimedia Já a SoaML fornece uma maneira padrão de arquitetar e modelar soluções SOA usando a Uni fied Modeling Language UML A SoaML usa os mecanismos de extensão integrados da UML para definir conceitos SOA em termos de conceitos UML existentes Em suma a Arquitetura Orientada à Linguagem de Modelagem de Serviço SoaML ou Service Modeling Language Oriented Architecture em in glês é um método padrão de projetar e modelar soluções SOA usando a UML A SoaML é um padrão do Object Management Group OMG que fornece uma linguagem de modelagem neutra de domínio para arquitetar e modelar SOA com o uso de UML 31 Um exemplo para aplicação da SoaML é com o Visual Paradigm uma ferramenta UML CASE O Visual Paradigm é um dos sistemas que suportam a modelagem de SOA com SoaML com ele esse perfil é organizado em cinco tipos de diagramas SoaML que são diagrama de interface de serviço de participante de serviço de contrato de serviço de arquitetura de serviços e de categorização de serviço SAIBA MAIS Para conhecer mais sobre o os diagramas e sistemas relacionados a SoaML acesse os conteúdos disponível nos links indicados a seguir Cada um deles fornece uma visão única para descrever e ajudar a entender os serviços e a arquitetura orientada a serviços Com binado com o uso de diagramas UML como diagrama de sequência diagrama de atividades diagrama de processos de negócios BPMN e modelo de motivação de negócios OMG BMM é possível descrever a SOA bem como indicar sua relevância técnica e comercial Tipos de diagrama com o Visual Paradigm httpswww visualparadigmcomfeaturessoamldiagramsandtools Sparx Systems Enterprise Architect httpssparxsys temscomproductsea SAIBA MAIS 32 Um dos diagramas de interface mais importantes é o de interface de serviço que podemos obser varmos na figura a seguir Figura 5 Exemplo de diagrama de interface de serviço Fonte Visual Paradigm Para entender o que é diagrama de interface de serviço devemos relembrar um conceito chave de SoaML o serviço 33 Conforme indicado na especificação SoaML serviço é um valor entregue a um consumidor por meio de uma interface bem definida Em SoaML um serviço pode ser especificado usando três abordagens interface simples interface de serviço e contrato de serviço A interface simples define o serviço unidirecio nal que não requer protocolo e permite serviços bidirecionais envolvendo a comunicação entre provedor e consumidor de serviços na conclusão de serviços O contrato de serviço define como as partes trabalham juntas O diagrama de interface de serviço permite a modelagem da especificação de serviço possível modelar interfaces simples e interfaces de serviço no diagrama de interface de serviço SAIBA MAIS A especificação SoaML fornece um metamodelo e um perfil UML para a categorização e design de serviços dentro de uma arquitetura orientada a serviços No link a seguir é possível ter acesso a todas as especificações da SoaML inglês httpswwwomgorgspecSoaML101PDF SAIBA MAIS 34 A SoaML padrão para modelagem de serviço foi lançada em sua versão 101 em maio de 2012 e sua primeira versão beta foi lançada em abril de 2009 Ela define os conceitos e os elementos e estereótipos correspondentes necessários para modelar aplicativos orientados a serviços O conceito mais importante na SoaML continuou sendo o de serviço que consiste em uma oferta de valor de acordo com uma ou mais capacidades definidas fornecendo uma interface com opera ções com parâmetros de entrada e saída e tipos associados e um contrato de serviço que define os papéis e interfaces envolvidos na execução do serviço Uma arquitetura de serviços é uma Colabo ração UML que mostra os participantes da rede ou comunidade de serviços os contratos de serviço para interação entre si e os papéis que cada um desempenha dentro de cada serviço específico Os participantes podem ser componentes de sof tware organizações ou sistemas que fornecem e usam serviços Os serviços são prestados por meio de portas de serviço e solicitados por meio de portas de requisição que são especializações de portas UML Os serviços podem ser modelados com uma interface de serviço ou interfaces UML simples que definem os elementos necessários para interagir com o serviço 35 O contrato de serviço define as interfaces funções e coreografias que os participantes concordam em usar para interagir entre si Um canal de atendi mento modela a comunicação entre consumido res e provedores e o tipo de mensagens permite especificar as informações trocadas dentro das operações O Sparx Systems Enterprise Architect é outro exemplo de ferramenta de modelagem e design visual baseada no OMG UML Com o Enterprise Architect é possível modelar arquiteturas de ser viços de forma rápida e simples através do uso de uma tecnologia MDG Model Driven Generation Technologies integrada ao instalador do Enterprise Architect Uma tecnologia MDG é um veículo para fornecer acesso aos recursos de uma tecnologia disponível comercialmente ou de uma tecnologia que você mesmo criou Esses recursos incluem uma ampla variedade de facilidades e ferramentas como perfis UML módulos de código scripts padrões imagens Tagged Value Types templates de re latórios templates de documentos vinculados e toolbox pages 36 SAIBA MAIS As tecnologias MDG permitem que os usuários estendam os recursos de modelagem do Enterprise Architect para domínios e notações específicas As tecnologias MDG se conectam perfeitamente ao Enterprise Architect para toolboxes adicionais perfis UML padrões modelos e outros recursos de modelagem Para conhecer os Downloads gratuitos da tecnologia MDG para Enterprise Architect inglês acesse https sparxsystemscomresourcesmdgtech Por fim preciso termos em mente que as facilidades SoaML por meio do Enterprise Architect ocorrem na forma de dois tipos de diagrama SoaML o diagrama de componente SoaML e diagrama de sequência SoaML SAIBA MAIS 37 EXERCÍCIO RESOLVIDO Exercício Consideremos o um programa chamado Encha de água em que basicamente se trate de um jogo de simulação onde o usuário deve encher um balde com o máximo volume possível de água A capacidade do balde no entanto é inicialmente desconhecida e pode variar entre 10 e 50 unidades A cada jogada o jogo sorteia uma quantidade de água mostra essa quantidade ao usuário e pergunta se o usuário deseja ou não utilizála A simulação termina quando o balde estiver cheio ou o usuário desistir de colocar mais água no balde Para facilitar o jogo avisa quando o volume armazenado chega ou ultrapassa a metade da capacidade do balde Desse modo como poderíamos desenvolver a situação proposta pelo jogo Observemos Parte A Modelamento inicial O programa abaixo descreve em Python esse comportamento O objetivo dessa primeira parte é modelar o si mulador e definir as ações desse objeto Se essa classe existisse o nosso programa estaria pronto Nos parece também que a classe Simulador vai precisar trabalhar com objetos do tipo Balde 38 Para chegar nesse programa inicial como o jogo precisa sortear quantidades de água de forma pseudoaleatória delegamos as funções para gerenciar esses sorteios à classe Simulador e imaginamos então que a classe precisa receber uma semente ao ser construída Os demais méto dos deposita e finaliza correspondem às demais ações de um jogo Parte B O próximo passo é definir a classe Simulador mas como ela depende de uma outra classe a Balde que nos parece mais simples de definir vamos começar pela definição de Balde Para ser utilizado em um jogo o objeto balde deve precisar dos atributos y Capacidade int que indica capacidade má xima do balde y Volume int volume atual de água no balde y Derramado água derramada y Cheio booleano indica se o balde está cheio Ao criar um Balde é necessário definir o valor do atributo capacidade podendo zerar os atributos volume e derramado Ao imprimir um Balde por exemplo contendo 12 unidades de volume ele deve corresponder ao 39 texto 12 caso esteja cheio e 12 caso ainda possua volume livre A classe deve ter o método depositaself v que recebe uma quantidade de água vol e atualiza o estado do objeto Balde Parte C Vamos definir agora a classe Simulador A ideia de se criar essa classe é agrupar o estado e ope rações específicas do simulador jogo Vamos incluir também no Simulador as operações com random e para isso o construtor dessa classe deve receber semente para o gerador de números pseudoaleatórios O construtor deve também inicializar os seguintes atributos y balde objeto Balde y vol volume sorteado y avisou indica se uma mensagem avisando se o balde atingiu ou passou da metade já foi dada Os demais métodos da classe são y sorteiaself sorteia um volume de água de 1 a 10 unidades atualizando o atributo vol e imprime esse volume y depositaself que adiciona o volume vol ao balde Observe que a função main usa o método deposita do Simulador mas esse volume deve ser passado do Simulador ao Balde simplificando as 40 ações necessárias na main O método deposita retorna True se o balde ficar cheio após a operação e imprime uma mensagem da primeira vez que o volume atingir ou passar da metade da capacidade y finalizaself imprime as seguintes mensagens Fim da simulação Capacidade do balde Volume final Balde está ou não cheio Volume derramado Parte D Agora é preciso que juntemos as partes anteriores para ter o programa completo O programa principal função main controla a entrada e a saída usando input e print com o usuário e o Simulador mantém o estado da simulação e controla o jogo Resolução 1 random utilizada na classe Simulador 2 import random 3 4 CONSTANTES 5 CAPMIN 10 6 CAPMAX 51 Capacidade maxima ja ajustada com 1 para randrange 7 VOLMIN 1 41 8 VOLMAX 11 volume sorteado maximo ja ajustado com 1 9 10 11 12 def main 13 Controla a entrada e saida 14 15 leitura da semente para criar o simulador 16 semente intinputDigite a semente do gerador aleato rio 17 jogo Simuladorsemente 18 continua True 19 cheio False 20 21 print Inicio da simulacao 22 while not cheio and continua 23 sorteia o proximo valor 24 jogosorteia 25 opcao inputDeseja adicionar sn 26 if opcao s 27 cheio jogodeposita 28 else 29 continua False 30 jogofinaliza 31 32 33 34class Balde 35 36 A classe Balde modela um recipente com capacidade cap e 37 volume atual vol Ela armazena tambem o volume derramado e 38 indica se esta cheio 39 40 def initself c 41 selfcap c 42 selfvol 0 volume atual 43 selfder 0 volume derramado 44 selfcheio False 45 42 46 def depositaself v 47 48 Deposita um volume de agua v e atualiza o estado do Balde 49 50 selfvol v 51 if selfvol selfcap 52 selfcheio True 53 selfder selfvol selfcap 54 selfvol selfcap 55 56 def reprself 57 if selfvol selfcap 58 return 2dselfvol 59 else 60 return 2dselfvol 61 62 63 64class Simulador 65 classe Simulador mantem o estado da simulacao e 66 os procedimentos para simular Note que a classe 67 Simulador esconde o modulo random da funcao main 68 69 def initself semente 70 randomseedsemente 71 capacidade randomrandrangeCAPMIN CAPMAX 72 selfrec Baldecapacidade 73 selfvol 0 74 selfavisou False 75 76 def sorteiaself 77 selfvol randomrandrangeVOLMIN VOLMAX 78 print 79 printVolume atual selfrecvol 80 printVolume sorteado selfvol 81 82 def depositaself 83 adiciona o ultimo volume sorteado selfvol 84 ao balde e retorna True se o 85 balde estiver cheio e False caso contrario 86 43 87 selfrecdeposita selfvol 88 89 if selfrecvol selfreccap2 and not selfavisou 90 selfavisou True 91 printO volume do balde atingiupassou a metade 92 93 return selfreccheio 94 95 def finalizaself 96 print Fim da simulacao 97 printCapacidade do balde d selfreccap 98 printVolume final d selfrecvol 99 100 if selfrecder 0 101 printBalde esta cheio e houve derramamento de agua 102 printVolume derramado foi d selfrecder 103 else 104 if selfreccheio 105 printBalde esta cheio e nao houve derramamen to de agua 106 elif selfreccap selfrecvol selfvol 107 printBalde nao esta cheio 108 printHavia espaco para o ultimo volume sortea do d selfvol 109 else 110 printBalde nao esta cheio 111 printNao havia espaco para o ultimo volume sorteado d selfvol 112 113 114 115 116main 117 118 Fonte Pandaime 44 SAIBA MAIS Além do exemplo apresentado você também encontra rá diversos exercícios resolvidos ou que poderão ser resolvidos sobre alguns dos assuntos apresentados nesta unidade POO e UML Consulte os links httpswwwfreecodecamporgportuguesenews40pro jetosemjavascriptparainiciantesideiassimplespara comecaraprogramaremjs httpspensepythoncaravelaclub15classeseobje tos09exercicioshtml httpsdocplayercombr196038860Listadeexerci ciosdepooempythonejavacomsolucaohtml httpswwwcomputersciencemastercombr exerciciosistemadelanchonete httpwaldersoncomlivroumlUML205120Exerci cios2020Ana20Cristina20Melopdf SAIBA MAIS 45 CONSIDERAÇÕES FINAIS Nessa unidade estudamos conceitos sobre mo delagem de sistemas em SOA analisando seus conceitos básicos e sua relação com a modelagem orientada a objetos e serviços Alguns exemplos de elementos em UML foram apresentados além dos conceitos de objetos nesse âmbito Discorremos também sobre a modelagem de com ponentes de software a partir da ideia de que o desenvolvimento de softwares com componentes reutilizáveis seja uma das maiores qualidades para a SOA e para qualquer outro contexto Por fim entendemos os conceitos de modelagem de arquitetura orientada a serviço assim como os conceitos de SOMA SoaML SOMF e SDDM foram brevemente fundamentados compreendendo que cada estrutura possui suas características espe cíficas e são aplicadas para funções diferentes Além disso entendemos também a importância dos diagramas e linguagens para a SOA 46 Referências Bibliográficas Consultadas ERL T SOA princípios e Design de Serviços São Paulo Pearson 2009 Biblioteca Virtual Pearson 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 Pearson GALLOTTI Giocondo M A Qualidade de Software São Paulo Pearson Education do Brasil 2016 Ebook Biblioteca Virtual Pearson HIDAYAT Nur Serviceoriented modeling and architecture IBM developer works 2004 sl v 9 n 1 p 116 jul 2005 Disponível em https wwwacademiaedu992569Serviceoriented modelingandarchitecture Acesso em 21 jul 2022 IME USP Aulas de Introdução à Computação com Python Disponível em httpspandaime uspbraulasPythonstaticaulasPythonaula19 html Acesso em 21 jul 2022 MARINHO A L Análise e modelagem de sistemas São Paulo Pearson Education do Brasil 2016 Ebook Biblioteca Virtual Pearson O QUE é uma arquitetura orientada por eventos RedHat 27 set 2019 Disponível em https wwwredhatcomptbrtopicsintegrationwhat iseventdrivenarchitecture Acesso em 21 jul 2022 PRESSMAN R S MAXIM B R Engenharia de Software uma abordagem profissional 9 ed Porto Alegre Bookman 2021 Ebook Minha Biblioteca RIBEIRO A EDA Arquitetura Orientada a Eventos Medium 18 nov 2019 Disponível em httpsmediumcomalexribeiroeda arquiteturaorientadaaeventosff197b2b429c Acesso em 21 jul 2022 SOMMERVILLE I Engenharia de software 10 ed São Paulo Pearson Brasil 2019 Ebook Biblioteca Virtual Pearson SOAML Diagrams and Tool Visual Paradigm sd Disponível em httpswwwvisual paradigmcomfeaturessoamldiagramsand tools Acesso em 21 jul 2022 SERVICE oriented architecture Modeling Language SoaML Specification OMG mai 2012Disponível em httpswwwomgorgspec SoaML101PDF Acesso em 21 jul 2022 fam ONLINE