Método para modelagem de processos de negócios na engenharia de requisitos de software

Transcrição

1 UNIVERSIDADE FEDERAL DO ABC CURSO DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO DISSERTAÇÃO DE MESTRADO SHEILA LEAL SANTOS Método para modelagem de processos de negócios na engenharia de requisitos de software Santo André 2014

2 CURSO DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO DISSERTAÇÃO DE MESTRADO SHEILA LEAL SANTOS Método para modelagem de processos de negócios na engenharia de requisitos de software Dissertação de Mestrado apresentada ao Programa de Pós-Graduação em Ciência da Computação da Universidade Federal do ABC UFABC para a obtenção do Título de Mestre em Ciência da Computação. Área de concentração: Engenharia de Software Linha de Pesquisa: Sistemas de Computação Orientadora: Prof.ª Dr.ª Fabiana Soares Santana Santo André 2014

3

4 DEDICATÓRIA À minha tia Branca, que partiu tão nova, deixando uma dor incurável. Tia, te amo muito e sempre vou te amar. À minha família, meu alicerce. Muito obrigada pelo apoio, torcida e carinho. Amo vocês.

5 AGRADECIMENTOS Primeiramente, agradeço a Deus por ter me dado forças para continuar, pois mesmo eu sendo imperfeita, falha e pecadora, nunca me abandonou e sempre tem se mostrado ser fiel e justo. À minha família, minha mãe Izete, meu pai Flaviano Fernandes e minha irmã Cintia pelo constante apoio e carinho, por acreditarem que eu sou capaz, pelas orações fervorosas nos momentos mais difíceis e por compreenderem cada momento de ausência. Um agradecimento especial a minha avó Isbela Norberto Leal, com 94 anos. Obrigada por tudo e desculpe a minha ausência durante a elaboração deste trabalho. Te amo muito. Às minhas sobrinhas lindas Renata Santos Rangel e Sophia Santos Rangel. Obrigada meus amores pelos momentos em que pude brincar com vocês, único meio que encontrava para esquecer os problemas e as pressões. À minha orientadora Fabiana Soares Santana, obrigada por acreditar neste trabalho, pela torcida, pela paciência, conselhos, pela oportunidade, pelo carinho, pelo aprendizado adquirido durante essa longa caminhada. Muito obrigada! Ao professor e amigo Jorge Becerra, ao qual serei eternamente grata pelo aprendizado, oportunidade, experiência adquirida e base para todo aprendizado. Ao amigo Leonardo Dias pelo aprendizado, por me fazer entender, por todas as cobranças, por todas as críticas construtivas, as quais eu pude aprender. Muito obrigada! Ao Silvio Trasmonte, pela oportunidade de colocar a teoria em prática, onde pude aprimorar os meus conhecimentos e ter um maior entendimento para a realização deste trabalho. Ao Profº. Drº. Wagner Tanaka Botelho, que esteve presente em um momento de pressão, me encorajando e me mostrando que eu sou capaz. Muito obrigada! Ao Profº.Drº Ronaldo Prati, pela dedicação e por estar sempre presente e disposto a resolver todos os problemas. À minha amiga, irmã, Tatiana Aparecida, não há palavras nesse mundo que possa expressar a minha imensa gratidão só me resta agradecer pelo constante apoio, por cada palavra de carinho. Obrigada por me ajudar a levantar num momento de muita dor. Obrigada por estar presente no momento em que eu pensei em desistir, mas você me encorajou e me ajudou a levantar. Muito obrigada!

6 À amiga Rafaela Godoi, por todas as suas palavras encorajadoras. Estas sempre chegaram na hora certa para me fortalecer e me encorajar. Muito obrigada! À minha amiga Silvia Scheunemann Silva, muito obrigada por estar sempre presente, por cada palavra de consolo e por secar cada lágrima minha. À amiga Andréia Gusmão, obrigada pelas risadas e pelo constante apoio. Estará sempre presente no meu coração. Aos amigos que encontrei durante essa difícil caminhada: Luciano Barros e Cleonice Caro. Sempre tivemos um ao outro e, quando faltava força para continuar, estávamos ali para uma palavra de carinho, um gesto de ternura que nos motivava, nos encorajando a seguir. Somos todos guerreiros! Aos professores Sueli Loddi, Wilson Vendramel e Rosângela Krong, sem o apoio de vocês não teria ingressado no programa de Mestrado da UFABC. A todos que de uma forma direta ou indireta, seja em palavras, seja em ações, contribuíram para a realização deste trabalho.

7 FICHA CATALOGRÁFICA SANTOS, SHEILA LEAL. MÉTODO PARA MODELAGEM DE PROCESSOS DE NEGÓCIOS NA ENGENHARIA DE REQUISITOS DE SOFTWARE. S. L. SANTOS, SANTO ANDRÉ, PÁGINAS. DISSERTAÇÃO DE MESTRADO - CENTRO DE MATEMÁTICA, COMPUTAÇÃO E COGNIÇÃO, UNIVERSIDADE FEDERAL DO ABC. 1. INTRODUÇÃO; 2. ARQUITETURA ORIENTADA A SERVIÇOS; 3. TRABALHOS RELACIONADOS; 4. PROPOSTA PARA APLICAÇÃO DE PROCESSOS NA ENGENHARIA DE REQUISITOS EM SOA; 5. APLICAÇÃO DO MÉTODO; 6. CONSIDERAÇÕES FINAIS; 7. REFERÊNCIAS BIBLIOGRÁFICAS.

8 RESUMO SANTOS, SHEILA LEAL. Método para modelagem de processos de negócios na engenharia de requisitos de software f. Dissertação de Mestrado Centro de Matemática, Computação e Cognição Universidade Federal do ABC UFABC, Santo André, São Paulo. As empresas produtoras de software precisam de métodos eficientes para obter resultados competitivos. Uma das principais causas dos resultados negativos em projetos de software se deve às deficiências na engenharia de requisitos de software. A especificação de requisitos inadequada ou incompleta pode levar à construção de sistemas que não estão em conformidade com as necessidades dos clientes, resultando no aumento de custos, atrasos nos cronogramas e realização de atividades desnecessárias. A fim de minimizar os problemas na especificação de requisitos, as boas práticas de engenharia de software recomendam o entendimento adequado do ambiente de tecnologia da informação (TI) e das regras de negócio. O uso de processos de negócio tem sido adotado pela maioria das organizações para mapear as suas necessidades e alinhar o conhecimento entre as equipes de negócio e de TI. BPMN (Business Process Modeling Notation, no original em inglês, ou Notação para Modelagem de Processos de Negócios) é a notação mais comumente adotada pelo mercado para a modelagem de processos de negócio, com diversas ferramentas disponíveis para o mapeamento e simulação de processos. Além da preocupação com os processos de negócio, as organizações têm adotado arquiteturas orientadas a serviços (SOA, Service Oriented Architectures, no original em inglês) com o intuito de facilitar a integração entre processos e tecnologia, resultando em soluções mais flexíveis para atender às constantes necessidades de mudanças e oportunidades de negócio. A união de BPMN e SOA permite o melhor entendimento dos sistemas através do mapeamento e modelagem dos processos de negócio, a partir dos quais é possível identificar os serviços que devem ser encapsulados dentro de um determinado ambiente tecnológico. O resultado é o aumento na produtividade, a melhoria na qualidade dos sistemas (QoS, Quality of Software, no original em inglês) e a redução de custos. Este trabalho propõe um método para modelagem de processos na engenharia de requisitos, incorporando formalmente o uso de processos de negócios na especificação dos requisitos de software. Um estudo de caso foi desenvolvido para experimentar o método proposto e mostrar a sua aplicação. Embora experimentos adicionais sejam recomendados, os resultados do estudo de caso foram promissores e mostram que a análise minuciosa dos processos de negócios na etapa de especificação de requisitos auxilia no entendimento e na

9 identificação mais precisa dos requisitos do sistema, melhorando o potencial de sucesso na produção de software. Palavras-chave: processos, engenharia de requisitos de software, arquiteturas orientada a serviços (SOA).

10 ABSTRACT SANTOS, SHEILA LEAL. Method for business processes modeling in the software requirements engineering p. Master s Thesis - Centro de Matemática, Computação e Cognição, Universidade Federal do ABC, Santo André, São Paulo. Producing software companies need effective methods to achieve competitive results. A major cause of adverse outcomes in software projects is due to deficiencies in the software requirements engineering. The specification of inadequate or incomplete requirements can lead to the construction of systems that are not in accordance with customer needs, resulting in increased costs, schedule delays, and development of unnecessary activities. In order to minimize the problems in the requirements specification, best practices in software engineering recommend a proper understanding of the information technology (IT) environment and of the business rules. The use of business processes has been adopted by many organizations to map their needs and to align the knowledge among business teams and IT. BPMN (Business Process Modeling Notation) is the notation most commonly adopted by the software companies for business processes modeling. Various software tools are available for processes mapping and simulation. In addition to the concern with business processes, many organizations are adopting service-oriented architectures (SOA) in order to facilitate the integration between processes and technology, resulting in more flexible solutions to meet the ever changing IT needs and the new business opportunities. The union of BPMN and SOA allows a better understanding of the systems to be developed by mapping and modeling business processes, from which it is possible to identify the services that should be encapsulated within a particular technological environment. Results include increased productivity, improved quality of software (QoS) and cost reduction. This work proposes a method for including the processes modeling as part of the requirements engineering, formally incorporating the use of business processes in the software requirements specification. A case study was developed to experiment the proposed method and to illustrate its application. Although further experiments are recommended, the results of the case study are promising and show that a thorough analysis of the business processes as part of the requirements specification phase helps in understanding and obtaining a more accurate identification of the system requirements, improving the potential for successful software production.

11 Keywords: processes, software requirements engineering, service-oriented architectures (SOA).

12 SUMÁRIO 1. INTRODUÇÃO MOTIVAÇÃO OBJETIVO MÉTODO ABRANGÊNCIA ORGANIZAÇÃO DO TRABALHO MATERIAIS E MÉTODOS ARQUITETURA ORIENTADA A SERVIÇOS WEB SERVICES PROTOCOLO HTTP XML SOAP WSDL UDDI SOFTWARE COMO SERVIÇO PROCESSO DE REFERÊNCIA DE NEGÓCIO ENGENHARIA DE REQUISITOS MODELOS DE REQUISITOS INTERNATIONAL STANDARD ISO/IEC/IEEE 29148:2011 SYSTEMS AND SOFTWARE ENGINEERING LIFE CICLE PROCESS REQUIREMENTS ENGINEERING TRABALHOS RELACIONADOS EXTRAÇÃO DE REQUISITOS DE SOFTWARE ESPECIFICAÇÃO DE CASO DE USO CONNECTION GATEWAY... 47

13 INTERMEDIATE EVENTS START EVENT E END EVENT TASKS ESPECIFICAÇÃO DE ATIVIDADES ESPECIFICAÇÃO DE CLASSES TRABALHOS RELACIONADOS PROPOSTA PARA APLICAÇÃO DE PROCESSOS NA ENGENHARIA DE REQUISITOS EM SOA APLICAÇÃO DO MÉTODO AS IS ESTRATÉGIA TO BE EXTRAÇÃO DE REQUISITOS ESPECIFICAÇÃO IMPLEMENTAÇÃO DOS PROCESSOS BizAgi Xpress IMPLEMENTAÇÃO DOS PROCESSOS JBPM CONSIDERAÇÕES FINAIS PRINCIPAIS CONTRIBUIÇÕES DO TRABALHO PUBLICAÇÕES ASSOCIADAS CONCLUSÃO TRABALHOS FUTUROS REFERÊNCIAS BIBLIOGRÁFICAS...100

14 LISTA DE FIGURAS 1. MERCADO COMPARATIVO DE ESB EM NIVEL MUNDIAL SINTAXE DE UMA MENSAGEM SOAP ELEMENTO CORPO RESPOSTA DOCUMENTOS WSDL ESQUEMA REPRESENTANDO OS PASSOS NA UTILIZAÇÃO DE UM SERVIÇO WEB PROTOCOLOS UTILIZADOS DIMENSÕES CRÍTICAS DO PROCESSO SUBPROCESSO EMISSÃO DE POLUENTES CASO DE USO EMISSÃO DE POLUENTS MÉTODO PROPOSTO ESTRUTURA PROPOSTA ESTRUTURA PROPOSTA BIZAGIXPRESS MACRO PROCESSO SUBPROCESSODE SERVIÇO SUBPROCESSO AVALIAÇÃO DO CICLO DE VIDA SUBPROCESSO REDUZ ELIMINA RESÍDUOS CICLO DE VIDA SUBPROCESSO TIPO DE RECURSO EMISSÃO DE POLUENTES... 67

15 20. SUBPROCESSO IMPACTO DE PRODUÇÃO SUBPROCESSO AVALIAÇÃO DA DISTRIBUIÇÃO SUBPROCESSO UTILIZAÇÃO SUBPROCESSO DISPOSIÇÃO DE RESÍDUO MACRO PROCESSO TO BE SUBPROCESSO PRODUTO TO BE AVALIAÇÃO SIMPLIFICADA TO BE REDUZIR ELIMINAR RESÍDUOS TO BE SUBPROCESSO AVALIAÇÃO DO CICLO DE VIDA TO BE SUBPROCESSO TIPO DE RECURSO TO BE SUBPROCESSO EMISSÃO DE POLUENTES TO BE SUBPROCESSO IMPACTO DE PRODUÇÃO TO BE AVALIAÇÃO DA DISTRIBUIÇÃO TO BE SUBPROCESSO UTILIZAÇÃO TO BE SUBPROCESSO DISPOSIÇÃO DE RESÍDUOS TO BE SUBPROCESSO PRODUTO TELA PARA VERIFICAR TRANSPORTE MODELO DE DADOS DO NEGÓCIO ATIVIDADES HABILITADAS PARA CRIAÇÃO DE FORMULÁRIOS CRIAÇÃO DE FORMULÁRIOS DEFINIÇÃO DE EXPRESSÕES (CONDIÇÕES)... 88

16 41. PARÂMETRO CONSULTA AO BANCO DE DADOS WSDL GERADO AUTOMATICAMENTE PORTAL DOS PROCESSOS EXECUÇÃO DOS PROCESSOS MEDIÇÃO DOS PROCESSOS REPRESENTAÇÃO JPDL PROCESSOS JBPM - CONSOLE... 96

17 LISTA DE TABELAS 1. MÉTODO ADOTADO FLUXOS PRINCIPAIS OBJETOS DE CONEXÃO POOLS E LANES ELEMENTOS DOS ARTEFATOS RESUMO DAS ATIVIDADES BPEL TRANSFORMAÇÃO DA BPMN PARA DIAGRAMA DE CASO DE USO PRINCIPAIS ELEMENTOS DA BPMN E SUAS HEURÍSTICAS VANTAGENS E DESVANTAGENS BizAgi Xpress VANTAGENS E DESVANTAGENS JBPM... 96

18 LISTA DE ABREVIATURAS E SIGLAS API: Application Programming Interface, no original em inglês, ou Interface de Programação de Aplicativos. ASP: Application Service Provider, no original em inglês, ou Provedor de Serviço de Aplicação. BPEL: Business Process Execution Language, no original em inglês, ou Linguagem de Execução de Processos de Negócios. BPM: Business Process Management, no original em inglês, ou Gerenciamento de Processos de Negócios. BPMI: Business Process Management Initiative, no original em inglês, ou Instituição de Gerenciamento de Processos de Negócios. BPMN: Business Process Modeling Notation, no original em inglês, ou Notação para Modelagem de Processos de Negócios. BPMS: Business Process Modeling Suite, no original em inglês, ou Suite para Modelagem de Processos de Negócios. CO: Monóxido de carbono DS: Design Sustentável ERP: Enterprise Resource Planning, no original em inglês, ou Planejamento de Recursos Empresariais. ESB: Enterprise Service Bus, no original em inglês ou Barramento de Serviços. FDD: Feature Driven Development, no original em inglês, ou Desenvolvimento Guiado por Funcionalidades. HC: Hidrocarboneto

19 HTML: HyperText Markup Language, no original em inglês ou Linguagem de Marcação de Hipertexto. HTTP: Hiper Text Transfer Protocol, no original em inglês ou Protocolo de Transferência de Hipertexto. IBM: International Business Machines. IEEE: Institute of Electrical and Electronic Engineers. ISEI: International Conference on Ecological Informatics. JPDL: Process Definition Language, no original em inglês. N2: Nitrogênio Molecular NOX: Óxidos de Nitrogênio RF: Requisitos Funcionais SAAS: Software as a Service, no original em inglês, ou Software como Serviço. SEI: Software Engineering Institute, no original em inglês, ou Instituto de Engenharia de Software. SMTP: Simple Mail Transfer Protocol, no original em inglês, ou Protocolo de Transferência de Correio Simples. SOA: Service-Oriented Architecture, no original em inglês, ou Arquitetura Orientada a Serviços. SOAP: Simple Object Access Protocol, no original em inglês, ou Protocolo Simples de Acesso a Objetos. TI: Tecnologia da Informação UDDI: Universal Description Discovery and Integration, no original em inglês, ou Integração e Descoberta da Descrição Universal. UFABC: Universidade Federal do ABC.

20 URL: Uniform Resource Locator, no original em inglês, ou Localizador Uniforme de Recursos. OTAN: Organização do Tratado do Atlântico Norte. XML: Extensible Markup Language, no original em inglês, ou Linguagem de Marcação. XP: Extreme Programming, no original em inglês, ou Programação Extrema. W3C: World Wide Web Consortium. WS: Web Services, no original em inglês, ou Serviço Web. WSDL: Web Services Description Language, no original em inglês, ou Linguagem para Descrição de Serviços Web.

21

22 1. INTRODUÇÃO 1.1. MOTIVAÇÃO As organizações estão inseridas em um ambiente competitivo e precisam de eficiência e eficácia para a realização dos seus objetivos. As empresas produtoras de software não são exceção. No entanto, um dos desafios relacionados à engenharia de software está em como minimizar os erros encontrados no desenvolvimento de software (SOMMERVILLE, 2007). Sabe-se que a grande maioria dos erros deve-se ao não entendimento das necessidades dos clientes. Não há uma explicação simples para este fenômeno, mas diversos trabalhos apontam deficiências nos requisitos dos sistemas como uma das principais causas de fracassos em projetos de software. Uma pesquisa realizada pelo Standish Group (2013) com 350 companhias e projetos indica que apenas 16,2% dos projetos são concluídos com sucesso, 52,7% são considerados problemáticos, pois não atendem as necessidades dos usuários e têm custos excessivos, e 31,1% são cancelados antes de serem completados, representando um desperdício da ordem de US$ 81 bilhões. A fim de identificar os principais fatores que levam à distribuição apresentada, foi realizada uma nova pesquisa, onde diversos fatores foram identificados como críticos, a saber: 1. Falta de especificação de requisitos; 2. Requisitos incompletos; 3. Mudança de requisitos; 4. Falta de apoio executivo; 5. Tecnologias imaturas; 6. Falta de recursos; 7. Expectativas irreais; 8. Tecnologias novas; e 9. A comunicação entre o usuário e o desenvolvedor é muito fraca (STANDISH GROUP apud PFLEEGER, 2004). Nota-se, portanto, que a falta de habilidade para definir adequadamente os requisitos de software e para lidar com os clientes e usuários são os principais fatores de falhas no desenvolvimento de software. Além disso, as falhas na especificação de requisitos podem resultar na não identificação de requisitos importantes ou na especificação de requisitos com conteúdo inadequado. Uma especificação de requisitos inadequada ou incompleta pode levar à produção de sistemas que não atendem às necessidades dos clientes, aumento de custos, potenciais atrasos no cronograma e realização de atividades duplicadas ou desnecessárias, entre outros fatores que prejudicam o desenvolvimento de software (JIANG, 2000). Para minimizar os problemas relacionados com a especificação de requisitos, as empresas produtoras de software precisam aplicar estratégias de TI (Tecnologia da Informação) que sejam capazes de alinhar os recursos de hardware, as necessidades do negócio e as boas práticas de engenharia de software para reduzir os custos e aumentar a 21

23 produtividade e a qualidade dos produtos gerados. Isso ocorre através do entendimento do negócio e do ambiente de TI (SOMMERVILLE, 2007). Dessa forma, diversas empresas têm adotado o uso de processos de negócio com a finalidade de obter um maior entendimento das suas necessidades e promover o alinhamento entre a equipe de negócio e a equipe de desenvolvimento de software, proporcionando um detalhamento adequado das atividades a serem executadas (SANTANA, 2010). Os processos de negócio permitem uma visão corporativa das soluções de software e apontam claramente as oportunidades e deficiências do ambiente. Atrelada ao processo de negócios está a BPMN é a notação mais adotada pelo mercado para a modelagem de processos de negócio, com diversas ferramentas disponíveis para o mapeamento e simulação de processos (SANTANA, 2010). A notação permite visualizar os detalhes de cada processo e, dependendo da sua complexidade, representá-lo em subprocessos independentes. Além disso, permite a execução dos processos de negócios através da construção orientada a serviços. Porém, a arquitetura orientada a serviços não prevê o uso de processos de negócios para a definição dos requisitos de software. No entanto, existe uma conexão possível entre as três partes: SOA, BPMN e especificação de requisitos. Isso ocorre porque, nos sistemas orientados a serviço, a execução do software é muito similar à execução de um processo (SANTANA, 2009). Em geral, os serviços são orquestrados em uma linguagem específica chamada BPEL (Business Process Execution Language, no original em inglês, ou Linguagem para Execução de Processos de Negócios), que se encarrega de instanciar os serviços de forma ordenada, como definido no processo. A tradução de BPMN para BPEL pode ser feita de forma automática, pois já existem diversas ferramentas para isso. Desta forma, existe uma ligação entre SOA e BPMN OBJETIVO Este trabalho tem como objetivo propor um método para incorporar os processos de negócios como ferramenta na engenharia de requisitos. Para experimentar o método proposto, será considerado um estudo de caso, baseado na definição dos requisitos de software para o seguinte processo: design sustentável, aplicando os conhecimentos adquiridos para a construção de processos de negócio usando BPMN. A partir da análise individual de cada atividade do processo apresentado, serão identificados os requisitos de software. Espera-se que os resultados obtidos nesse trabalho possam ajudar na etapa de especificação de requisitos através da análise minuciosa dos processos de negócios. 22

24 1.3. MÉTODO Com o intuito de atender o objetivo proposto, o método adotado é apresentado na tabela 1, envolvendo os principais passos para o desenvolvimento deste trabalho. Principais passos Descrição 1º Estudo do domínio Consiste no entendimento do domínio do problema. 2º BPMN Tem como finalidade realizar o mapeamento e modelagem do estudo de caso proposto. 3º Ciclo BPM Aplicar o ciclo BPM no estudo de caso design sustentável. 4º Método proposto para elaboração da especificação de requisitos. Consiste em propor um método para incorporar processos de negócios como ferramenta na engenharia de requisitos. No entanto, não está no escopo deste trabalho de dissertação desenvolver o documento de requisitos. 5º Aplicar o método proposto Esta etapa visa realizar a aplicação do método proposto utilizando o estudo de caso design sustentável. 6º Implementação dos serviços Consiste em utilizar processos para a implementação dos serviços. 7º Analisar os resultados obtidos A análise será realizada através de uma comparação da BPMN juntamente com o documento de requisitos proposto pela ISO/IEC/IEEE 29148:2011. Tabela 1: Método adotado Fonte: LEAL (2014) 1.4. ABRANGÊNCIA O método proposto neste trabalho foi aplicado em um modelo não organizacional, no entanto, pode ser aplicado em uma organização de pequena, média e grande porte, onde os requisitos podem ser de duas formas: (1) requisitos claros e completos, mas que mesmo assim, há necessidade de obter um gerenciamento dos processos de negócios e das possíveis mudanças que podem ocorrer durante a fase de elicitação. (2) requisitos incompletos, neste caso o uso do BPM e BPMN justifica-se pela necessidade de entender as necessidades do cliente, as regras de negócios e os seus processos de negócios onde espera-se uma melhora nos resultados obtidos na etapa de levantamento de requisitos ORGANIZAÇÃO DO TRABALHO O capítulo inicial deste trabalho apresenta uma introdução ao problema e os principais objetivos da proposta de mestrado. 23

25 O segundo capítulo apresenta os conceitos necessários para o desenvolvimento da proposta de mestrado, incluindo: (2.1) arquiteturas orientadas a serviço, (2.2) SaaS (Software as a Service, no original em inglês, ou Software como Serviço), (2.3) processo de referência de negócio, (2.4) engenharia de requisitos, (2.5) modelo de requisitos e (3) trabalhos relacionados. O quarto capítulo apresenta o método deste trabalho. E para finalizar, o quinto capítulo apresenta a aplicação do método proposto. 24

26 2. MATERIAIS E MÉTODOS deste trabalho. Esta seção descreve os principais conceitos necessários para o desenvolvimento 2.1. Arquitetura orientada a serviços Existem diferentes definições para o conceito de serviço e de arquitetura. (MARZULLO, 2009) e outros estudiosos definem o conceito de serviços como uma informação necessária ao negócio, no entanto, essa informação será um serviço somente se for mapeada em atividades. Uma definição mais precisa para o conceito de serviços é sugerida pelo IEEE que define serviço como sendo um relacionamento entre um provedor e um consumidor. O primeiro se compromete a realizar determinadas tarefas e o segundo a utilizar determinados serviços. Dessa forma, um serviço de TI é uma representação de uma atividade de negócio que pode ser mapeada por meio de uma entrada, um processamento e uma saída, ou seja, representa detalhes das tarefas necessárias para executar uma determinada atividade dentro de um processo existente na organização. Em contrapartida, uma arquitetura é a estrutura do sistema composto pelos elementos de software, correspondendo às propriedades visíveis desses elementos assim como o seu relacionamento. A partir de uma breve definição de serviços e de arquitetura é possível definir SOA como uma abordagem para a utilização dos recursos de TI que tem como finalidade apoiar o negócio da organização. Dentro dessa abordagem podem-se identificar os seguintes benefícios: separação das responsabilidades, organização lógica, facilidade de uso, integração de aplicações e flexibilidade (MARZULLO, 2009). Baseia-se na idéia principal de que um sistema de informação é um conjunto de serviços facilmente acessíveis que podem ser ligadas de forma dinâmica, com a finalidade de fornecer a informação desejada melhorando a eficiência da empresa. Esses serviços podem ser utilizados nos processos mais complexos com a finalidade de realizar os objetivos estratégicos da empresa, sendo assim, são compostos por elementos que representam papéis distintos de interação: o consumidor, o prestador e a central de serviço, denominada serviço de identificação (LIN et al., 2010). 25

27 Além dos serviços que possuem um dos objetivos da SOA é proporcionar um ambiente que alinha esses serviços com as metas da empresa. Por meio da modelagem dos processos é possível identificar os principais processos organizacionais e dependendo da sua complexidade é possível desmembrá-los em subprocessos de negócios até o nível em que as atividades são mapeadas. Atualmente, um dos conceitos que vem sendo difundido é o uso do BPM (Business Process Management, no original em inglês, ou Gerenciamento de Processos de Negócios) e SOA, pois têm sido defendidas como iniciativas evolutivas que permitem que as organizações se tornem mais ágeis, através da flexibilidade. Essas são, porém, iniciativas distintas. A primeira está relacionada à gestão e estratégia organizacional. A segunda é uma abordagem de arquitetura para o desenvolvimento de sistemas (ENGELS et al., 2008). Os seguintes aspectos devem ser considerados para adoção de SOA: (STAL, 2006) 1. Interface e contrato que descrevem os serviços e contratos oferecidos ao cliente; 2. Padrão de comunicação para permitir a integração entre provedores e consumidores de serviço; 3. Localização; 4. Definição de uma infraestrutura para ativar os serviços. De acordo com o modelo de referência para Arquitetura Orientada a Serviços OASIS (MACKENZIE et al., 2006) os principais conceitos do paradigma SOA são: 1. Visibilidade: Ocorre através da descrição do serviço onde contém as informações necessárias para interagir com o serviço. A descrição do serviço comunica o que está sendo consumado quando o serviço é invocado e as condições para usar o serviço. 2. Interação: Pode ser viabilizada por meio de troca de mensagens que ocorre através de uma série de ações de troca de informações e invocações. 3. Efeito: Caracterizado como o retorno de uma informação ou a mudança no estado de entidade que estão envolvidas numa interação. A descrição do serviço representa uma das qualidades da SOA, facilitando a interação e a visibilidade, particularmente quando os participantes estão em domínios proprietários diferentes. Desta forma, o benefício da SOA está relacionada à facilidade no gerenciamento do crescimento dos sistemas corporativos de larga escala reduzindo os custos nas organizações. Devido a esse crescimento e a diversidade de sistemas diferentes padrões tecnológicos se destacam ao se tratar da SOA. Consequentemente, a integração desses padrões nos apresenta um conceito vital: o barramento de serviços (Enterprise Service Bus do original em inglês, ou Barramento de Serviços). 26

28 Uma solução ESB fornece uma variedade de benefícios, pois simplifica a tarefa de conectar a diversidade de sistemas diferentes e melhora a agilidade do negócio fornecendo integração de aplicativos. Sendo assim, facilita a comunicação entre aplicações construídas em ambientes de desenvolvimento heterogêneos. (MARECHAUX, 2006). Este possui nove características básicas. Descritas brevemente a seguir: 1. Invocação: É a capacidade de um ESB para enviar pedidos e receber respostas de serviços de integração. 2. Roteamento: Tem como finalidade fornecer o destino de uma mensagem durante o seu transporte. 3. Mediação: Refere-se a todas as transformações ou traduções entre recursos como protocolo de transporte, o formato da mensagem e o seu conteúdo. 4. Adaptadores: Conectam as interfaces de transação e estrutura de dados e apresentam uma interface padrão. 5. Segurança: Está relacionada à autenticação e controle de acesso através da criptografia e a capacidade de decifrar o conteúdo das mensagens. 6. Gestão: Fornece a capacidade de registro da infraestrutura e controle da execução do processo. 7. Processamento de orquestração: Inclui um mecanismo para executar processos de negócios descritos com serviços web utilizando BPEL, controlando a descrição do processo, em seguida, coordena a colaboração dos serviços ligados ao barramento. 8. Processamento de eventos complexos: Um ESB pode incluir mecanismos de interpretação, correlação e correspondência do evento. 9. Ferramentas de integração: Para o desenvolvimento de ESB ferramentas de implantação e testes devem estar disponíveis. Devido aos benefícios e a competitividade muitas empresas têm adotado o uso de SOA utilizando ESB, conforme mostra uma pesquisa realizada pelo Wintergreen com relação ao ESB em escala mundial, sendo representada pela figura 1. 27

29 Figura 1: Mercado comparativo de ESB a nível mundial. Fonte: (WINTERGREEN). Ao analisarmos a figura 1 nota-se que de 2006 até 2013 há um crescimento significativo do ESB no mercado corporativo. Para exemplificar, no ano de 2007 o mercado mundial de ESB obteve 203,8 milhões de dólares e estima-se 494,4 milhões de dólares em A próxima seção trata de descrever esta tecnologia, além de detalhes técnicos relevantes para a execução deste trabalho de pesquisa WEB SERVICES (MARZULLO, 2009) define um web services como um serviço que é disponibilizado via Internet. Representa uma lógica de negócio em que um ou mais clientes enviam requisições e recebem suas respostas. Desta forma, a capacidade de criar soluções distribuídas e descentralizadas fornece à possibilidade de manter equipes de trabalho em locais diferentes e operando simultaneamente. Na literatura são apresentadas diversas definições de web services, no entanto, para este trabalho vamos utilizar a definição utilizada pelo W3C (World Wide Web Consortium) que consiste de: Sistema de software que deve ser projetado para apoiar as interações máquina a máquina em uma rede; A interface deve ser descrita em WSDL (Web Service Description Language do original em inglês, ou Linguagem para Descrever o Serviço Web). Outros sistemas interagem com um determinado serviço utilizando mensagens SOAP. As mensagens são trocadas através do protocolo HTTP (Hypertext Transfer Protocol do original em inglês, ou Protocolo de Transferência de Hipertexto), com XML (Extensible 28

30 Markup Language, no original em inglês, ou Linguagem de Marcação), em conjunto com outras tecnologias essenciais. De uma forma mais simples, um web service é um serviço disponibilizado na Internet, que utiliza WSDL, UDDI (Universal Description, Discovery and Integration do original em inglês, ou Integração e Descoberta da Descrição Universal), SOAP (Simple Object Access Protocol, no original em inglês, ou Protocolo Simples de Acesso a Objetos) e XML o relacionamento entre esses principais padrões ocorre da seguinte forma: O primeiro está relacionado com a descrição dos serviços sendo registrado utilizando UDDI, em seguida utiliza SOAP para troca de mensagens entre as aplicações e finalmente os dados são transmitidos via XML. Os padrões básicos empregados no âmbito da tecnologia web são descritos brevemente nas próximas seções: Protocolo HTTP, XML, SOAP, WSDL, e UDDI; PROTOCOLO HTTP O protocolo padrão utilizado para transmissão de dados pela internet oferece uma infraestrutura de comunição simples, permitindo uma ascensão rápida da tecnologia do web service XML A linguagem de marcação utilizada para armazenamento e transporte de dados. A W3C define uma especificação rigorosa, onde são definidas as regras de criação de documentos XML. A aceitação desse modelo está diretamente relacionada à sua flexibilidade, pois permite a sua aprovação a um conjunto de ferramentas de desenvolvimento que suportam e manipulam os documentos em XML (W3C-SCHOOL). A seguir algumas características da XML conforme a W3C: XML é uma linguagem de marcação parecida com a HTML. XML tem como finalidade projetar os dados e não para exibi-los. XML é uma recomendação da W3C. As principais diferenças entre XML e HTML são: XML não é uma substituição para HTML; XML e HTML foram projetados com objetivos diferentes; 29

31 XML está focada no que é o dado. Em contrapartida, HTML foi projetada para exibir os dados, ou seja, como estes dados aparecem. XML foi criado para estruturar, armazenar e transportar a informação SOAP SOAP é um protocolo baseado em XML para troca de mensagens. Em vez de definir um novo protocolo de transporte, SOAP trabalha com HTTP, SMTP (Simple Mail Transfer Protocol do original em inglês ou Protocolo de Transferência de Correio Simples) e MQSERIES. De acordo com o W3C SOAP fornece uma forma de comunicação entre diferentes aplicações com diferentes tecnologias e linguagens de programação. A mensagem SOAP contém os seguintes elementos: Um elemento envelope que identifica o documento XML como uma mensagem SOAP. Um elemento de cabeçalho. Um elemento corpo que contém informações referentes à chamada e resposta. Um elemento fault contendo os erros e informações de status. A seguir um exemplo desta estrutura representada pela figura 2: <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle=" Message information goes here <soap:header></soap:header> <soap:body> <m:getprice xmlns:m=" <m:item>apples</m:item></m:getprice> <soap:fault></soap:fault> </soap:body> </soap:envelope> Figura 2: Sintaxe mensagem SOAP Fonte: (W3C SCHOOL). O elemento envelope define o documento XML como uma mensagem SOAP. Além da estrutura da mensagem, SOAP define um modelo que visa como os destinatários devem processar as mensagens. A seguir uma breve descrição dos principais elementos desconsiderando os elementos opcionais abordados no SOAP. A figura 2 mencionada anteriormente exemplifica como seria uma resposta da requisição. Em contrapartida, a figura 3 ilustra como seria a resposta SOAP: 30

32 <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:body> <m:getpriceresponse xmlns:m=" <m:price>1.90</m:price> </m:getpriceresponse> </soap:body></soap:envelope> Figura 3: Elemento corpo resposta Fonte: (W3C SCHOOL) WSDL A WSDL tem como finalidade obter a descrição de um web services, ou seja, define o formato da mensagem, tipos de dados, protocolos de transporte que devem ser utilizados entre o solicitante e o provedor. A figura 4 mostra documentos WSDL representando aplicações web services. Figura 4: Documentos WSDL Fonte: (W3C SCHOOL) Ao analisar a figura 4 nota-se que a camada de integração introduzida pela estrutura de web service estabelece um padrão, universalmente reconhecido, permitindo a comunicação entre essas camadas. Web Services Description Language: descreve a interface de web services. Universal Description, Discovery and Integration: define a maneira de publicar e descobrir informações relacionadas aos web services. O relacionamento entre protocolos e linguagens pode ser representado pelo esquema a seguir exemplificado na figura 5. 31

33 Figura 5: Esquema representando os passos da utilização de um web services. Fonte: (RIBEIRO, 2008) Todo o processo pode ser descrito em seis passos: 1. Procura: o usuário realiza uma busca num site UDDI com a finalidade de satisfazer as suas necessidades. 2. Descrição: o site retorna um ficheiro WSDL com a descrição de cada serviço. remoto. 3. Criação de Proxy: Em seguida um Proxy é criado para a realização do serviço 4. Criar uma mensagem SOAP: A mensagem SOAP é criada e enviada para a URL especificada no ficheiro WSDL. 5. Recepção: O receptor SOAP recebe o pedido, trata-o, interpreta-o e envia-o para o web service. cliente. 6. Função: Uma função é executada e posteriormente é entregue o resultado ao O ciclo de vida de um web service compreende quatro estados. Descritos brevemente a seguir: 1. Publicação: Neste processo o fornecedor do web service conhece a existência do seu serviço, efetuando o registro do mesmo no repositório; 2. Descoberta: Por meio do qual uma aplicação do cliente conhece a existência de um web service pesquisando um repositório UDDI; 3. Descrição: Inclui a linguagem padrão de mensagens SOAP; 32

34 4. Mensagens: Inclui o protocolo padrão de mensagem e extensões para o protocolo SOAP (RIBEIRO, 2008). A interação entre o web service acontece por meio de protocolos abertos. Os protocolos utilizados são: UDDI, WSDL, XML, SOAP e HTTP, conforme a figura 6: Figura 6: Protocolos utilizados Fonte: (RIBEIRO, 2008) O protocolo SOAP permite a interoperabilidade entre as diferentes plataformas. No entanto, primeiramente as características são explicitadas por meio do WSDL e finalmente o UDDI é utilizado para armazenamento em repositórios disponíveis na Internet. Descrito na próxima seção UDDI De acordo com Andrade (2002) o padrão UDDI trata-se de um repositório universal de registros que contém todas as informações necessárias sobre as empresas que fornecem serviços. Além disso, define a maneira de publicar e descobrir informações que estejam relacionadas à web service. A UDDI utiliza uma base de registros por meio de um formato XML. Essa base contem três componentes. Descritos a seguir: serviço; 1. Páginas brancas: contêm identificadores relacionados a um provedor de 2. Páginas amarelas: incluem categorização com base em negócios e serviços; (categorias com base em um padrão). 3. Páginas verdes: contêm informações específicas relacionadas aos serviços (ANDRADE, 2002). 33

35 Esta seção apresentou os principais conceitos e elementos primordiais na arquitetura orientada a serviços. Devido a sua flexibilidade e agilidade a SOA é capaz de responder rapidamente as mudanças de acordo com a necessidade do negócio realizando um alinhamento entre negócios e TI. 34

36 2.2. SOFTWARE COMO SERVIÇO Por décadas as organizações utilizavam seu software em sua própria infraestrutura, sendo responsáveis por todas as atividades a serem executadas. Com a evolução tecnológica este cenário mudou estando relacionado com a ocorrência do aumento do fluxo de informação, demandas cada vez maiores por inovações e ganho de competitividade e uma visão estratégica de alinhamento entre TI e negócio (WU et al., 2012). Neste novo cenário, está desenvolvendo muito rapidamente um modelo emergente de comercialização de software, conhecido como SaaS (Software as a Service do original em inglês ou Software como Serviço). Esse novo modelo, visa separar a propriedade do usuário e a propriedade do fornecedor. Dessa forma, os clientes que adquirem esse novo modelo usufruem de uma nova via de acesso a seu negócio e diversos benefícios como: flexibilidade, redução de tempo, menores custos com licenças de software, redução de custos com hardware, alta disponibilidade, segurança, manutenção, dados associados com o serviço é mantido com o serviço. (WU et al., 2012). Conforme apontado anteriormente SaaS proporciona diversos benefícios e devido a estes benefícios as empresas estão recorrendo ao uso de SaaS, pois o cliente não precisa adquirir hardware, licenças e outros requisitos, diminuindo o orçamento de uma implantação. Com todas essas vantagens um estudo realizado pelo Gartner estima que o modelo de software como serviço movimente 14,5 bilhões de dólares em todo o mundo, um crescimento de 17,9% em comparação com o ano passado. Na América do Norte a receita de software está prevista para totalizar US$ 9,1 bilhões em 2012, acima dos US$ 7,8 bilhões em 2011, apresentando a maior implantação de SaaS em gestão de despesas, finanças, e suítes de escritório. Na Europa Ocidental, a receita SaaS está prevista para ultrapassar US$ 3,2 bilhões em 2012, acima dos US$ 2,7 bilhões em 2011, totalizando US$ 169,4 acima dos US$ 135,5 milhões do ano passado. Com relação à Ásia estima-se US$ 934,1 em 2012 acima dos US$ 730,9 em No geral, a adoção de SaaS na Ásia está fragmentada, pois é uma combinação de mercados maduros, como a Austrália, Nova Zelândia, Hong Kong, Cingapura, Coréia do Sul e Taiwan e os mercados emergentes, incluindo a China, Índia, Malásia, Tailândia, Indonésia, Vietnã e Filipinas, onde as aplicações voltadas para SaaS financeiro são as mais populares, especialmente na China e na Índia. O segundo maior uso de SaaS é para funções ERP (do 35

37 original em inglês Enterprise Resource Planning ou Planejamento de Recursos Empresariais), tais como gestão de despesas e gestão do desempenho do colaborador. Apesar da sua disseminação e dos diversos benefícios mencionados anteriormente as empresas necessitam de prudência ao optarem pelo uso de SaaS, pois há necessidade de um processo dentro da empresa, principalmente quando há necessidade de integração com outros aplicativos e sistemas legados. Analisando os dados obtidos observa-se a relevância do uso de SaaS e ressalta-se a importância do entendimento do negócio, desta forma faz-se necessário o uso de BPM para coordenar, compactar e entregar as ofertas de negócios assim como BPMN para a modelagem dos processos (KAPURUGE, 2011). Como conclusão deste subcapítulo o modelo SaaS apresenta uma excelente solução para as empresas de TI que desejam obter um maior controle sobre seus custos e, consequentemente sobre os lucros possibilitando níveis mais eficientes de controle, principalmente com relação à forma de negociação do uso dos serviços e como as licenças são distribuídas. 36

38 2.3. PROCESSO DE REFERÊNCIA DE NEGÓCIO A decomposição do domínio é considerada o principal ponto de partida para uma solução orientada a serviços. O domínio pode ser organizado em um processo de negócio (HUHNS et al., 2005). Kellner (1999) enfatiza que um processo é um conjunto de passos ordenados sendo composto por atividades, ferramentas, métodos que definem o relacionamento entre as tarefas e práticas que transformam entradas, ou matérias prima, em produtos. Esta definição é exemplificada na figura 7. Figura 7: Dimensões crítica do processo. Fonte: (adaptado de SEI- Software Engineering Institute, 2003). A figura 7 mostra que os processos representam conjuntos de atividades relacionadas com pessoas, treinamento e motivação, ferramentas, equipamentos, procedimentos e métodos que definem o relacionamento das tarefas esses estão interligados para que o objetivo final seja alcançado. Um processo está diretamente relacionado a um conjunto de atividades, que indicam o seu início e o seu fim fornecendo informações sobre as atividades, os stakeholders, as tecnologias e os dados que estão vinculados, isto permite identificar os componentes que estão relacionados aos processos, recursos utilizados e políticas internas e externas. Dentro desse contexto, processo de referência consiste no mapeamento detalhado das informações com relação a um determinado padrão auxiliando na identificação dos gargalos e proporcionando melhorias nos processos informais adotados (BASS et al., 2003). 37

39 A modelagem do processo de negócio está sendo aceita em grande escala com o objetivo de identificar as falhas, atividades duplicadas ou desnecessárias, pessoa sem capacitação e, além disso, facilita no desenvolvimento sendo uma ferramenta gerencial e de comunicação que ajuda a melhorar os processos existentes, ou a implantação de uma nova estrutura, auxiliando a empresa a identificar claramente os pontos fortes e os pontos fracos (SARA. R; SAVÉN. A, 2003). Neste trabalho, processo é considerado o principal elemento na engenharia de requisitos estando agregada a qualidade do processo e do produto, a estrutura organizacional incluindo pessoas, recursos, tecnologias, procedimentos e os produtos resultantes desses processos. Outro conceito que está diretamente relacionado a processos é BPMN. Segundo o BPMI (Process Management Institute) BPMN fornece às empresas a capacidade de compreender os seus procedimentos internos de negócios em uma notação compreensível por todos os stakeholders. Um dos objetivos da BPMN é criar um mecanismo para o desenvolvimento dos modelos dos processos com o intuito de obter um maior entendimento. Para manter a notação padrão foi realizado um acordo entre os fornecedores da ferramenta para utilizarem a mesma notação, sendo apoiada por muitas das maiores empresas de software do mundo, como IBM, Microsoft, Oracle e Sybase. Existem diversas ferramentas disponíveis no mercado para notação de processos de negócios, entre elas podemos destacar: TIBCO, BizAgi Xpress e ACTIVITI são as mais utilizadas para modelagem de processos essas ferramentas possuem o BPMS (Business Process Modeling Suite) que consiste de um pacote de software que serve para automatizar os processos e as atividades em BPMN. A principal diferença entre uma ferramenta e a outra está relacionada à simulação, desempenho, avaliação e análise dos processos. Entre as diversas ferramentas mencionadas anteriormente a ferramenta BizAgi Xpress e JBPM foram escolhidas para a concepção do processo de referência proposta neste trabalho. Desta forma, a descrição dos elementos nesta dissertação foi embasada em uma pesquisa bibliográfica, sobretudo a partir de obras de White (2010) e Reis (2011), no entanto, buscou-se obter maior ênfase na norma oficial da notação da OMG (2011). Na BPMN dividiram-se os elementos em: 1. objetos de fluxos, 2. objetos de conexão, 3. swimlanes e 4. artefatos. Descritos brevemente a seguir: 38

40 1. Objetos de fluxos: Definem o comportamento do processo de negócio. A tabela 2 apresenta os principais eventos. Elemento Descrição Notação Atividade Ações que devem ser realizadas em um processo. Evento Gateway Ocorrem durante o fluxo do processo. Podendo ser: (1) start, (2) intermediate e (3) end. O primeiro está relacionado ao início do fluxo no processo. O segundo ocorre durante o fluxo e o terceiro finaliza um fluxo. Controla a convergência e divergência do fluxo. Tabela 2: Fluxos principais Fonte: (OMG) Objetos de conexão: Conectam objetos de fluxos. Estes são divididos em: 1. fluxo de sequência, 2. fluxo de mensagem e 3. associação. Conforme ilustra a tabela 3. Elemento Descrição Notação Fluxo de sequência Fluxo de mensagem Associação È utilizado para mostrar a ordem (sequência) que as atividades serão realizadas em um processo. Exibi o fluxo de mensagem entre dois ou mais participantes do processo separado. Tem como finalidade associar texto e outros artefatos Tabela 3: Objetos de conexão Fonte: (OMG) 3. Swimlanes: São entidades que tem como finalidade agrupar elementos pools e lanes, permitindo particionar um diagrama BPMN de acordo com seus responsáveis. Sendo assim, permite informar onde serão executadas. A tabela 4 apresenta a notação dos pools e lanes assim como uma breve descrição. Elemento Descrição Notação Pool Lanes Representa um participante e suas atividades no processo. È uma subpartição dentro de um pool, sendo utilizada para separar participantes dentro de uma mesma organização. Tabela 4: Pools e Lanes Fonte: (OMG) 39

41 4. Artefatos: Os artefatos são utilizados para fornecer informações adicionais sobre o processo. Esses são divididos em três grupos: 1.dados, 2. grupo e 3.anotação. Exemplificados a seguir na tabela 5: Elemento Descrição Notação Dados Mecanismo que visa mostrar como os dados são necessários ou produzidos pelas atividades. Grupo Anotação È utilizado para fins de documentação ou de análise, mas não afeta o fluxo de sequência. Mecanismo que visa proporcionar informação adicional para o texto. Tabela 5: Elementos dos artefatos Fonte: (OMG) Os processos em BPMN facilitam o entendimento e a comunicação entre os stakeholders. Assim os três subprocessos existentes na BPMN são apresentados a seguir: 1. Processo interno: Este é o tipo de processo mais comum, composto por uma série de atividades que são realizadas unicamente dentro de uma empresa. 2. Processo abstrato: O processo inclui atividades que são realizadas fora da empresa, ou seja, não há uma gerência sobre a execução destas atividades. 3. Processo de colaboração: Descrevem processos e as interações entre duas ou mais entidades de negócios. Uma das vantagens com relação à BPMN é o desenvolvimento de sistemas baseados em serviços, pois fornece uma notação gráfica para modelagem de coreografia (descreve as interações entre duas ou mais entidades empresariais), sendo assim, torna-se fundamental o uso de BPEL para o desenvolvimento de web services. Segundo (RIBEIRO, 2008) há dois tipos de combinação possível para web service, à orquestração e a coreografia. A primeira é mais utilizada em processos de negócios privados, onde há um processo central, normalmente um web service que controla e coordena todas as operações, ou seja, somente o web service central controla todas as operações e a ordem de invocação dos web services envolvidos. Por outro lado, na coreografia não há necessidade de um web service central, pois todos os web services sabem quais são os web services que devem interagir e quando deve executar as suas operações. 40

42 Para um maior entendimento a tabela 6 apresenta as atividades básicas e as atividades estruturadas da BPEL assim como uma pequena descrição de cada atividade. Atividade Descrição Atividade Descrição Básica Estruturada <invoke> Chama um serviço externo. <if> Executa uma atividade com base uma ou mais condições. <receive> Recebe entrada de serviços. <while> Executa uma atividade repetidamente <reply> Envia respostas de serviços <repeatuntil> Executa repetidamente até que a sua condição seja verdadeira. <throw> Lida com falhas durante o processo de execução do processo, sinalizando as que ocorrem no seu scope. <pick> Contém ao menos uma mensagem. Quando esta atividade é executada bloqueia o processo até que a mensagem seja recebida. <wait> Pausa o fluxo do processo de negócio durante um determinado período. <flow> Executa as atividades dentro do seu scope em paralelo. <empty> Sincroniza atividades concorrentes. <sequence> Define atividades que serão invocadas. <exit> Termina um processo <scope> Contexto para um conjunto de atividades. Tabela 6: Resumo das atividades BPEL. Fonte: (RIBEIRO, 2008) Além de proporcionar a automatização dos processos, BPEL pode ser utilizado de duas maneiras: dentro da corporação (intranet) e entre as corporações (internet). A primeira está relacionada com a padronização e integração das aplicações corporativas. A segunda visa à integração fácil e eficiente entre os parceiros. Como conclusão deste subcapítulo nota-se a importância do entendimento do negócio por meio do mapeamento e modelagem dos processos, pois este permite identificar de uma forma detalhada todas as atividades relacionadas a um processo auxiliando na engenharia de requisitos. Além disso, foi apresentado um conceito fundamental que está interligado ao uso da BPMN que é BPEL proporcionando uma automatização dos processos facilitando o desenvolvimento dos sistemas baseados em web services. 41

43 2.4. ENGENHARIA DE REQUISITOS Um requisito é uma característica do sistema ou a descrição do que o sistema é capaz de realizar, com a finalidade de atingir o seu objetivo, sendo assim, é fundamental para o bom desenvolvimento de software (PRESSMAN, 2011). A engenharia de requisitos distingue de uma forma clara e precisa requisitos de usuários e requisitos de sistema podendo ser definidos da seguinte maneira: 1. Requisitos de usuários: são declarações em uma linguagem natural com diagramas, de quais serviços são esperados e sob quais restrições deve operar. 2. Requisitos de sistema: Definem detalhadamente, as funções, os serviços e as restrições operacionais (BOURQUE, 2004). Além dos requisitos mencionados anteriormente há os requisitos funcionais e não funcionais descritos a seguir: Requisitos funcionais: Estão diretamente relacionados à funcionalidade do software, ou seja, descrevem as funções que o software deve realizar. Requisitos não funcionais: Consiste nas qualidades específicas que o software deve ter. Essas qualidades estão de acordo com a norma ISO 9126 que está relacionada à qualidade do produto de software que propõe atributos de qualidade distribuídos em categoria A partir de uma breve definição de requisitos é possível definir engenharia de requisitos como uma abordagem inserida no contexto de engenharia de software onde as atividades estão diretamente relacionadas à produção de uma descrição minuciosa de um software a ser construído. No entanto, entender precisamente os requisitos de software e as necessidades dos clientes tem sido um dos principais desafios na área de engenharia de software. A engenharia de requisitos auxilia os engenheiros de software a lidar com os diversos tipos de problema relacionados aos requisitos (PRESSMAN, 2011). A engenharia de requisitos consiste de sete etapas distintas: 1. Concepção, 2. Levantamento, 3. Elaboração, 4. Negociação, 5. Especificação, 6. Validação e 7. Gestão. Descritas brevemente a seguir: 1. Concepção: Consiste na definição do escopo e da natureza do problema. 2. Levantamento: Consiste em reuniões com os principais stakeholders com o objetivo de identificar quais são os principais objetivos do sistema e como este se encaixa nas necessidades do negócio. 42

44 O levantamento de requisitos parece uma tarefa fácil, porém é uma tarefa difícil, pois diversos problemas podem ocorrer durante o levantamento, entre eles, destacam-se: Problemas de escopo: Este tipo de problema ocorre quando o limite do sistema não foi informado corretamente ou quando o cliente/usuário fornece detalhes técnicos supérfluos. Problemas de entendimento: Ocorre quando o cliente/usuário não tem certeza da sua necessidade, omite informações que parecem ser "óbvias" e/ou não tem o conhecimento necessário sobre o domínio do problema. Problemas de volatilidade: Os engenheiros mudam ao longo do tempo. 3. Elaboração: As informações obtidas nas etapas realizadas anteriormente são expandidas e refinadas na etapa de elaboração que está focada nas características e restrições do software. 4. Negociação: Conflitos de requisitos podem ocorrer durante todas as etapas sendo assim, engenheiros de requisitos devem elaborar um documento de negociação que tem como finalidade minimizar os conflitos entre os stakeholders. 5. Especificação: A especificação de requisitos pode ser considerada como uma das principais etapas para a realização deste trabalho. No entanto, apesar da sua importância o principal objetivo dessa dissertação é fornecer mecanismos para a elaboração do documento de requisitos. Dessa forma, uma especificação pode ser um documento escrito, um modelo gráfico ou qualquer combinação desses elementos que permite identificar as restrições e desempenho que governarão o desenvolvimento. Existem dois tipos de padrões propostos pela IEEE somente para especificação de requisitos. São eles: IEEE STD Recommended Practices for Software Requirements Specification (Práticas Recomendada para a Especificação de Requisitos de Software). As práticas recomendadas têm a finalidade de descrever os caminhos para a especificação de requisitos. IEEE Guide for the Development os Systems Requirements Specifications (Guia para o Desenvolvimento de Especificações de Requisitos de Sistema). Este guia provê orientações para a identificação de requisitos assim como a maneira de organizá-los. 6. Validação: Esta etapa tem como finalidade verificar se os requisitos identificados nas etapas anteriores foram declarados de modo não ambíguo, pois os erros em 43

45 um documento de requisitos podem levar a custos excessivos de retrabalho quando estes são descobertos na etapa de desenvolvimento (SOMMERVILLE, 2011). 7. Gestão de requisitos: Devido à mudança de requisitos que ocorrem durante o projeto há necessidade de gerenciar essas mudanças. A gestão de requisitos proporciona a identificação, controle e modificação dos requisitos. Como conclusão desse subcapítulo pode-se notar que a engenharia de requisitos contém atividades que estão diretamente relacionadas com o entendimento e a produção de um documento de requisitos. 44

46 2.5. MODELO DE REQUISITO Este capítulo apresenta um modelo de engenharia de requisitos estabelecido pela ISO/IEC. Este modelo foi escolhido pelo fato de ser mais completo para o escopo deste trabalho INTERNATIONAL STANDARD ISO/IEC/IEEE 29148:2011 SYSTEMS AND SOFTWARE ENGINEERING LIFE CYCLE PROCESSES REQUIREMENTS ENGINEERING Este padrão tem como objetivo apresentar processos e produtos relacionados à engenharia de requisitos apresentando todo o seu ciclo de vida. No entanto, para atingir o objetivo deste trabalho será apresentado somente o documento de requisitos. Esse consiste dos seguintes elementos: 1. Propósito: Apresenta o objetivo do software a ser especificado. 2. Escopo: Define o que o produto deve fazer e descreve a aplicação do software. 3. Funções do produto: Fornece um resumo das funções do software. 4. Características de usuário: Descreve as características dos usuários do produto. 5. Limitações: Fornece uma descrição do que pode limitar o fornecedor. 6. Hipótese e dependência: São os fatores que podem afetar os requisitos no documento de requisitos. 7. Requisitos específicos: Deve conter todos os requisitos de software devidamente detalhados para que possa permitir o desenvolvimento de software. 8. Interfaces externas: Deve conter todas as entradas e saídas para o sistema de software. 9. Requisitos de usabilidade: Define a qualidade de uso dos requisitos. 10. Requisitos de desempenho: Deve conter exigências numéricas do software. 11. Requisito de banco de dados lógico: São os requisitos lógicos para que posteriormente estes possam ser colocados numa base de dados. 12. Restrições: Deve conter restrições sobre o projeto do sistema. 13. Padrões de conformidade: Deve conter os requisitos derivados de normas. 14. Atributos do sistema de software: Contem os atributos necessários do produto de software. 15. Verificação: Contem as abordagens de verificação com o objetivo de qualificar o software. 16. Informações: O documento de requisitos deve fornecer informações adicionais. 45

47 3. TRABALHOS RELACIONADOS Neste capítulo serão abordados trabalhos que estejam relacionados ao presente trabalho. Tais como: (Vieira et., 2012; Dias et.al, 2006; Xavier et. al, 2010; Dijkman, 2002; Liew, 2004; Rodriguez, 2011 e Okama, 2007) EXTRAÇÃO DE REQUISITOS DE SOFTWARE Como apresentado anteriormente os requisitos de software podem ser funcionais ou não funcionais. Dessa forma, a abordagem proposta por (Vieira et al., 2012) utiliza a técnica REMO (Requirements Elicitations oriented by business Process Modeling) para identificar requisitos e regras de negócios. Essa técnica faz uso de heurísticas para extrair requisitos funcionais, não funcionais e regras de negócios identificando primeiramente os elementos da BPMN para posteriormente aplicar à heurística e obter os requisitos. Outra abordagem proposta por (Dias et al., 2006) apresenta uma técnica para facilitar na especificação de requisitos. Para atingir esse objetivo apresenta uma ferramenta que permite a transformação do modelo de negócios em modelo de requisitos. Tal abordagem é composta por duas etapas: a primeira faz uso de heurística em um processo de aluguel de carros. Esse processo é representado através do diagrama de atividades. Na segunda etapa o processo é transformado automaticamente em um diagrama de caso de uso. Para isso o autor propôs o desenvolvimento de uma ferramenta denominada RAPDIS. Em (Xavier et al., 2010) é proposto uma extensão para BPMN utilizando RNF. Nessa nova abordagem denominada BPMNFR utiliza-se catálogos de requisitos de um framework. Tal método consiste de quatro etapas: 1. modelagem do processo de negócio, 2. inserção de rótulos nas atividades, 3. criação de catálogos de RNF e 4- inserir as operacionalizações no modelo. Na primeira etapa é realizada a modelagem dos processos de negócio. A segunda etapa consiste na identificação dos RNF de acordo com o domínio e relacioná-los de acordo com cada atividade com seus rótulos. Posteriormente, há necessidade de relacionar os RNF com as operacionalizações para isso utiliza-se o NFR framework. 46

48 3.2. ESPECIFICAÇÃO DE CASO DE USO O trabalho proposto por Dijkman (2002) é um dos primeiros a tratar da transformação da BPMN para caso de uso. Nesse trabalho são apresentados novos conceitos como papel e passo. O primeiro está relacionado ao ator de uma determinada atividade. Em contrapartida, o segundo refere-se ao conjunto de atividades que são realizadas. O mapeamento dos processos é realizado no diagrama de atividades. Dessa forma, são considerados os seguintes elementos da BPMN: 1. Connection (sequence flow), 2. Gateway (exclusive), 3. Intermediate events, 4. Start event e end event, 5. Tasks. Descritos brevemente a seguir: Connection Na BPMN há diversos tipos de elementos para caracterizar um connection. No entanto, no trabalho apresentado será analisado o sequence flow que identifica o fluxo de sequência entre as atividades. Em contrapartida, no diagrama de caso de uso o fluxo de mensagem é representado pela associação entre atores e casos de uso Gateway A exclusive gateway representa "sim" ou "não" dada uma determinada condição. No entanto, em diagrama de caso de uso o extend representa um comportamento opcional de um caso de uso. Dessa forma, é possível realizar uma relação entre a BPMN e o diagrama de caso de uso Intermediate events São eventos temporais esses podem ocorrer anexados a uma atividade ou no fluxo do processo. A primeira indica que algo pode ocorrer no decorrer da execução de uma determinada atividade. A segunda indica que são precedidos por outro elemento da BPMN Start event e End event Em BPMN um evento de início indica onde inicia o processo. Esses podem ser acionados por diversas causas Tasks Há diversos tipos de elementos na BPMN que caracterizam as atividades. Para exemplificar há atividades que podem ser executadas por um usuário, atividades sistêmicas e manuais, sendo assim, há necessidade de identificar o tipo de atividade que será executada. 47

49 O método apresentado acima apresenta uma relação entre a BPMN e o diagrama de caso de uso, no entanto, apesar da sua relevância limita-se pelo fato de não representar todas as atividades da BPMN que devem ser transformadas em caso de uso. Com base no método proposto acima nesta dissertação será apresentada um método para transformar BPMN em diagrama de caso de uso. A transformação da BPMN para diagrama de caso de uso ocorrerá da seguinte maneira: Cada participante encontrado na BPMN será transformado em ator no diagrama de caso de uso. Em contrapartida, cada atividade sistêmica encontrada na BPMN será transformada em caso de uso. Liew (2004) propõe uma transformação de modelos BPMN para diagrama de casos de uso. Esse trabalho é uma extensão do trabalho proposto por Dijkman, com a diferença que a modelagem no trabalho de Dijkman é realizada utilizando diagrama de atividades. Nesta etapa será exemplificado o diagrama de caso de uso através do subprocesso emissão de poluentes, pois no estudo de caso proposto há necessidade de mais de um participante. A tabela 7 exemplifica o método proposto para elaboração do diagrama de caso de uso do subprocesso emissão de poluentes. Elemento BPMN Lane Atividade Evento de Fim Artefatos Elemento UML Para cada lane identificada no processo substituir por um ator. As atividades devem ser substituídas por um caso de uso. Para cada evento de fim. Deve-se substituir por uma atividade. Os artefatos que servem de entrada para uma determinada atividade devem ser transformados em pré-condições na descrição do caso de uso. Em contrapartida, os artefatos que servem de saída devem ser transformados em pós- condições na descrição do caso de uso. Tabela 7: Transformação da BPMN para diagrama de caso de uso Fonte: (adaptado de Liew, 2004) Um exemplo da transformação da BPMN para diagrama de caso de uso pode ser representado nas figuras 8 e 9 a seguir: 48

50 Figura 8: Subprocesso emissão de poluentes Fonte: (Leal, 2014) Figura 9: Caso de uso emissão de poluentes Fonte: (adaptado de Liew, et al., 2004) ESPECIFICAÇÃO DE ATIVIDADE No trabalho apresentado por Rodriguez (2011) parte de um modelo inicial em BPMN que posteriormente é modelado em diagrama de atividades que dá origem ao diagrama de classes e ao diagrama de caso de uso da UML. A transformação realizada entre uma BPMN e um diagrama de atividades ocorre da seguinte forma: cada participante modelado em um pool ou lane é transformado em uma partição de atividades. As tarefas são representadas por uma ação. O fluxo de mensagem corresponde ao fluxo de objeto e os objetos de dados e os eventos iniciais e finais são representados por datastores, nodo de início e nodo final respectivamente. 49

51 3.4. ESPECIFICAÇÃO DE CLASSES Em OKAMA (2007) é proposto um método para realizar a transformação de BPM para diagrama de classes. Com o objetivo de verificar o método proposto foi realizado um estudo de caso de uma reserva de autocarros e um sistema de gestão. O método proposto pelo autor é divido em quatro etapas. Na primeira etapa é realizada a modelagem inicial dos processos de negócios conhecida como As is. Na próxima etapa, é realizada a melhoria desses processos conhecida como To be. Posteriormente, é realizada a simulação de cada processo com o objetivo de verificar as melhorias e possíveis correções. Finalmente, é feita a transformação de cada processo em diagrama de classes. Essa transformação está dividida em quatro etapas. Descritas brevemente a seguir: 1. Cada processo de negócio é associado a uma única classe. 2. Os dados obtidos devem ser tratados como atributos do diagrama de classes. 3. Os elementos devem ser tratados como métodos da classe. 4. Verificar os elementos que são comuns às classes TRABALHOS RELACIONADOS Os trabalhos apontados anteriormente utilizam os seguintes diagramas: caso de uso, atividades e classes o seu uso justifica-se pelo fato de serem os diagramas que mais se aproximam para obter os requisitos. No entanto, apesar da sua proximidade os dois primeiros trabalhos proposto com Vieira et al., (2012) e Dias et al., (2006) faz uso de heurísticas para identificação de requisitos e regras de negócios. O primeiro trabalho utiliza a BPMN em contrapartida o segundo trabalho utiliza o diagrama de atividades. Apesar da sua importância estes trabalhos não apresentam detalhes com relação a elementos mais complexos da BPMN. Além disso, seria interessante expandir o uso da ferramenta para outros padrões. O trabalho proposto por Liew (2004) utiliza BPMN para diagrama de caso de uso, no entanto, apesar da sua importância é um trabalho limitado, pois faz uso de apenas um participante no processo. Além disso, o evento de fim da BPMN não é caracterizado no diagrama de caso de uso. Os trabalhos mencionados foram citados nesta dissertação pelo fato de se aproximarem da extração de requisitos, no entanto, a melhoria proposta neste trabalho é o uso da BPMN para modelagem de processos sendo que a partir dela é possível extrair os requisitos funcionais, não funcionais, regras de negócios. Além disso, é possível verificar até 50

52 que ponto a BPMN auxilia na engenharia de requisitos com relação à especificação de requisitos. O capítulo a seguir apresenta o método proposto. 51

53 4. PROPOSTA PARA APLICAÇÃO DE PROCESSOS NA ENGENHARIA DE REQUISITOS EM SOA A fim de oferecer uma alternativa mais consistente para a engenharia de requisitos em SOA este trabalho propõe uma solução baseada na aplicação de processos de negócios. O método faz uma análise dos elementos da BPMN e posteriormente uma comparação com cada elemento encontrado na ISO/IEC/IEEE 29148:2011 para a especificação de requisitos. A escolha da BPMN e BPM justifica-se pelo fato de entender precisamente o domínio do problema, minimizando assim, os erros encontrados na etapa de desenvolvimento, pois está atrelada a TI, ou seja, permite um melhor alinhamento entre a equipe de negócio e a TI, pois pode minimizar as falhas encontradas no desenvolvimento. Dessa forma, esta dissertação atua em duas frentes: utilizar BPMN para proporcionar o alinhamento entre negócio e TI e analisar até que ponto a BPMN auxilia na especificação de requisitos. Para experimentar o método proposto foi realizado um estudo de caso denominado design sustentável extraído do trabalho de Santana, 2012, no entanto, a modelagem dos processos As is foi adaptado para que pudesse atender o método proposto utilizando a BPMN. As etapas apresentadas a seguir foram desenvolvidas após estudos de diversas referências bibliográficas encontradas na literatura: 1. Entender o domínio do problema, 2. Entender a estrutura proposta 3. Realizar a modelagem dos processos de negócios As is, 4. Estratégia organizacional, 5. Realizar a modelagem dos processos de negócios To be, 6. Identificação dos requisitos e 7. Especificação. A figura 10 exemplifica esse processo. 52

54 Figura 10: Método proposto 53

55 1. Entender o domínio do problema: O primeiro passo fundamental para a modelagem dos processos de negócios é entender o domínio do problema, ou seja, quais são as reais necessidades. Dessa forma, é possível ter um maior entendimento de quais processos de negócios são de fato importantes para atingir objetivos estratégicos. 2. Entender estrutura organizacional: Consiste no entendimento da estrutura organizacional através do organograma onde é possível verificar os principais papéis da organização. Além disso, permite identificar os principais stakeholders para que posteriormente possa ser elaborada a modelagem dos processos de negócios. No entanto, apesar da sua relevância dificilmente uma estrutura organizacional é documentada. Dessa forma, torna-se importante a realização da modelagem dos processos de negócios para que possam permitir o entendimento da estrutura organizacional, assim como os principais stakeholders. O trabalho proposto nesta dissertação faz uso de um estudo de caso, sendo assim, para realizar esta etapa foram necessárias pesquisas que pudessem propor uma estrutura dentro do escopo deste trabalho. 3. A modelagem dos processos de negócios As is: Essa é iniciada através do As is (está relacionado com o funcionamento atual da organização) e o To be (realizado após a modelagem do As is com o intuito de propor melhorias ao processo). 4. Validar a modelagem: Após a etapa de modelagem As is é realizada a validação dos processos que foram modelados juntamente com os principais stakeholders. 5. Verificar a estratégia: A estratégia tem como finalidade verificar os principais objetivos e determinar políticas, normas, regras de negócios, para atingir os objetivos. 6. A modelagem dos processos de negócios To be: Esta etapa visa redesenhar o processo obtido na etapa As is, porém é realizada uma análise com o objetivo de acrescentar melhorias ao processo modelado. Nesta etapa são identificadas pessoas sem capacitação. Além disso, atividades duplicadas e/ou desnecessárias são excluídas. 7. Validar modelagem To be: Após a etapa de modelagem To be é realizada a validação dos processos que foram modelados juntamente com os principais stakeholders. 8. Extração de requisitos funcionais e não funcionais: O método para extração de requisitos funcionais e não funcionais propostas neste trabalho faz uso da técnica REMO para extração de requisitos. O primeiro passo consiste na identificação dos elementos da BPMN. Posteriormente, é feita a aplicação das instruções de cada heurística. 9. Verificar a especificação: Nesta etapa é realizada a comparação da BPMN com a ISO/IEC/IEEE 29148:

56 10. Realizar implementação: Consiste em implementar os processos de negócios To be. A tabela 8 a seguir apresenta os principais elementos da BPMN assim como as suas heurísticas. Tabela 8: Principais elementos da BPMN e suas heurísticas Fonte: (adaptado de VIEIRA, 2012) 55

57 5. APLICAÇÃO DO MÉTODO Para avaliar e experimentar o método proposto será apresentado um estudo de caso denominado design sustentável. A principal motivação para a escolha do estudo de caso abordando design sustentável justifica-se pelas alterações climáticas o que tem levado ao estabelecimento de restrições legais e comerciais para o desenvolvimento de produtos e serviços com a finalidade de aumentar a sustentabilidade. O SD é uma atividade bastante complexa, pois um dos seus principais desafios é utilizar conceitos PSS (Product Service Systems) e LCA (Life Cycle Assessment) para avaliar o impacto causado por um produto sobre o meio ambiente. Dessa forma, torna-se viável o uso de ferramentas de software que possam fornecer apoio na análise e avaliação de aspectos quantitativos, no entanto, será necessário recurso de integração e interoperabilidade com outros sistemas (MANZINI, 2003). Dessa forma, torna-se viável o uso da SOA que tem como ponto de partida a definição de um processo de referência com o objetivo de fornecer um entendimento claro das tarefas que devem ser executadas. O processo de referência design sustentável faz uso do LCA, ou seja, tem como finalidade analisar, medir e propor melhorias com o intuito de eliminar ou reduzir os impactos ambientais sem comprometer as necessidades das gerações futuras. Além disso, a LCA tem como objetivo verificar o ciclo de vida de um determinado produto desde a fase de extração, aquisição, produção, distribuição e descarte. O estudo de caso proposto neste trabalho consiste de sete etapas: 1. Entender o domínio do problema: Esta etapa foi realizada através de pesquisas que evidenciam a importância do design sustentável. 2. Entender a estrutura organizacional: A estrutura organizacional proposta foi realizada através do entendimento do domínio do problema e com base em pesquisas referente ao assunto, sendo assim, foi possível identificar os principais participantes do processo. A figura 11 apresenta a estrutura proposta e a figura 12 apresenta a estrutura proposta utilizando a ferramenta BizAgi Xpress. 56

58 Figura 11: Estrutura proposta Fonte: (Leal, 2014) manual. A figura 11 apresenta a estrutura proposta. Tal estrutura foi realizada de forma seguir: Figura 12: Estrutura proposta BizAgi Xpress. Fonte: (Leal, 2014) Dessa forma, foi possível identificar oito participantes. Descritos brevemente a 1. Pesquisador 1: Neste trabalho o participante denominado pesquisador 1 realiza uma pesquisa e análise do mercado com o objetivo de verificar as principais necessidades. 2. Pesquisador 2: È responsável por planejar e executar a pesquisa de mercado realizada pelo pesquisador Engenheiro de produção: O engenheiro de produção define a melhor forma de integrar mão de obra, equipamentos e matéria prima, com o objetivo de fornecer melhor qualidade e aumentar a produtividade. 4. Ecologista: È responsável por pesquisar e estudar a diminuição dos efeitos da ação do homem contribuindo significativamente para a compreensão e preservação da biodiversidade, conduz pesquisas, aplica o conhecimento obtido para solucionar problemas ambientais. 57

59 5. Engenheiro ambiental: Responsável por desenvolver tecnologias para proteger o ambiente dos danos causados pelas atividades humanas. Além disso, tem como função preservar a qualidade da água, do ar e do solo. 6. Gerente de logística: Responsável pelo armazenamento, compras, distribuição e entrega de produtos. Além disso, determina o tipo de transporte a ser utilizado (ferroviário, rodoviário e aeroviário) assim como o cálculo do frete a embalagem que será utilizada. 7. Analista de TI: Responsável por desenvolver as funcionalidades necessárias. 8. Gerente de TI: Responsável por gerenciar as funcionalidades estabelecidas. Após esta etapa, foi realizada a modelagem do As is e a modelagem To be AS IS Conforme mencionado anteriormente, o As is corresponde à modelagem atual dos processos,ou seja, como estes estão estruturados atualmente. Dessa forma, por meio da modelagem é possível identificar os principais gargalos, atividades duplicadas, pessoal sem capacitação. Uma das formas de obtê-lo é por meio de entrevistas com a pessoa responsável pelo processo, no entanto, torna-se desaconselhável, por considerar a visão de uma única pessoa. A técnica mais utilizada é realizar uma reunião com todos os stakeholders para realizar o mapeamento e documentar o processo. Neste trabalho a modelagem inicial, ou seja, o As is foi retirado do trabalho de (SANTANA, 2012), no entanto, mesmo representando o As is houve melhorias nesta etapa. O orquestrador é considerado o processo principal. Este consiste de cinco subprocessos e sete atividades. Descritas brevemente a seguir: 1. Demanda de mercado: Informações de mercado com relação ao nível de necessidade do público alvo quanto a este produto/serviço; 2. Subprocesso serviços: Informações relevantes da matéria prima (referente à sua extração, origem e transporte) para a produção. No entanto, caso não haja a presença de matéria prima nociva ou não renovável buscar a substituição; 3. Subprocesso Produtos: Informações relevantes da matéria prima (referente à sua extração, origem e transporte) para a produção. No entanto, caso não haja a presença de matéria prima nociva ou não renovável buscar a substituição; 4. Supply Chain Management: Visa realizar um planejamento do gerenciamento da cadeia de abastecimento com o objetivo de regular os gastos da matéria prima para uma quantidade mínima necessária; 58

60 5. Subprocesso simplificação do ciclo de vida: Com base nas informações adquiridas com relação ao consumo de matéria prima deve-se determinar uma avaliação simplificada do impacto gerado pela produção; 6. Produção: Aperfeiçoar a produção e diminuir/eliminar os gastos e os desperdícios; 7. Distribuição: Avaliar se o transporte do produto ou serviço é realmente necessário até chegar ao consumidor; 8. Consumo: Eliminar/reduzir a produção do lixo gerado com as embalagens assim como o seu gasto; 9. Subprocesso reduzir/eliminar: Após a utilização do produto/serviço há necessidade de determinar uma destinação final, ou seja, avaliação de reparo para reutilização, ou se podem ser descartados com ou sem tratamento; 10. Avaliação do ciclo de vida: Avaliação do impacto ambiental; 11. Enviar mensagem: Consiste na verificação da destinação escolhida e caso seja insatisfatória a mensagem será enviada para mudar o tipo de destinação. A figura 13 exemplifica este processo. 59

61 Figura 13: Macro processo Fonte: (adaptado de SANTANA, 2012). 60

62 Os subprocessos serviço e produtos têm como finalidade realizar a extração do etanol. Esses subprocessos são formados pelas seguintes atividades: 1. Matéria prima: Consiste na identificação da matéria prima; 2. Origem da matéria prima: Essa atividade consiste no estudo da cana de açúcar produzida no Estado de São Paulo; 3. Substituição de materiais perigosos: Consiste na análise dos materiais e caso haja necessidade o material é substituído. O material ácido sulfúrico e ciclo-hexano acabaram por ser mantidos; 4. Redução de materiais não renováveis: Nessa atividade os materiais reduzidos foram: o diesel, substituído pelo bagaço de cana para fornecer energia à usina, fertilizantes, substituídos pelo uso da torta de filtro; 5. Redução de matéria prima: O estudo baseia-se em 1 hectare de cana de açúcar, produção média de 86,7 ton. Neste caso, não ocorrerá à redução da quantidade de matéria prima a ser utilizada; 6. Transporte de materiais: È realizado de acordo com a distância a ser entregue o produto; O subprocesso simplificação do ciclo de vida consiste na estimativa do ciclo de vida do Etanol de forma simplificada. Esse subprocesso é composto por quatro atividades. Descritas brevemente a seguir: 1. Produção: Consiste na avaliação do método tradicional da produção de cana de açúcar quando comparado com o método para reduzir o impacto ambiental; 2. Distribuição: Consiste na estimativa do custo de distribuição do Etanol onde tem a sua distribuição entre o transporte rodoviário, náutico e ferroviário; 3. Uso: O Etanol apresenta grande aplicação como combustível automotivo sendo utilizado em larga escala para o abastecimento de veículos automotores; 4. Destino: O Etanol apresenta como destino final a atmosfera, porém, após sofrer a combustão está reação converte o Etanol em dióxido de carbono. Os subprocessos mencionados anteriormente estão exemplificados nas figuras 14 e 15 a seguir: 61

63 Figura 14: Subprocesso de serviço Fonte: (adaptado de SANTANA, 2012). Figura 15: Subprocesso avaliação do ciclo de vida Fonte: (adaptado de SANTANA, 2012) 62

64 Neste caso, para o produto em questão, o Etanol, não será possível o reparo assim como a recuperação dos seus componentes, sendo assim, é enviado para o descarte, pois conforme mencionado anteriormente, após o consumo do Etanol esse é convertido em CO 2 sendo liberado na atmosfera. A figura 16 exemplifica esse processo. Figura 16: Subprocesso reduz/elimina resíduos Fonte: (adaptado de SANTANA, 2012). O subprocesso avaliação do ciclo de vida tem como finalidade avaliar o impacto ambiental de todo o ciclo deste produto, ou seja, desde a concepção até o seu destino final. Esse subprocesso é formado por seis subprocessos e sete atividades. Descritas brevemente a seguir: 1. Obter de matéria prima: Conforme mencionado anteriormente à matéria prima utilizada na obtenção do Etanol é a cana de açúcar; 2. Subprocesso tipo de recurso: O tipo de recurso utilizado é renovável; 3. Subprocesso emissão de poluentes: Este subprocesso tem como finalidade controlar as emissões de poluentes, oriundas do processo de obtenção de matéria prima, tornando-as aceitáveis (baixa); 4. Transporte: Durante o transporte da cana de açúcar, contida em hectare, estima-se uma emissão de 14,31 ton de CO 2 para a atmosfera; 5. Subprocesso impacto de produção: Este subprocesso avalia o impacto associado à produção do produto, neste caso, o Etanol, por meio da avaliação de gastos energéticos tendo como objetivo otimizar o processo; 63

65 6. Realiza distribuição: Corresponde à distribuição pelo transporte do álcool até os postos revendedores. 7. Subprocesso avaliação da distribuição: Avalia as atividades que englobam a distribuição do Etanol. 8. Insumos: Consiste em verificar a combinação de fatores de produção. 9. Subprocesso utilização: Este subprocesso tem como finalidade avaliar se a utilização do Etanol está sendo utilizado de maneira eficaz no veículo. 10. Subprocesso disposição de resíduos: Conforme mencionado anteriormente o produto Etanol acaba por se perder na atmosfera quando transformado em CO 2, sendo assim, não pode ser reaproveitado, consertado ou reciclado, portanto, neste caso, este resíduo deve ser descartado. A figura 17 exemplifica o subprocesso mencionado. 64

66 Figura 17: Ciclo de vida Fonte: (adaptado de SANTANA, 2012). 65

67 O subprocesso tipo de recurso tem como finalidade verificar se o recurso utilizado pode ser renovável, neste caso, é renovável, sendo assim, a atividade recurso renovável é configurada como fluxo de mensagem padrão. Conforme exemplifica a figura 18: Figura 18: Subprocesso tipo de recurso Fonte: (adaptado de SANTANA, 2012). Com relação ao subprocesso emissão de poluentes este tem como finalidade controlar as emissões de poluentes, oriundas do processo de produção da matéria prima, tornando-as baixas. Esse subprocesso é formado por sete atividades. Descritas brevemente a seguir: 1. Verifica emissão de poluentes: Esta atividade tem como finalidade definir a classificação da emissão de poluentes. 2. Baixa: Está relacionada com a taxa de emissão do CO (monóxido de carbono), HC (Hidrocarbonetos) e NOx (Óxidos de nitrogênio). 3. Média: Está relacionada com a taxa de emissão do CO, HC e NOx. 4. Alta: Está relacionada com a taxa de emissão do CO, HC e NOx. 5. Otimiza processo: Esta atividade é executada caso a quantidade de emissão de poluentes seja considerada como média ou alta, realizando uma melhoria no processo com o intuito de minimizar a porcentagem de emissão de poluentes. 6. Substitui matéria prima: Substituição da matéria prima por uma menos poluente. 7. Manter matéria prima: Consiste em deixar a matéria prima já existente. A figura 19 ilustra este processo: 66

68 Figura 19: Subprocesso emissão de poluentes Fonte (adaptado de SANTANA, 2012). 67

69 O subprocesso impacto de produção avalia à produção do produto, neste caso, o Etanol, por meio da avaliação de gastos. Este subprocesso é formado por seis atividades. Descritas brevemente a seguir: 1. Verifica gastos energéticos: O gasto pode ser definido como regular, pois a energia elétrica consumida na produção do Etanol é obtida por meio da cana de açúcar, sendo assim, não há necessidade de compra de energia externa. 2. Verifica desgaste de equipamento: Esta atividade tem como finalidade verificar o desgaste dos equipamentos. Para este caso, a vida útil do equipamento dura 25 anos. 3. Otimiza combustíveis: Verifica a relação custo benefício dos produtos ou serviços. 4. Verifica emissão de poluentes: Verifica a taxa de emissão de poluentes. 5. Otimiza modernização: Verifica a relação custo benefício dos produtos ou serviços. 6. Realiza tratamento: Esta atividade tem como objetivo diminuir o impacto negativo com relação aos gastos energéticos, desgastes de equipamentos entre outros. A figura 20 exemplifica este processo. Figura 20: Subprocesso impacto de produção Fonte: (adaptado de SANTANA, 2012). O subprocesso avaliação da distribuição tem como finalidade avaliar as atividades que englobam a distribuição do Etanol. Este subprocesso é formado por doze atividades. Descritas a seguir: 68

70 1. Verifica risco atribuído: Tem como finalidade verificar o risco atribuído. Neste caso, o produto a ser distribuído apresenta característica inflamável, sendo assim, o risco atribuído é alto; 2. Transporte especializado: Dada a periculosidade da carga, a mesma necessita de transporte especializado para não correr risco de vazamentos de carga; 3. Transporte comum: Após a verificação do risco atribuído, a carga pode ser transportada utilizando um transporte comum. 4. Verifica meio de distribuição: Verifica a distribuição da distância. Neste caso, uma distância de distribuição adequada seria a de 340 km sendo considerada como perto; 5. Náutico, aéreo, ferroviário: Corresponde ao tipo de distribuição; 6. Ferroviário, rodoviário: Corresponde ao tipo de distribuição; 7. Perda de produto: Consiste em verificar se houve alguma perda do produto. 8. Emissão de poluentes: Esta atividade tem como finalidade verificar a distribuição da emissão de poluentes; 9. Verifica custo benefício: Esta atividade realiza uma avaliação do custo beneficio com relação ao tipo de distribuição; 10. Modernização da frota: Corresponde a modernização na frota distribuidora; 11. Substitui meio da distribuição: Apesar da alta de emissão de poluentes e não modernização da frota a mesma ainda é mantida; 12. Terceiriza distribuição: Tem como objetivo verificar a possibilidade de terceirizar a distribuição do produto. A figura 21 representa o processo mencionado anteriormente. 69

71 Figura 21: Subprocesso avaliação da distribuição Fonte: (adaptado de SANTANA, 2012). 70

72 No subprocesso de utilização o uso do Etanol dependerá muito do funcionamento adequado do veículo, uma vez que o dado apresentado no item "consumo" 1, 97 kg de CO 2 por litro de etanol hidratado, sendo assim somente é considerado correto se aplicado em um automóvel em perfeito funcionamento. 1. Checar funcionamento: Verifica se o funcionamento do veículo está adequado. 2. Realizar manutenção preventiva: Esta atividade é realizada com o objetivo de reduzir ou impedir falhas no desempenho de equipamentos. 3. Realizar manutenção corretiva: Esta atividade é realizada com o objetivo de restabelecer o pleno funcionamento do equipamento. 4. Verificar gastos emissão: Liberação de gases por um motor. 5. Verificar resíduos: Realiza uma análise para verificar se o resíduo é regular ou se este necessita de tratamento. 6. Realizar tratamento: Os gases tóxicos monóxido de carbono (CO), monóxido de nitrogênio (NOx) e partículas de hidrocarboneto (HC), passam por uma espécie de tratamento graças ao uso dos catalisadores automotivos que convertem esses gases tóxicos em nitrogênio molecular (N 2 ), vapor de água e (H2O) e dióxido de carbono (CO2). Conforme ilustra a figura 22. Figura 22: Subprocesso utilização Fonte: (adaptado de SANTANA, 2012). Com relação ao subprocesso disposição de resíduos infelizmente, como o produto (Etanol) acaba por se perder na atmosfera, quando convertido em CO 2, uma vez utilizado o mesmo não pode ser reaproveitado, consertado ou reciclado, portanto, para este caso este resíduo é diretamente descartado. Conforme ilustra a figura

73 Figura 23: Subprocesso disposição de resíduo Fonte: (adaptado de SANTANA, 2012). 72

74 ESTRATÉGIA A estratégia deve ser bem definida e alinhada com os objetivos. Dessa forma, após iniciar a modelagem As is é preciso analisar criticamente as possíveis mudanças a serem realizadas, ou seja, se tais mudanças irão gerar valor para o negócio e contribuir para alcançar as metas e apenas após esta etapa é possível propor melhorias que consiste na remodelagem dos processos. Esses processos modelados devem auxiliar as organizações a realizar o plano tático e o plano estratégico. Para esta etapa foi definido como meta automatizar o processo design sustentável com o objetivo de auxiliar nas atividades a serem desenvolvidas proporcionando um melhor acompanhamento destas atividades durante a concepção de um produto TO BE Analisando o processo As is foi possível verificar que neste processo não há participantes para executarem as atividades mapeadas foi verificado também a ocorrência de atividades duplicadas e/ou desnecessárias. Além disso, não é possível verificar se a atividade a ser executada é manual, sistêmica ou se será realizada por um usuário. Dessa forma, foi proposta a modelagem To be que corresponde as possíveis melhorias que podem ser realizadas após a modelagem do funcionamento atual da empresa, ou seja, o As is. No processo de referência utilizado, estas melhorias estão relacionadas a atividades duplicadas, atividades desnecessárias e identificação de participantes. A seguir serão apresentados os processos To be. No processo principal denominado orquestrador, ou macro processo pode-se notar que os subprocessos serviços e produtos foram mapeados em um único subprocesso, pois ambos os subprocessos possuem as mesmas atividades. As atividades: realiza produção, realiza distribuição e consumo apresentado no As is foram eliminadas no To be pelo fato de pertencerem ao subprocesso avaliação simplificada. A figura 24 apresenta a melhoria proposta. 73

75 Figura 24: Macro processo to be 74

76 No subprocesso produto foram acrescentados dois departamentos: Logística e Engenharia de produção assim como os seus dois principais participantes: Engenheiro de produção e gerente de logística. Além disso, foi incluído o artefato informação do território nacional que consiste dos dados sobre a produção de açúcar e a produção do etanol. A figura 25 exemplifica este processo. Figura 25: Subprocesso produto to be Fonte: (Leal, 2014) No subprocesso avaliação simplificada foram incluídos dois departamentos: 1. Engenharia de produção e 2. Logística. Além disso, foi incluído um artefato denominado estimativa de custo de distribuição que consiste de uma planilha em Excel que contém todas as estimativas de custo de distribuição. A figura 26 exemplifica este processo. Figura 26: Avaliação simplificada to be Fonte: (Leal, 2014) 75

77 No subprocesso reduz/elimina resíduos a melhoria proposta foi o acréscimo do subprocesso avaliação simplificada, tendo em vista que as atividades retorna distribuição e retorna produção proposta no As is fazem parte do subprocesso avaliação simplificada. A figura 27 apresenta este processo. Figura 27: Reduzir/eliminar resíduos to be Fonte: (Leal, 2014) No subprocesso avaliação do ciclo de vida foram incluídos três departamentos: 1. Engenharia ambiental, 2. Engenharia de produção e 3. TI. A figura 28 ilustra este processo. Figura 28: Subprocesso avaliação do ciclo de vida to be Fonte: (Leal, 2014) 76

78 A melhoria proposta no subprocesso tipo de recurso consiste na inclusão de dois departamentos: engenharia ambiental e engenharia de produção. Ressalta-se que todas as atividades neste processo são realizadas pelo usuário. A figura 29 exemplifica esse processo. Figura 29: Subprocesso tipo de recurso to be Fonte: (Leal, 2014) No subprocesso emissão de poluentes foi incluído dois departamentos: engenharia de produção e engenharia ambiental assim como os seus participantes. Outra melhoria realizada no subprocesso é a inclusão do artefato denominado análise. Este é adquirido após a execução da atividade "analisa emissão de poluentes". Conforme demonstra a figura 30. Figura 30: Subprocesso emissão de poluentes to be Fonte: (Leal, 2014) 77

79 A melhoria proposta no subprocesso impacto de produção foi à inclusão de dois departamentos: engenharia de produção e engenharia ambiental. A figura 31 ilustra este processo. 78

80 Figura 31: Subprocesso impacto de produção to be Fonte: (Leal, 2014) 79

81 O subprocesso avaliação da distribuição teve como principal melhoria a eliminação de atividades desnecessárias e a inclusão de departamentos. Além disso, foi possível identificar uma atividade sistêmica e um artefato denominado análise. A figura 32 ilustra a melhoria proposta. Figura 32: Avaliação da distribuição to be Fonte: (Leal, 2014) No subprocesso utilização a melhoria proposta foi à inclusão dos três departamentos. Conforme mostra a figura 33. Figura 33: Subprocesso utilização to be Fonte: (Leal, 2014) A melhoria proposta no subprocesso disposição/resíduos é a eliminação de atividades duplicadas. Além disso, foram incluídos os departamentos. Conforme ilustra a figura

82 Figura 34: Subprocesso disposição/resíduos to be Fonte: (Leal, 2014) 81

83 EXTRAÇÃO DE REQUISITOS Essa etapa consiste na identificação dos principais requisitos funcionais, não funcionais e regras de negócios extraídos do estudo de caso proposto. A extração de requisitos proposta neste trabalho faz uso do trabalho de (VIEIRA, 2011). Dessa forma, é possível identificar os requisitos funcionais, não funcionais e regras de negócios: A seguir um exemplo que ilustra o método proposto representado pela figura 35. Figura 35: Subprocesso produto Fonte: (Leal, 2014) RF 01: O sistema deve fornecer dados relacionados ao território nacional. RF 02: O sistema deve permitir o cadastro, alteração e exclusão de dados. RNF 01: O sistema deve ser de fácil acessibilidade. RN 01: Deve-se sempre optar pela melhor distância, ou seja, a distância mais econômica. Neste caso, o sistema deve considerar uma distância de 340 km como perto ESPECIFICAÇÃO Esta etapa tem como objetivo propor um método para auxiliar na elaboração do documento de especificação de requisitos com o intuito de analisar até que ponto a BPMN está aderente à norma ISO/IEC/IEEE 29148:2011, que trata da engenharia de requisitos. 1. Propósito: De acordo com (CASTRO, 2010) há uma correspondência entre os objetivos e os elementos da BPMN. No modelo proposto pelo autor o objetivo é alcançado através de metas e submetas utilizando operadores lógicos. 82

84 2. Escopo: A notação BPMN auxilia na definição do escopo do projeto. Segundo (GARCIA et al., 2011) é possível desmembrar cada atividade e verificar quais recursos são necessários para realizá-la. Além disso, torna-se possível relacionar cada atividade com os seus principais stakeholders determinando o prazo para a execução de cada atividade. 3. Funções do produto: Conforme demonstrado no subcapitulo 3.1 com a BPMN é possível extrair os requisitos funcionais e não funcionais e posteriormente é possível realizar diagramas da UML, como por exemplo, diagramas de caso de uso, diagrama de atividades, diagrama de classes. Dessa forma, é possível ter uma visão sistêmica e identificar suas possíveis funções. 4. Característica de usuário: Não foi encontrado indícios na literatura que a BPMN auxilia na descrição das características do usuário. No entanto, pode-se afirmar por meio do trabalho realizado nesta dissertação que através de técnicas de levantamento que auxiliam na modelagem dos processos é possível identificar os principais participantes do processo. Dessa forma, obtém as características relevantes de cada usuário. 5. Limitações: Não foi encontrado na literatura indícios de que a BPMN possa auxiliar na identificação de possíveis limitações. No entanto, pode- se afirmar por meio do trabalho realizado nesta dissertação que é possível identificar fatores que podem limitar possíveis melhorias no mapeamento como por exemplo regras de negócios. 6. Hipótese e dependência: Não foi encontrado na literatura indícios de que a BPMN possa auxiliar na identificação de hipóteses e dependência. 7. Requisitos: Diversas pesquisas apontam a identificação dos requisitos funcionais por meio da BPMN e, posteriormente, faz uso do diagrama de caso de uso (TANUSKA, 2011) (NAWROCKI et al., 2006). 8. Interfaces: A BPMN fornece o uso de interface, pois na modelagem de processos de negócios é possível identificar claramente as atividades de serviço. Dessa forma, é possível executar um web services dentro do processo (OHNISHI et al., 2007) 9. Requisitos de usabilidade: Não foi encontrado na literatura trabalhos que estejam relacionados com o uso da BPMN que possa auxiliar nos requisitos de usabilidade. No entanto, o trabalho proposto por (DEMIRORS, 2005) faz uso das seguintes categorias de qualidade: funcionalidade, confiabilidade e manutenabilidade. Além disso, o trabalho apresenta as subcategorias: métricas, operabilidade das métricas, métricas de atratividade, entre outras propostas na ISO O objetivo é utilizar a ISO 9126 para medir a qualidade dos processos de negócios. 83

85 10. Requisitos de desempenho: Os requisitos de qualidade são importantes, pois tem como objetivo fornecer a garantia para o desempenho do serviço, assim como garantir a satisfação do cliente. No entanto, apesar da sua importância capturar requisitos não funcionais utilizando a BPMN torna-se algo trivial e complexo. Dessa forma, propôs capturar os requisitos de custo, tempo e confiabilidade utilizando BPMN. Para adquirir os requisitos mencionados anteriormente é considerado o tempo máximo de transferência de dados, tempo necessário para completar um determinado pedido, número de solicitações atendidas (SAEEDI, 2010). 11. Restrições: A BPMN por meio da regra de negócio fornece mecanismo para identificar possíveis restrições, operações e definições que podem impactar o projeto. 12. Padrões de conformidade: O método proposto por (SCHLEICHER, 2010) faz uso da BPMN para identificar padrões de conformidade. Este método consiste na identificação dos papéis que devem estar envolvimentos no ambiente. No estudo de caso proposto pelo autor foi possível identificar: Proprietário do processo (responsável pela criação e modificação dos processos), Process Designer (responsável pela verificação do escopo juntamente com regras de conformidade), Especialista em conformidade (possui o conhecimento necessário para aplicar normas de conformidade que deve ser aplicada no processo). 13. Atributos do sistema de software: Não foi encontrado na literatura indícios de que a BPMN possa auxiliar na identificação de atributos do sistema de software (atividade sistêmica), no entanto, por meio do trabalho proposto pode-se afirmar que é possível identificá-los por meio de levantamento de requisitos e mapeamento de processos. 14. Verificação: Não foi encontrado na literatura trabalhos que estejam relacionados com o uso da BPMN que possa auxiliar na verificação, no entanto, pode-se afirmar que o uso da BPM garante a qualidade dos processos estando atrelada com a qualidade do software. 15. Informações: A BPMN contém um elemento denominado anotação que permite fornecer informações adicionais. 16. Definições, siglas e abreviaturas: Embora seja considerada uma informação adicional no documento de especificação a BPMN não auxilia na identificação de definições, siglas e abreviaturas. Além dos itens encontrados no documento de requisitos apresentado anteriormente as definições, siglas e abreviaturas podem fazer parte do documento de requisitos, no entanto, a BPMN não tem mecanismo que possa auxiliar na sua identificação. Em contrapartida, a 84

86 criação de protótipos pode ser considerada como uma informação adicional que agrega valor no documento de requisitos. No trabalho realizado por (DONALDSON, 2005) o autor utiliza diagrama de atividades para realizar o protótipo de telas, no entanto, é possível estender o método proposto para BPMN, pois conforme demonstrado no subcapítulo 4.2 o diagrama de atividades pode ser transformado em BPMN. Desta forma, a BPMN auxilia na prototipação de telas que serve como modelo para uma apresentação de como será o sistema assim como as principais funcionalidades. Um exemplo prático extraído do subprocesso "produto" está relacionado à atividade "realiza transporte". Nesta atividade o sistema teria como uma das telas a figura 36. Figura 36: Tela para verificar transporte Fonte: (Leal, 2014) IMPLEMENTAÇÃO DOS PROCESSOS BizAgi Xpress Esta etapa apresenta a implementação do processo design sustentável. Inicialmente foi realizada uma pesquisa sobre as principais ferramentas de mapeamento e modelagem de processos, sendo elas: BizAgi Xpress, Tibco, Bonita, Activiti e Aris. Após uma análise detalhada de cada ferramenta foi possível escolher a ferramenta BizAgi Xpress e JBPM sendo uma proprietária e a outra open source o uso das duas ferramentas justifica-se pelo fato de apresentar a diferença entre as ferramentas e para demonstrar que apesar das diferenças ambas possuem as mesmas funcionalidades, no entanto, uma com baixo grau de complexidade e a outra com um alto grau de complexidade. 85

87 A identificação dos serviços é considerada o primeiro passo para o desenvolvimento da arquitetura orientada a serviços, dessa forma, torna-se fundamental ter o processo de negócio como ponto de partida (INAGANTI, 2007). Após a identificação dos principais processos de negócios há necessidade de identificar as funcionalidades oferecidas pelos aplicativos e expor como serviço. A terceira etapa consiste em relacionar os serviços às atividades existentes. Para realizar a implementação dos processos e dos serviços foi necessário seguir as sete etapas disponibilizadas pela ferramenta, sendo estas: 1. a modelagem dos processos, 2. model data, ou seja, modelar as possíveis entidades que podem descrever o negócio, 3. criar formulário para as atividades, 4. definir as possíveis regras de negócios e as ações de cada atividade e caminhos alternativos, 5. definir participantes para cada atividade do processo, 6. verificar as possíveis interfaces e 7. realizar o deployment dos processos de acordo com o ambiente, podendo ser: ambiente de desenvolvimento, ambiente de teste e ambiente de produção. A figura 37 exemplifica o modelo de dados extraído do processo de referência. Figura 37: Modelo de dados do negócio Fonte: (Leal, 2014) 86

88 Analisando a figura 37 contém três tipos de entidades: 1. entidade master (caracterizada com a cor azul) corresponde a atividades que estão ligadas ao negócio do processo que está sendo automatizado, 2.entidade do tipo system (caracterizado com a cor cinza): entidade do metamodelo do BizAgi Xpress que pode ser relacionada com o modelo do negócio. Neste caso, indica que a entidade design sustentável está associada a um usuário que a solicita e o usuário está na tabela WFuser e 3. entidade do tipo parâmetro: representam campos que pode ter mais de uma opção, permitindo realizar inclusão, alteração e exclusão lógica dos valores da entidade. A próxima etapa tem como finalidade criar formulário para as atividades do processo. As figuras 38 e 39 exemplificam esta etapa. Figura 38: Atividades habilitadas para criação de formulários Fonte: (Leal, 2014) Ao analisar a figura 38 nota-se que apenas com atividades de usuário é possível criar um formulário. Dessa forma, a atividade do tipo serviço não está habilitada. A figura 39 ilustra a criação do formulário. Este é extraído com base nos campos que foram criados na tabela. 87

89 Figura 39: Criação do formulário Fonte: (Leal, 2014) A próxima etapa consiste na definição das possíveis regras de negócio que podem impactar o processo. Para esta etapa inicialmente há necessidade de definir as expressões que determinam os caminhos alternativos no processo, ou seja, os gateways. A figura 40 exemplifica esta etapa. Figura 40: Definição de expressões/condições Fonte: (Leal, 2014) Posteriormente há necessidade de definir os participantes que irão executar cada atividade. Para atingir o objetivo proposto foram definidas posições organizacionais de acordo com a estrutura ilustrada na figura 11. A etapa seis tem como finalidade realizar a configuração das atividades que foram definidas como atividades sistêmicas. No estudo de caso proposto foi definido que a atividade 88

90 "origem matéria prima" necessita de informação referente ao território nacional que para este estudo de caso foi utilizado o estado de São Paulo. O objetivo principal desta etapa é criar um web services que possa acessar um banco de dados e retornar os seus valores, sendo assim, primeiramente foi definido um banco de dados com as informações necessárias. A ferramenta da Microsoft SQL Server Management Studio Express 2008 foi utilizada para a criação do banco de dados. Dessa forma, foi criado um banco de dados denominado "dados produção". Além disso, foram criadas sete tabelas: 1. dados produção, 2. exportação anual açúcar origem, 3. exportação anual de etanol por local de embarque, 4. exportação anual etanol, 5. exportação açúcar origem, 6. exportação anual açúcar local de embarque; e 7. preço médio pago cana de açúcar. O web services utilizado foi desenvolvido utilizando a ferramenta Web Developer 2005 Express Edition. Esta ferramenta contém como padrão as pastas App_Code (para o web services) e App_Data (contém os arquivos service.asmx e web.config). A seguir é exemplificado o arquivo service.vb: Imports System.Data.SqlClient Imports System.Web.Services <System.Web.Services.WebService(Namespace:=" o/service1")> _ Public Class Service1 Inherits System.Web.Services.WebService //Informa que o método deve ser exposto como um web services <WebMethod(Description:="Consulta banco de dados e retorna DataSet")> _ Function RetornaDataSetResult(ByVal strquery As String) As Data.DataSet Dim conn As New SqlConnection Dim cmd As New SqlCommand Dim da As New SqlDataAdapter Dim tabela As New Data.DataSet //Obtem a string de conexão definida no arquivo web.config conn.connectionstring = "Data Source=localHost;UserID=TESTE;Password=290787;InitialCatalog= DADOSPRODUCAO,EXPORTAÇÃO_ANUAL_ACUCAR_LOCAL_EMBARQUE, EXPORTACAO_ANUAL_ACUCAR_ORIGEM,EXPORTACAOANUALETANOL,EXPORTACAOANUALETANOL, PRECO_MEDIO_PAGO,CANA_ACUCAR" cmd.connection = conn cmd.commandtext = strquery da.selectcommand = cmd da.fill(tabela) conn.dispose() cmd.dispose() da.dispose() 89

91 //Retorna os dados Return tabela End Function End Class A seguir o arquivo padrão web.config criado no web developer com as seguintes alterações para conexão. <?xml version="1.0"?> <configuration> <appsettings> <add key="localhost.service" value=" </appsettings> <connectionstrings> <add name="conexaoteste" connectionstring="data Source=.\SQLEXPRESS;Initial Catalog=DADOSPRODUCAO,EXPORTAÇÃO_ANUAL_ACUCAR_LOCAL_EMBARQUE, EXPORTACAO_ANUAL_ACUCAR_ORIGEM,EXPORTACAOANUALETANOL,EXPORTACAOANUALETANOL, PRECO_MEDIO_PAGO,CANA_ACUCAR;Integrated Security=True" providername="system.data.sqlclient"/> </connectionstrings> <system.web> <compilation debug="true" strict="false" explicit="true"/> <pages> <namespaces> <clear/> <add namespace="system"/> <add namespace="system.collections"/> <add namespace="system.collections.specialized"/> <add namespace="system.configuration"/> <add namespace="system.text"/> <add namespace="system.text.regularexpressions"/> <add namespace="system.web"/> <add namespace="system.web.caching"/> <add namespace="system.web.sessionstate"/> <add namespace="system.web.security"/> <add namespace="system.web.profile"/> <add namespace="system.web.ui"/> <add namespace="system.web.ui.webcontrols"/> <add namespace="system.web.ui.webcontrols.webparts"/> <add namespace="system.web.ui.htmlcontrols"/> </namespaces> </pages> <authentication mode="windows"/> </system.web> </configuration> Ao analisar o código do arquivo service.vb nota-se que o método RetornaDataSetResult recebe como parâmetro um comando em sql e posteriormente, consulta o banco de dados denominado DADOSPRODUÇÃO e retorna os seus dados. A figura 41 ilustra essa etapa: 90

92 Figura 41: Parâmetro Fonte: (Leal, 2014) A figura 42 a seguir exemplifica a chamada do web service. Em contrapartida, a figura 43 ilustra o wsdl gerado. Figura 42: Consulta ao Banco de dados Fonte: (Leal, 2014) 91

93 Figura 43: WSDL gerado automaticamente Fonte: (Leal, 2014) A etapa final corresponde a realizar o "deploy" dos processos em um dos ambientes: desenvolvimento, teste ou produção. A figura 44 ilustra o work portal para execução dos processos. Figura 44: Portal dos processos Fonte: (Leal, 2014) Analisando a figura 44 nota-se que inicialmente não há nenhum processo sendo executado. Em contrapartida, a figura 45 apresenta a execução do processo design sustentável. 92