Fasci-Tech – Periódico Eletrônico da FATEC-São Caetano do Sul, São Caetano do Sul, v. 1, n.
5, Out/Dez 2011, p. 129 a 140.
INTEGRAÇÃO ENTRE BPMN E UML: APLICANDO O MODELO
USE PROCESSES
Renan Dozorski Conrado1 Prof. MSc. Wilson Vendramel2
RESUMO:
Problemas com o entendimento de requisitos podem acarretar prejuízos nas outras etapas do desenvolvimento de um projeto de software. Assim, foi criado um modelo, o Use Processes (UP), que visa facilitar o entendimento dos requisitos de software. O UP tem um diagrama que é derivado de duas notações, o BPMN e o Diagrama de Casos de Uso. Com a aplicação deste modelo, deseja-se que o usuário tenha uma maior facilidade de entendimento de como o software irá cooperar de acordo com o processo de negócio da empresa.
Palavras-Chave: Use Processes, BPMN, Casos de Uso, UML ABSTRACT:
Problems with the understanding of requirements can lead to losses in the other stages of the development of a software project. Thus it was created a model, Use Processes (UP), which aims to facilitate the understanding of the software requirements. The UP has a diagram that is derived from two notations, BPMN and Use Case Diagram. With the application of this model, it is desired that the user has an easier understanding of how the software will cooperate in accordance with the company's business process.
Keywords: Use Processes, BPMN, Use Cases, UML
1 INTRODUÇÃO:
Com o tempo, a área de desenvolvimento de software evolui de acordo com as necessidades tecnológicas, para a construção de um software de qualidade e que atenda de forma plena as necessidades do cliente. Com isso, novas técnicas de modelagem de
1
Aluno de Iniciação Científica do Curso de Bacharelado em Análise de Sistemas e Tecnologia da Informação da FATEC-São Caetano do Sul.
2
Fasci-Tech – Periódico Eletrônico da FATEC-São Caetano do Sul, São Caetano do Sul, v. 1, n.
5, Out/Dez 2011, p. 129 a 140.
requisitos surgem, possibilitando escolher a mais adequada para cada projeto ou ainda realizar uma combinação de várias delas para a concepção do produto.
No entanto, apenas escolher uma metodologia de desenvolvimento mais apropriada não garante que se criará um software que atenda as necessidades de quem o solicitou. Portanto, o entendimento dos requisitos é muito importante para descobrir tais informações. Há recursos que podem auxiliar nesta fase, por exemplo, saber em quais processos da empresa o software terá influência pode ser de grande ajuda. Para isto, é possível utilizar o Business Process Modeling Notation (BPMN) para modelar os processos de negócios e conhecer o fluxo das atividades da empresa. A Unified
Modeling Language (UML) também pode ajudar por meio do Diagrama de Casos de
Uso, que demonstrará quem vai interagir com o sistema e quais serão as funcionalidades do mesmo. Porém, estas duas notações são independentes uma da outra.
Assim, foi criado um modelo chamado Use Processes, que é a integração do BPMN e do Diagrama de Casos de Uso da UML. Com isso, em apenas um diagrama, pode-se saber qual funcionalidade será utilizada e onde ela se encaixará no processo da empresa.
Portanto, este artigo demonstrará este modelo visando uma maior facilidade no entendimento dos requisitos.
2 ENGENHARIA DE REQUISITOS
A engenharia de requisitos é definida por Sommerville (2007, p.49) como “o processo para compreender e definir quais serviços são necessários e identificar restrições de operação e de desenvolvimento do sistema”. Já para Pressman (1995, p. 231), esta etapa “é um processo de descoberta, refinamento, modelagem e especificação”.
Mesmo que um software fosse bem projetado ou muito bem codificado, de nada valeria se não atendesse as necessidades do cliente, trazendo desapontamentos tanto
Fasci-Tech – Periódico Eletrônico da FATEC-São Caetano do Sul, São Caetano do Sul, v. 1, n.
5, Out/Dez 2011, p. 129 a 140.
para os desenvolvedores como para os clientes (PRESSMAN, 1995). Por isso, este momento na criação de um software é tão crítico, pois erros neste estágio acarretarão problemas posteriores no projeto e na implementação do sistema (SOMMERVILLE, 2007). Logo, é necessário usar métodos e ferramentas adequadas para esta etapa, como o BPMN e a UML, que são exemplos destas ferramentas.
3 BPMN: BUSINESS PROCESS MODEL AND NOTATION
O Business Process Model and Notation (BPMN) ou Notação de Modelagem de Processos de Negócio foi proposta por um grupo de profissionais do Business Process
Management Institute (BPMI) em agosto de 2001, para que fosse criada uma notação
padronizada para realizar a diagramação dos processos de negócio, mas, em junho de 2005, houve a junção do BPMI com a Object Management Group (OMG) que passou a ser responsável pela evolução do BPMN (CUNHA, 2008).
Esta notação especifica o processo de negócios através de gráficos que representam sua lógica. Para isso, é aplicado apenas um modelo denominado Diagrama de Processo de Negócios (DPN) ou Business Process Diagram (BPD) (DE SORDI, 2008).
O objetivo primário do BPMN é prover uma notação que seja entendível por todos os usuários de negócio, que abrange os seguintes envolvidos (OMGa, 2011):
Os analistas de negócio que criam um desenho inicial dos processos de negócio; Os desenvolvedores técnicos que são os responsáveis por implementar
tecnologicamente a execução destes processos;
E por último, as pessoas de negócio que gerenciarão e monitorarão estes processos.
Assim, o BPMN cria uma ponte padronizada que preenche a lacuna entre o processo de negócio e o processo de implementação (OMGa, 2011). Além disso, segundo De Sordi (2008), esta notação é abrangente, intuitiva e fácil de ser trabalhada, pois consegue expressar em um único diagrama os processos de negócios.
Fasci-Tech – Periódico Eletrônico da FATEC-São Caetano do Sul, São Caetano do Sul, v. 1, n.
5, Out/Dez 2011, p. 129 a 140.
4 UML: MODELO DE CASOS DE USO
Outra ferramenta que pode ser usada para melhorar o entendimento dos requisitos é o Modelo de Casos de Uso, da UML. Para Bezerra (2006, p.45), “o modelo de casos de uso é uma representação das funcionalidades externamente observáveis do sistema e dos elementos externos ao sistema que interagem com ele”. Já para Booch, Rumbaugh e Jacobson (2005, p. 230), “um caso de uso é uma descrição de um conjunto de sequências de ações, inclusive variantes, que um sistema executa para produzir um resultado de valor observável por um ator”.
Os casos de uso fornecem subsídios para que os desenvolvedores consigam captar o comportamento de um sistema, sem a necessidade de saber como ele será implementado, isso junto aos usuários finais e especialistas do domínio. Além disso, eles podem ajudar a validar a arquitetura e a verificar o sistema à medida que evolui (BOOCH, RUMBAUGH & JACOBSON, 2005).
Por mais que os casos de uso possam auxiliar em outras etapas do projeto, eles são mais usados e essenciais na fase de levantamento de requisitos. Para Bezerra (2006), o modelo de casos de uso faz parte da especificação de requisitos e também molda os requisitos funcionais do sistema. E se populariza cada vez mais, pois sua notação gráfica é simples e sua descrição é em linguagem natural, facilitando a comunicação de desenvolvedores e stakeholders.
Os principais conceitos associados ao modelo de casos de uso são atores, casos de uso e assunto. O assunto é o sistema em que os casos de uso estão inclusos. Os usuários e outros sistemas que podem interagir com o assunto são representados como atores, que são sempre entidades do modelo que estão fora do sistema. O comportamento exigido do ator é determinado por um ou mais casos de uso, que são definidos de acordo com as necessidades dos atores (OMGb, 2010).
Fasci-Tech – Periódico Eletrônico da FATEC-São Caetano do Sul, São Caetano do Sul, v. 1, n.
5, Out/Dez 2011, p. 129 a 140.
5 MODELO USE PROCESSES
Este modelo chamado de Use Processes (UP) foi idealizado por Hernández, Rodríguez e Martin (2010) com o “objetivo de apresentar uma visão geral das funcionalidades que um sistema deve oferecer no âmbito das atividades de um processo de negócio”.
Esta abordagem inclui um diagrama, o Use Processes Diagram (UPD), que é baseado nos elementos de notação do BPMN e do Diagrama de Casos de Uso (DCU), que foram adaptados para compor o modelo criado. Segundo Hernández, Rodríguez e Martin (2010), esta abordagem facilitará o desenvolvimento da especificação dos requisitos, pois a metodologia tem a intenção de ser de fácil entendimento tanto para a equipe técnica quanto para os stakeholders, além de detectar e possivelmente solucionar problemas relacionados ao processo de negócio da organização.
5.1 Elementos do Use Processes Diagram (UPD)
Como o UPD é a junção do BPMN e Casos de Uso, alguns elementos foram adaptados, conforme a tabela 1:
Tabela 1: Elementos de um diagrama Use Processes
Elemento Descrição Notação
Evento Elemento utilizado para indicar o começo ou final de um processo de negócio.
Início
Fasci-Tech – Periódico Eletrônico da FATEC-São Caetano do Sul, São Caetano do Sul, v. 1, n.
5, Out/Dez 2011, p. 129 a 140.
Atividade
Atividade dentro da fronteira do sistema que é realizada por um determinado ator.
Atividade fora da fronteira do sistema é realizada por um determinado ator.
Sub-Processo dentro da fronteira do sistema é realizado por um determinado ator.
Sub-Processo fora da fronteira do sistema é realizado por um determinado ator.
Fluxo de Sequência Um Fluxo de Sequência é usado para mostrar a ordem em que as atividades serão realizadas em um processo.
Gateway Um Gateway é usado para determinar a direção e/ou união de caminhos.
Fasci-Tech – Periódico Eletrônico da FATEC-São Caetano do Sul, São Caetano do Sul, v. 1, n.
5, Out/Dez 2011, p. 129 a 140.
Caso de Uso Um Caso de Uso representa uma funcionalidade do sistema.
Ator
Um ator representa um papel que interage com o sistema. Há uma adaptação na notação original, pois é incluído um ID na cabeça do ator.
Relacionamento
Inclusão: relaciona somente casos de uso, mostrando que um caso de uso depende de outro.
Extensão: relaciona somente casos de uso, mostrando que um caso de uso pode ter um comportamento alternativo.
Fonte: Adaptado de Hernández, Rodríguez e Martin (2010).
6 APLICAÇÃO DO MODELO USE PROCESSES
Para aplicar o modelo UP, houve a necessidade de procurar uma organização em que fosse possível criar um projeto de software que agregasse valor ao negócio. Logo, foi identificada na instituição Igreja Batista Água Viva (IBAV) a necessidade de automatização de seu processo de negócio através de um software.
Fasci-Tech – Periódico Eletrônico da FATEC-São Caetano do Sul, São Caetano do Sul, v. 1, n.
5, Out/Dez 2011, p. 129 a 140.
No cenário atual da IBAV, as informações são armazenadas em planilhas eletrônicas, assim como o controle dos seus processos. Este controle consiste na geração semanal e mensal de alguns relatórios estatísticos. Assim, foi proposta a automatização do negócio através de um software, que foi aceita por parte do cliente.
Hernández, Rodríguez e Martin (2010), sugeriram cinco etapas para que o UP fosse aplicado e que serão seguidas para este projeto. Estas cinco etapas são:
Descrição do Problema;
Modelagem do Processo de Negócio; Definição da Fronteira do Sistema;
Descrição das Atividades e dos Papéis Envolvidos;
Identificação e Descrição das Funcionalidades do Sistema.
Então, para dar início ao projeto foi realizada a etapa de descrição do problema. Através de reuniões realizadas com os stakeholders foram identificadas as seguintes situações:
Dificuldade por parte do usuário em alterar as planilhas, devido a haver muitas fórmulas. Por exemplo, ao adicionar um novo grupo (uma nova linha) as fórmulas eram alteradas, necessitando um retrabalho para acertá-las;
Algumas planilhas são utilizadas por mais de uma pessoa, havendo a necessidade de proteger as fórmulas para não serem alteradas;
Os relatórios mensais eram atualizados e impressos manualmente direto da planilha eletrônica;
O cadastro dos membros estava armazenado em planilhas eletrônicas.
Após isso, foi necessário descobrir qual é o fluxo das atividades em que ocorre o processo de geração de relatórios. Descobrindo isto, já foi possível realizar a etapa de
Fasci-Tech – Periódico Eletrônico da FATEC-São Caetano do Sul, São Caetano do Sul, v. 1, n.
5, Out/Dez 2011, p. 129 a 140.
Modelagem de Processo de Negócio. Nela, é criado um diagrama BPMN correspondente ao processo de negócio. A figura 1 demonstra o diagrama criado neste trabalho:
Figura 1: Diagrama BPMN para o processo de geração de relatórios da IBAV
Com base no diagrama da figura 1, a etapa de Definir as Fronteiras do Sistema também já pôde ser realizada. Assim, sabe-se em qual tarefa do processo de negócio o sistema irá influenciar diretamente, além de demonstrar, em cada tarefa, qual papel a realiza. A figura 2 demonstra a terceira etapa do modelo UP.
Fasci-Tech – Periódico Eletrônico da FATEC-São Caetano do Sul, São Caetano do Sul, v. 1, n.
5, Out/Dez 2011, p. 129 a 140.
Na figura 2, os retângulos em negrito, são as tarefas que estão diretamente relacionadas com o sistema, ou seja, as que serão automatizadas. E também, em cada uma, há pelo menos um ator (Secretária, Líder ou Coordenador), simbolizado no canto inferior esquerdo da tarefa, que é responsável por cumpri-la.
As últimas duas etapas estão ainda em desenvolvimento, porém já foi possível verificar quais funcionalidades o sistema terá que ter para automatizar as tarefas. Na figura 3, são demonstradas as funcionalidades.
Figura 3: Diagrama Uses Processes para o processo de geração de relatórios da IBAV.
Neste momento, o diagrama da figura 3 já é considerado um modelo Uses
Processes, pois houve a integração do BPMN com os Casos de Uso da UML. Pode-se
perceber que em cada tarefa, que é fronteira do sistema, existe um ou mais casos de uso relacionados.
Fasci-Tech – Periódico Eletrônico da FATEC-São Caetano do Sul, São Caetano do Sul, v. 1, n.
5, Out/Dez 2011, p. 129 a 140.
Portanto, com a descrição das atividades, dos papéis envolvidos e dos casos de uso que ainda falta realizar, as cinco etapas propostas por Hernández, Rodríguez e Martin (2010) estarão completas. Logo, será possível dar início à construção do sistema de acordo com o que foi levantado.
7 CONSIDERAÇÕES FINAIS
Apesar de o projeto ainda não estar concluído, percebeu-se que o modelo Uses
Processes que foi criado auxiliou no entendimento dos requisitos de software tanto para
os desenvolvedores do projeto como para o cliente. Nas primeiras reuniões, ficou um tanto nebuloso demonstrar ao cliente como um sistema poderia automatizar o seu processo de negócio, porém com o diagrama criado foi possível facilitar este entendimento. Outro ponto é que o desenvolvedor pensava que o fluxo das tarefas era realizado de modo diferente, porém com o diagrama ficou claro como é realizado o processo no ambiente interno da organização.
Até este momento, foi demonstrado que a integração do BPMN e dos Casos de Uso pode ser benéfica para que haja um maior entendimento dos requisitos de software.
REFERÊNCIAS:
BEZERRA, E. Princípios de Análise e Projeto de Sistemas UML. 2 ed. Ed. Campus, Rio de Janeiro: Elsevier, 2006.
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: guia do usuário. Ed. Campus, Rio de Janeiro: Elsevier, 2005.
CUNHA, G. J. Metodologia para modelagem do sistema agroindustrial visando
identificar parâmetros de rastreabilidade e qualidade – aplicação na Malacocultura
Continental. (Tese Doutorado), 2008, 137 p. - Departamento de Engenharia de Computação e Sistemas Digitais, Escola Politécnica da Universidade de São Paulo, São Paulo, 2008.
DE SORDI, J.O. Gestão por processos: uma abordagem da moderna administração. 2. ed. Ed. Saraiva, São Paulo: Saraiva, 2008.
Fasci-Tech – Periódico Eletrônico da FATEC-São Caetano do Sul, São Caetano do Sul, v. 1, n.
5, Out/Dez 2011, p. 129 a 140.
, U. , F. J. A.; MARTIN, M. V.; Use Processes – Modeling Requirements Based on Elements of BPMN and UML. Use
Case Diagrams. Centro de Cienc. Basicas, Univ. Autonoma de Aguascalientes, Aguascalientes, Mexico, 2010. Disponível em <http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=5608758>. Acessado em maio de 2011
OMGa. Documents Associated with Business Process Model and Notation (BPMN)
Version 2.0, 2011. Disponível em <http://www.omg.org/spec/BPMN/2.0/>. Acessado
em maio de 2011.
OMGb. Documents associated with UML Version 2.3, 2010. Disponível em <http://www.omg.org/spec/UML/2.3/Superstructure/PDF>. Acessado em maio de 2011.
PRESSMAN, R. S. Engenharia de software. São Paulo: Pearson Education. 1995.
SOMMERVILLE, I. Engenharia de software. 8 ed. São Paulo: Pearson Education. 2007.
