DIRETORIA DE PESQUISA E PÓS-GRADUAÇÃO
PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
HABNER FABRÍCIO BOESING
MÉTODO DE TRANSFORMAÇÃO DE MODELOS DE PROCESSOS
DE NEGÓCIO PARA DIAGRAMAS DE CLASSES DE ANÁLISE
DISSERTAÇÃO
PONTA GROSSA 2019
MÉTODO DE TRANSFORMAÇÃO DE MODELOS DE PROCESSOS
DE NEGÓCIO PARA DIAGRAMAS DE CLASSES DE ANÁLISE
Dissertação apresentada como requisito parcial à obtenção do grau de Mestre em Ciência da Computação, do Diretoria de Pós-Graduação em Ciência da Computação, da Universidade Tecnológica Federal do Paraná.
Orientadora: ProfaDra. Simone Nasser Matos
PONTA GROSSA 2019
Ficha catalográfica elaborada pelo Departamento de Biblioteca
da Universidade Tecnológica Federal do Paraná, Campus Ponta Grossa n.45/19
Elson Heraldo Ribeiro Junior. CRB-9/1413. 23/05/2019. B672 Boesing, Habner Fabrício
Método de transformação de modelos de processos de negócio para diagramas de classes de análise. / Habner Fabrício Boesing, 2019.
106 f. : il. ; 30 cm.
Orientadora: Profa. Dra. Simone Nasser Matos
Dissertação (Mestrado em Ciência da Computação) - Programa de Pós-Graduação em Ciência da Computação. Universidade Tecnológica Federal do Paraná, Ponta Grossa, 2019.
1. UML (Computação). 2. Negócios - Modelos. 3. Sistemas de informação gerencial. 4. Controle de processo. I. Matos, Simone Nasser. II. Universidade Tecnológica Federal do Paraná. III. Título.
Diretoria de Pesquisa e Pós-Graduação
Programa de Pós-Graduação em Ciência da Computação
FOLHA DE APROVAÇÃO
Título de Dissertação Nº 12/2019
MÉTODO DE TRANSFORMAÇÃO DE MODELOS DE PROCESSOS DE NEGÓCIO PARA DIAGRAMAS DE CLASSE DE ANÁLISE
Por
Habner Fabrício Boesing
Esta dissertação foi apresentada às 15 horas e 30 minutos de 18 de abril de 2019, na DIRPPG, como requisito parcial para a obtenção do título de MESTRE EM CIÊNCIA DA COMPUTAÇÃO, Programa de Pós-Graduação em Ciência da Computação. O candidato foi arguido pela Banca Examinadora, composta pelos professores abaixo assinados. Após deliberação, a Banca Examinadora considerou o trabalho APROVADO.
Profª. Drª. Letícia Mara Peres (UFPR) Profª. Drª. Helyane Bronoski Borges (UTFPR)
Profª. Drª. Simone Nasser Matos (UTFPR)
Orientador(a) e presidente da banca
Visto da Coordenadora:
Profª. Drª. Helyane Bronoski Borges Coordenadora do PPGCC UTFPR – Câmpus Ponta Grossa
BOESING, Habner Fabrício. Método de transformação de modelos de processos de negócio
para diagramas de classes de análise. Dissertação de Mestrado em Ciência da Computação,
Universidade Tecnológica Federal Do Paraná. Ponta Grossa, 2019.
A modelagem de processos de negócio constitui uma etapa importante na identificação de requi-sitos de sistema, o qual também é utilizado como base para a modelagem do mesmo. No entanto, dificuldades são encontradas ao realizar a transformação dos elementos presentes em um mo-delo de negócio para um momo-delo de sistema em razão de cada um utilizar notações e linguagens diferentes em sua criação. Em razão disso, métodos de transformação são propostos para realizar a interpretação dos elementos de um modelo ao outro para evitar que informações importantes sejam perdidas no processo de modelagem do sistema. Com este objetivo, foi realizado um ma-peamento sistemático para identificar publicações sobre métodos de transformação de modelos de negócio para modelos de sistema. Na literatura foram encontrados diferentes métodos pro-postos para a realização desta transformação, no entanto, na maior parte dos casos não ocorre uma transformação direta do modelo de negócios para o diagrama de classes de análise e quando ocorre não é utilizado um processo formalizado para a geração da estrutura deste diagrama, o que pode resultar em falhas caso seja realizado de forma totalmente manual por um analista. Outro problema observado é a quantidade reduzida de elementos que são transformados, sendo que, muitos dos elementos do modelos de negócio poderiam ser transformados em elementos do diagrama de classes, mas são descartados durante as etapas do processo de transformação. A partir destas informações, este trabalho propôs a criação do método de transformação TMBC, o qual transforma diretamente modelos de negócio, criados por meio da notação Business
Pro-cess Model and Notation (BPMN), para modelos de classes de análise, criados utilizando o
diagrama de classes da notação Unified Modeling Language UML. O método utiliza a arqui-tetura de transformação Model Driven Architecture (MDA) para a criação dos modelos, a qual define a modelagem como o centro do processo de desenvolvimento com o objetivo de des-considerar limitações referentes à plataforma utilizada para a implementação do sistema. Para a formalização do processo é utilizada a linguagem de transformação de modelos Atlas
Transfor-mation Language(ATL), onde são criadas as regras de relacionamento entre os elementos dos
metamodelos da BPMN e da UML, que posteriormente são executadas para gerar a estrutura do modelo final em XML Metadata Interchange (XMI) que é utilizado para a criação do modelo do diagrama de classes. Para verificação da aplicabilidade do método a transformação foi realizada em 3 estudos de caso diferentes e os pontos de destaque foram comparados com outros métodos presentes na literatura.
BOESING, Habner Fabrício. Transformation method of business process model to analysis
class diagrams. Masther’s Degree Thesis in Computer Science, Federal Technology University
- Paraná. Ponta Grossa, 2019.
Business process modeling is an important step in the identification of system requirements, which is also the basis for modeling the system. However, difficulties are encountered when performing the transformation of the elements present in a business model to a system model because each one uses different notations and languages in its creation. Therefore, transformation methods are proposed to perform the interpretation of the elements from one model to another to avoid important information being lost in the modeling process of the system. With this objec-tive, a systematic mapping was performed to identify publications on methods of transforming business models for system models. In the literature, there are different methods proposed to per-form this transper-formation, however, in most cases there is no direct transper-formation of the business model to the class diagram and when it happen it does not use a formalized process for the gene-ration of the diagram structure, which can result in failures if performed entirely manually by an analyst. Another problem observed is the reduced number of elements that are transformed and beside this, many of the elements of business models could be transformed into elements of the class diagram, but are discarded during the steps of the transformation process. From this infor-mation, this work proposes the creation of the TMBC transformation method, which transforms business models, created using the Business Process Model and Notation (BPMN), for analy-sis class models created using the class diagram of the notation Unified Modeling Language (UML). The method uses the Model Driven Architecture (MDA), which defines modeling as the center of the development process in order to disconsider limitations related to the platform used for system implementation. In order to formalize the process, it is used the Atlas Transfor-mation Language (ATL), where the relationship rules between the elements of the BPMN and UML metamodels are created, which are then executed to generate the final model structure in XML Metadata Interchange (XMI) that is used to create the class diagram model. To verify the applicability of the method the transformation was performed in 3 different study cases and the important points were compared with other methods present in the literature.
Figura 1 – Metamodelo da BPMN . . . 18
Figura 2 – Representação de Atividades na BPMN . . . 19
Figura 3 – Tipos de Portais da BPMN. . . 20
Figura 4 – Tipos de Eventos da BPMN . . . 21
Figura 5 – Tipos de Objetos de Conexão da BPMN . . . 22
Figura 6 – Tipos de Partições da BPMN . . . 22
Figura 7 – Tipos de Artefatos da BPMN . . . 23
Figura 8 – Diagramas da UML . . . 25
Figura 9 – Metamodelo da UML . . . 26
Figura 10 – Notação UML para Representação da Classe . . . 27
Figura 11 – Exemplo de Relacionamento de Associação . . . 29
Figura 12 – Exemplo de Relacionamento de Agregação . . . 29
Figura 13 – Exemplo de Relacionamento de Composição . . . 30
Figura 14 – Exemplo de Generalização . . . 31
Figura 15 – Exemplo de Classe Associativa . . . 31
Figura 16 – Exemplo de Relacionamento de Dependência . . . 32
Figura 17 – Exemplo de Relacionamento de Realização . . . 32
Figura 18 – Tipos de Notações de Estereótipos na UML . . . 34
Figura 19 – Níveis da MDA. . . 36
Figura 20 – Esquema Geral de Transformação de Modelos . . . 37
Figura 21 – Arquitetura ATL . . . 39
Figura 22 – Processo de Transformação do Modelo na ATL. . . 40
Figura 23 – Quantidade de Publicações por Ano . . . 56
Figura 24 – Fases do Método de Transformação TMBC . . . 60
Figura 25 – Estrutura do Padrão de Projeto Strategy . . . 65
Figura 26 – Arquitetura ATL Aplicada ao Método de Transformação . . . 67
Figura 27 – Relacionamentos entre o Modelo BPMN e o Modelo de Diagrama de Classes 68 Figura 28 – Regra R1 - Transformação de Piscina para Classe . . . 69
Figura 29 – Regra R2 - Transformação de Raia para Classe . . . 69
Figura 30 – Relacionamentos R3 - Transformação de Grupo para Classe . . . 70
Figura 31 – Relacionamentos R4 - Transformação de Tarefa para Classe . . . 71
Figura 32 – Relacionamentos R4 - Transformação de Tarefa para Operação no Caso 1 . 72 Figura 33 – Relacionamentos R4 - Transformação de Tarefa para Operação no Caso 2 . 73 Figura 34 – Relacionamentos R5 - Transformação do Portal Exclusivo para Classe . . . . 74
Figura 35 – Relacionamentos R6 - Transformação de Objeto de Dados para Classe . . . . 75
Figura 36 – Relacionamentos R7 - Transformação de Fluxo de Mensagem para Asso-ciação . . . 76
Figura 37 – Regra de Transformação R1 em ATL . . . 78
Figura 38 – Configuração da Execução da Regras ATL . . . 79
Figura 39 – Modelo BPMN do Estudo de Caso 1 . . . 82
Figura 40 – Modelo BPMN do Estudo de Caso 1 Criado na Estrutura XMI . . . 83
Figura 41 – Exemplo da Transformação das Regra R1 e R2 Através da Análise do XMI 84 Figura 42 – Modelo de Diagrama de Classes Gerado na Transformação do Estudo de Caso 1 . . . 85
Figura 45 – Modelo BPMN do Estudo de Caso 3 . . . 87 Figura 46 – Modelo de Diagrama de Classes Gerado na Transformação do Estudo de
Quadro 1 – Exemplos de Multiplicidade . . . 28
Quadro 2 – Definição das Bases de Pesquisa . . . 44
Quadro 3 – Definição das String de Busca . . . 44
Quadro 4 – Artigos de Periódicos . . . 48
Quadro 5 – Artigos de Conferências . . . 49
Quadro 6 – Contribuição dos Artigos de Periódicos . . . 52
Quadro 7 – Contribuição das Publicações em Conferências . . . 53
Quadro 8 – Elementos do BPMN . . . 62
Quadro 9 – Elementos da UML . . . 63
Quadro 10 – Similaridades entre os Elementos do BPMN e do Diagrama de Classes . . 64
Tabela 1 – Total de Resultados por String . . . 45
Tabela 2 – Primeiro Processo de Filtragem . . . 46
Tabela 3 – Segundo Processo de Filtragem . . . 46
Tabela 4 – Terceiro Processo de Filtragem . . . 47
Tabela 5 – Quarto Processo de Filtragem . . . 47
Tabela 6 – Ordenação dos Artigos. . . 50
Tabela 7 – Ordenação das Publicações em Conferências. . . 50
Tabela 8 – Modelos de Processos de Negócio Utilizados . . . 54
ATL Atlas Transformation Language
BPD Business Process Diagram
BPMN Business Process Model and Notation
CIM Computation Independent Model
EMF Eclipse Modeling Framework
GMF Graphical Modeling Framework
GMP Graphical Modeling Project
JCR Journal Citation Reports
MDA Model Driven Architecture
MOF Managed Object Format
MVC Model View Controller
OCL Object Constraint Language
OMG Object Management Group
PIM Plataform Independent Model
PSM Plataform Specific Model
QVT Query View Transformation
SBVR Semantics Of Business Vocabulary And Rules
SJR Scientific Journal Rankings
TMBC Transformation Method of BPMN to Class Diagrams
UML Unified Modeling Language
1 INTRODUÇÃO . . . 12 1.1 OBJETIVO GERAL . . . 14 1.2 OBJETIVOS ESPECíFICOS . . . 14 1.3 JUSTIFICATIVA . . . 14 1.4 ORGANIZAÇÃO DO TRABALHO. . . 15 2 REFERENCIAL TEÓRICO . . . 16
2.1 MODELOS DE PROCESSOS DE NEGÓCIO (BPMN) . . . 16
2.1.1 Objetos de Fluxo . . . 18
2.1.2 Objetos de Conexão . . . 21
2.1.3 Partições (Swinlanes) . . . 22
2.1.4 Artefatos . . . 23
2.2 MODELOS DE ANÁLISE (DIAGRAMA DE CLASSES) . . . 24
2.2.1 Classes . . . 26
2.2.2 Relacionamentos entre Classes . . . 28
2.2.2.1 Associação . . . 28 2.2.2.2 Agregação. . . 29 2.2.2.3 Composição . . . 29 2.2.2.4 Generalização . . . 30 2.2.2.5 Classe Associativa . . . 30 2.2.2.6 Dependência . . . 31 2.2.2.7 Realização . . . 32 2.2.3 Estereótipos . . . 33 2.3 TRANSFORMAÇÃO DE MODELOS . . . 34
2.3.1 Model Driven Architecture(MDA) . . . 35
2.3.2 Atlas Transformation Language (ATL) . . . 38
2.4 CONSIDERAÇÕES FINAIS . . . 41
3 ESTADO DA ARTE. . . 42
3.1 MÉTODO DE MAPEAMENTO SISTEMÁTICO . . . 42
3.2 QUESTÕES DE PESQUISA . . . 43
3.3 SELEÇÃO DA BASES DE PESQUISA . . . 43
3.4 DEFINIÇÃO DOS TERMOS DE BUSCA . . . 44
3.5 REALIZAÇÃO DAS BUSCAS . . . 44
3.6 PROCEDIMENTOS DE FILTRAGEM . . . 45 3.7 CRITÉRIOS DE ORDENAÇÃO . . . 49 3.8 RESULTADOS . . . 51 3.9 TRABALHOS RELACIONADOS . . . 56 3.10 CONSIDERAÇÕES FINAIS . . . 58 4 MÉTODO DE TRANSFORMAÇÃO TMBC . . . 59
4.1 VISÃO GERAL DO MÉTODO PROPOSTO . . . 59
4.2 IDENTIFICAÇÃO DOS ELEMENTOS DOS MODELOS DE ORIGEM E DESTINO 61 4.3 IDENTIFICAÇÃO DE SIMILARIDADES E RESTRIÇÕES DOS MODELOS . . . 64
4.4 CRIAÇÃO DAS REGRAS DE TRANSFORMAÇÃO . . . 66
4.5 FORMALIZAÇÃO DAS REGRAS DE TRANSFORMAÇÃO UTILIZANDO A ATL 77 4.6 CONSIDERAÇÕES FINAIS . . . 80
5 RESULTADOS . . . 81
5.4 COMPARATIVO ENTRE TMBC E MÉTODOS PROPOSTOS NA LITERATURA 89
5.5 CONSIDERAÇÕES FINAIS . . . 91
6 CONCLUSÃO . . . 92
6.1 TRABALHOS FUTUROS . . . 94
REFERÊNCIAS . . . 98
Apêndice A REGRAS DE TRANSFORMAÇÃO DO TMBC . . . 99
Apêndice B ARQUIVO XMI DO ESTUDO DE CASO 1 . . . 102
Apêndice C ARQUIVO XMI DO ESTUDO DE CASO 2. . . 104
1 INTRODUÇÃO
A construção de modelos de processos de negócio auxilia na organização dos proce-dimentos da empresa e possibilita uma visão completa dos processos, o que consequentemente torna a gestão mais integrada.
A partir da modelagem dos processos de negócio é possível definir as funcionalidades de um sistema para automatizar as atividades envolvidas. No entanto, para seu desenvolvimento a complexidade se torna alta caso não seja realizada uma análise de requisitos e uma modelagem do sistema, a qual possa abranger as necessidades do negócio (PRESSMAN, 2006).
Na engenharia de software existem diferentes modelos para o levantamento de requisi-tos e tratamento de informações de negócios e de sistemas. Cada modelo construído apresenta uma abordagem distinta, o que consequentemente pode tornar confusa a construção do sistema. Com o intuito de propor padrões de modelagem, houve o surgimento do Object
Ma-nagement Group(OMG), uma organização internacional que é responsável por aprovar padrões
abertos para aplicações orientadas a objetos (OMG, 2018b).
A OMG define a notação Bussiness Process Model and Notation (BPMN) como padrão para a modelagem de processos de negócio, a qual atende as diversas conformidades referentes à linguagem, modelagem e execução de processos (OMG, 2014a). A realização da modelagem de processos de negócio pode servir como fonte para o desenvolvimento do modelo de sistema, principalmente por expressar informações fundamentais para o levantamento dos requisitos. Isso se deve pelo fato do modelo expressar melhor a organização dos processos da empresa como um todo (PHALP, 1998).
Para criação dos modelos de sistema, a OMG define a notação Unified Modeling
Lan-guage(UML), uma linguagem padrão de modelagem para a elaboração de projetos de software,
tendo como objetivo principal a modelagem de sistemas concorrentes e distribuídos (OMG, 2017). Ao todo, existem quinze tipos de diagramas definidos pela UML, separados em diagra-mas de estrutura e diagrama de comportamento que, segundo Heredia (2012, p. 27) “ajudam o analista de sistemas a entender a informação, função e comportamento de um sistema, tornando a análise de requisitos mais fácil e sistemática”.
Apesar do modelo de negócio auxiliar na definição dos requisitos que o sistema deve atender, nem sempre a interpretação é clara, o que pode fazer com que o resultado obtido não seja o mesmo que o previsto inicialmente. Com isso, surge a necessidade de estabelecer um processo de transformação, relacionando e convertendo elementos nos modelos de negócio para os elementos existentes nos modelos de sistema, criando um nível intermediário de interpretação e ligação entre ambos (ODEH; KAMM, 2003).
Para realizar este processo a arquitetura de transformação Model Driven Architecture (MDA) é aplicada, a qual define a modelagem como ponto central no desenvolvimento de sis-temas, permitindo que os modelos sejam criados desconsiderando limitações referente à
plata-forma em que o sistema será criado e permitindo uma modelagem focada em seu domínio de implementação.
Apesar da transformação de modelos de negócio para modelos de sistema ser algo já abordado em outras publicações, como em Rhazali, Hadi e Mouloudi (2016), Rodríguez et al. (2010) e Heredia (2012), a transformação não é realizada de um diagrama de processos de negó-cio diretamente para um diagrama de classes. A transformação mais recorrente encontrada em publicações é a transformação de diagramas de processos de negócio para diagramas de casos de uso ou diagrama de atividades, e partir destes são gerados os demais modelos, como o diagrama de classes. Em razão disso, o processo de transformação pode ser tornar lento e dispendioso para que se obtenha o modelo final do diagrama de classes do sistema. Em outros trabalhos não ocorre a formalização do processo de transformação ou então o modelo de destino da trans-formação não é o diagrama de classes, tendo como modelo final do processo de transtrans-formação outros diagramas da UML, tais como: diagrama de máquina de estados, diagrama de pacotes, diagrama de colaboração, entre outros, tornando necessária a expansão dos modelos para que se obtenha o diagrama de classes.
Com este objetivo, este trabalho propõs o método de transformação TMBC para pos-sibilitar a transformação de modelos de negócio utilizando a BPMN, para modelos de sistema, criados por meio do diagrama de classes, utilizando a notação UML. A transformação direta en-tre estes dois modelos permite agilizar o processo de desenvolvimento, em razão de possibilitar a definição de classes de análise sem a necessidade da transformação prévia em outros modelos de sistemas e também garante mais confiabilidade ao processo com a aplicação da formalização por meio da utilização de uma linguagem de transformação de modelos.
O método TMBC foi estruturado em quatro fases distintas, que são executadas de forma sequencial e que constituem um processo iterativo, ou seja, caso necessário é possível realizar al-terações em fases anteriores do processo, o que permite que estes sejam readequados caso novos elementos sejam inseridos no processo de transformação. A estrutura do método é constituído por quatro fases distintas, que são: identificação dos elementos dos modelos de origem e destino; identificação de similaridades e restrições dos modelos; criação das regras de transformação e formalização das regras de transformação através da Atlas Transformation Language (ATL). A linguagem ATL foi utilizada em razão desta permitir a criação de relacionamentos padronizados e a aplicação de um processo de formalização que permitiu a geração automática da estrutura do modelo final.
Para verificar a funcionalidade do método, o processo de transformação foi aplicado em três estudos de caso distintos e os resultados obtidos foram utilizados para identificação dos pontos de destaque do método, além de permitir a criação de um comparativo com outros trabalhos presentes na literatura para identificação dos pontos divergentes entre cada um deles.
1.1 OBJETIVO GERAL
Criar um método de transformação de modelos processos de negócio para diagramas de classes de análise aplicando a arquitetura de transformação de modelos MDA e a formalização dos processos por meio da ATL.
1.2 OBJETIVOS ESPECÍFICOS
Os objetivos específicos definidos para a realização deste trabalho são:
∙ Realizar um mapeamento sistemático para identificar publicações que contenham métodos relacionados à transformação de modelos BPMN para modelos de sistema em UML. ∙ Identificar a funcionalidade dos elementos dos metamodelos da BPMN e da UML.
∙ Implementar as regras de transformação na ATL.
∙ Aplicar o método de transformação proposto em estudos de caso e analisar os resultados obtidos.
1.3 JUSTIFICATIVA
Para as empresas que desejam agilidade na execução de seus processos, a construção de sistemas automatizados é fundamental. No entanto, nem sempre os modelos de sistemas são criados de forma correta, o que resulta em sistemas inacabados ou ineficientes em relação ao cumprimento de sua finalidade.
Para melhorar esta construção, a modelagem de processos de negócio é essencial, pois serve como base para a identificação de requisitos de um sistema. O processo de criação de mo-delos de sistemas por meio da modelagem de processos de negócio pode se tornar um processo difícil, pois diferentes notações são utilizadas na construção de cada modelo e consequente-mente nem todos os elementos possuem funções equivalentes entre os modelos. Com o objetivo de padronizar este processo, diferentes métodos de transformação são propostos e linguagens de transformação de modelos como a ATL são utilizadas, o que pode ser observado nos trabalhos de Castro, Marcos e Vara (2011), Fabra et al. (2012) e Rhazali, Hadi e Mouloudi (2016).
Métodos de transformações de modelos são criados com o intuito de facilitar a transição e aplicação de uma visão mais ampla que um modelo inicial proporciona, para uma visão mais específica, a qual possa ser aplicada posteriormente para diferentes fins.
Os métodos de transformação de modelos propostos na literatura geralmente não rea-lizam a transformação de modelos de negócio criados na BPMN diretamente para modelos de classes de análise criados utilizando a UML, e quando realizam, não é aplicada uma lingua-gem de transformação de modelos para a formalização do processo. O fato de não haver uma transformação direta entre o modelo BPMN e o diagrama de classes também afeta o tempo de transformação para se obter este modelo, uma vez que é necessário realizar a transformação do BPMN para outros diagramas, como o diagrama de casos de uso ou diagrama de atividades, para que a partir destes seja obtido o diagrama de classes. Outro problema observado é a quanti-dade reduzida de elementos que são transformados, sendo que, muitos dos elementos do BPMN poderiam ser transformados em elementos do diagrama de classes, mas são descartados durante as etapas do processo.
Com isso o método proposto neste trabalho tem por objetivo criar uma transformação direta entre os dois modelos, utilizar uma quantidade maior de elementos no processo de trans-formação, permitir agilidade na geração do modelo de classes de análise e aplicar um processo de formalização na transformação para evitar que erros de interpretação possam ocorrer por parte de um analista ao realizar a transformação de um modelo ao outro de forma totalmente manual.
1.4 ORGANIZAÇÃO DO TRABALHO
Este trabalho é constituído pelos seguintes capítulos: capítulo 1, com a introdução, ob-jetivos e justificativa do trabalho. No capítulo 2, são definidos os conceitos sobre os modelos de negócios, modelos de análise, arquiteturas e linguagens utilizadas na transformações de mode-los. No capítulo 3 é realizado um mapeamento sistemático para a identificação de trabalhos que contêm métodos de transformação de modelos de negócio em BPMN para modelos de sistema em UML. O capítulo 4 apresenta as fases do método de transformação TMBC e o capítulo 5 exibe os resultados obtidos por meio da aplicação do método TMBC em diferentes estudos de caso.
2 REFERENCIAL TEÓRICO
A realização da modelagem de processos possibilita uma uniformização do entendi-mento da forma de trabalho, auxiliando na definição do fluxo de informações e na decisão de processos críticos da organização (VERNADAT, 1996). Uma das finalidades da modelagem de processos é expressar de forma clara e objetiva as atividades realizadas pelos envolvidos no processo dentro de uma ou mais organizações para que isto seja aplicado em sistemas de geren-ciamento.
Este capítulo tem por objetivo identificar os elementos das notações BPMN e Unified
Modeling Language(UML), utilizadas para a modelagem dos processos, além de descrever os
conceitos referentes a arquitetura e linguagem utilizadas na transformação dos modelos.
A seção 2.1 apresenta a definição de modelos de negócio e a descrição dos elementos da BPMN. A seção 2.2 descreve os modelos de análise, juntamente com as características do Diagrama de Classes da UML, notação selecionada para a realização dos modelos de análise. A seção 2.3 explana sobre os conceitos da transformação de modelos, a arquitetura MDA e a linguagem de transformação ATL. Na seção 2.4 são apresentadas as considerações finais obtidas por meio da produção deste capítulo.
2.1 MODELOS DE PROCESSOS DE NEGÓCIO (BPMN)
A gestão de processos de negócio abrange conceitos e métodos que representam as funções e restrições de cada atividade dentro de uma organização. Por meio do gerenciamento administrativo, aplicam-se técnicas de controle que permitem uma melhor análise e aprimora-mento dos processos (WESKE, 2007).
O profissional que realiza esta modelagem é o analista de negócio, o qual tem como objetivo avaliar, identificar e documentar as etapas que ocorrem dentro de uma organização, para que seja possível gerar um modelo que auxilie na tomada de decisão e gestão de uma empresa (HEREDIA, 2012). A modelagem de processos de negócio é importante para o entendimento dos requisitos de um sistema e estas modelagens são montadas a partir de padrões de notações gráficas.
Nos trabalhos de produção científica, diversos tipos de notações são abordadas e para identificar as mais utilizadas, foi realizado um mapeamento sistemático apresentado no Capítulo 3, com o objetivo de apontar as notações que foram utilizadas com mais frequência em trabalhos publicados. Dentre os destaques estão: a Semantics Of Business Vocabulary And Rules (SBVR), a UML por meio do diagrama de atividades e a Business Process Model and Notation (BPMN). Considerando estes modelos, destaca-se o fato de que todos pertencem a Object
internacional exercem. As três notações são reconhecidas e estabelecidas no meio acadêmico, no entanto, para a realização deste trabalho, a notação BPMN foi a escolhida, em razão desta notação aparecer em uma maior quantidade de trabalhos publicados nos últimos anos.
A BPMN foi proposta inicialmente em 2004 pela Business Process Management
Ini-tiative (BPMI) e em 2005 passou a ser mantida pelo OMG, após as duas organizações serem
fundidas. A partir disso, consolidou-se como padrão da indústria, tornando-se uma das princi-pais notações utilizadas para desenho dos processos de negócio (HARMON, 2010).
A BPMN provê uma notação gráfica que possibilita a criação de modelos de processos de negócio. Nestes modelos são abordados os fluxos dos processos de negócio, coordenando sua sequência de execução e controlando as mensagens que percorrem os diferentes processos, permitindo que os mesmos possam ser visualizados e entendidos por todas as partes envolvidas (OMG, 2018c).
A criação dos diagramas e dos elementos da BPMN exibidos neste trabalho foram re-alizados por meio do programa Bizagi Modeler versão 3.1.0.011, o qual segue o padrão da documentação oficial definida em OMG (2014a), a qual está em sua versão 2.0.2. No entanto, este software pode apresentar algumas variações na forma ou coloração dos seus elementos, mas que não afetam a sua compreensão.
Os elementos de um modelo e seus respectivos relacionamentos são definidos por meio de seu metamodelo, o qual serve como referência para determinar a estrutura que o modelo possuirá representando um modelo para criar modelos. O metamodelo utilizado para a definição dos elementos da BPMN é exibido na Figura 1.
Figura 1 – Metamodelo da BPMN
Fonte: Adaptado de (OMG, 2018a)
Os elementos deste metamodelo derivam do elemento principal objeto gráfico e destes descendem quatro categorias principais: objetos de fluxo; objetos de conexão; partições e arte-fatos. No metamodelo essas quatro categorias aparecem representadas como classes abstratas. Estas classes auxiliam na identificação dos elementos envolvidos nas transformações de cada modelo (OMG, 2014a).
2.1.1 Objetos de Fluxo
Os objetos de fluxo definem o caminho e a sequência de execução dos processos e são divididos em três tipos: atividades, potais e eventos (OMG, 2014a).
Uma atividade descreve um trabalho realizado dentro da organização e pode ser execu-tado tanto por uma pessoa como por um setor. A atividade pode ter duas especificações: atômica ou complexa. Caso a atividade seja atômica, ela representa uma tarefa que não pode ser subdi-vidida. A BPMN apresenta diferentes tipos de tarefas, dentre as quais se destacam: i) tarefas manuais, que representam ações que não necessitam o uso de uma aplicação, como atender um
telefonema; ii) tarefas de usuário, que representam ações realizadas com o auxílio de uma aplica-ção ou sistema; iii) tarefas de serviço, que representam a execuaplica-ção de um serviço automatizado, como um WebService. Se a atividade for do tipo complexa, ela pode ser subdividida em diversas outras atividades, representando então um subprocesso (WHITE; MIERS, 2008).
As atividades são representadas no diagrama BPMN através de um retângulo com as bordas arredondadas. Os símbolos utilizados para atividades do tipo tarefa e atividades do tipo subprocesso são representados na Figura 2.
Figura 2 – Representação de Atividades na BPMN
Fonte: Adaptado de (OMG, 2014a)
Outro objeto de fluxo existente na BPMN é o portal, também conhecido como gateway, que é utilizado para controlar o fluxo do processo e pode convergir ou divergir ao longo da sua execução (OMG, 2014a).
Um portal é um elemento não-obrigatório no processo. Caso o fluxo não necessite ser controlado não se faz necessária a utilização de um portal. Na BPMN o mesmo tipo de portal é usado tanto para dividir como para unir o fluxo do processo (OMG, 2014a).
A BPMN apresenta seis tipos de portais: exclusivo, inclusivo, exclusivo baseado em eventos, paralelo, paralelo baseado em eventos e complexo.
Um portal exclusivo divide o fluxo em dois ou mais fluxos, cada um deles com uma condição específica. Quando um processo chega à este portal, uma condição é verificada e o processo segue o caminho que resultar verdadeiro, ignorando os demais. Caso nenhuma condi-ção seja verdadeira, é possível definir um caminho padrão a ser tomado nestas situações.
O portal inclusivo é semelhante ao exclusivo, sendo que a diferença é que dois ou mais caminhos podem ser seguidos, dando origem aos fluxos paralelos. Uma vez que um portal inclu-sivo tenha dividido o fluxo, outro portal incluinclu-sivo deve ser usado para unir o mesmo novamente. O portal permanece aguardando até que todos os fluxos sejam finalizados.
Um portal exclusivo baseado em eventos é semelhante a um portal exclusivo porque ambos envolvem apenas um caminho no fluxo. A diferença é que no caso de um portal baseado
em eventos se avalia qual evento ocorreu e não qual condição está sendo atendida, podendo este variar durante a execução do fluxo conforme um evento é ativado.
O portal paralelo, assim como o inclusivo, é utilizado para dividir o fluxo em vários flu-xos paralelos e para sincronizar os mesmos posteriormente. A principal diferença é que o portal paralelo não avalia nenhuma condição, ou seja, todos os fluxos são executados simultaneamente, independentemente da quantidade de fluxos.
O portal paralelo baseado em eventos, como o próprio nome afirma, é similar à um portal paralelo, ou seja, ele permite que vários processos aconteçam ao mesmo tempo, com a diferença que os processos dependem de eventos específicos para serem ativados.
Por último, o portal complexo é usado apenas em casos específicos em que não há a possibilidade de descrever os problemas por meio dos fluxos mais simples. Utilizado quando vários portais são necessários para descrever um fluxo de negócio. A criação de textos descritivos também devem ser realizadas, pois a utilização de palavras ao invés de apenas símbolos auxiliam na compreensão do processo.
Os diferentes tipos de portais são representados na Figura 3 e seguem a ordem na qual foram explicados.
Figura 3 – Tipos de Portais da BPMN
Fonte: Adaptado de (OMG, 2014a)
O próximo objeto de fluxo é o evento que representa algo que ocorre no início, meio ou final de um processo. Pode simular a chegada de uma mensagem ou um determinado tempo transcorrido. Os eventos podem ser de três tipos: início, intermediários e final (OMG, 2014a)
Eventos de início são usados para indicar o início de um processo e podem ser de dife-rentes tipos, tais como: sem causa especificada, temporal e condicional. Quando nenhuma causa é especificada o evento de início representa apenas o ponto de início do processo. Um evento
temporal pode indicar que o mesmo só inicia quando uma data ou hora específica for atingida ou quando um ciclo de tempo for completado. O evento condicional possui uma condição de negócio associada ao mesmo.
O evento intermediário ocorre entre o início e o final do processo e assim como os eventos de início podem ser de diferentes tipos, como por exemplo, evento temporal. Um evento intermediário pode estar localizado no fluxo do processo ou anexado a uma tarefa.
Por último, o evento final representa o final do processo e é opcional, podendo o dia-grama ter nenhum, um, ou vários eventos de final.
A Figura 4 apresenta os símbolos utilizados para os diferentes tipos de eventos expli-cados anteriormente.
Figura 4 – Tipos de Eventos da BPMN
Fonte: Adaptado de (OMG, 2014a)
Por meio da definição dos objetos de fluxo é possível descrever as operações realizadas em um diagrama de processos de negócio, no entanto, para especificar a ordem de execução e o tipo de relação que cada processo apresenta entre si, é necessário utilizar os objetos de conexão.
2.1.2 Objetos de Conexão
Os objetos de conexão são utilizados para conectar os diferentes elementos do modelo e podem ser de três tipos: fluxo de sequência, fluxo de mensagem e associação (OMG, 2014a).
Um fluxo de sequência representa a ordem em que as atividades serão executadas no processo. O fluxo de mensagem é usado para mostrar a troca de mensagens entre participantes do processo. Utilizado apenas em casos que o modelo possua mais de uma piscina. O objeto de associação é utilizado para associar os artefatos aos objetos do fluxo, indicando a qual se referem. A Figura 5 exibe os três tipos de conexões.
Figura 5 – Tipos de Objetos de Conexão da BPMN
Fonte: Adaptado de (OMG, 2014a)
Os objetos de conexão interligam os objetos de fluxo e estes por sua vez estão contidos em partições, divididos em piscinas e raias.
2.1.3 Partições (Swinlanes)
As partições são usadas para organizar as atividades dentro do modelo. A BPMN possui dois tipos de partições: Participante (Pool) e Raia (Lane) (OMG, 2014a).
Uma piscina representa um participante do processo, geralmente associado a um sis-tema ou até mesmo a empresa. Modelos que possuam mais de uma piscina geralmente são en-contrados em processos de negócio de empresas para empresas, ou na comunicação de sistemas de integração.
As raias são partes de uma piscina e são utilizadas para representar diferentes categorias dentro de um participante. Geralmente são usadas para indicar papéis da organização, podendo ser tanto um operador do sistema, por exemplo, como também representar um setor inteiro, como a expedição. Os símbolos usados para a piscina e para a raia são apresentados na Figura 6.
Figura 6 – Tipos de Partições da BPMN
Fonte: Adaptado de (OMG, 2014a)
Com as partições criadas e a estrutura dos processos finalizadas, artefatos podem ser adicionados ao diagrama para incrementar informações ao modelo.
2.1.4 Artefatos
Os artefatos documentam o modelo, adicionando informações extras ao diagrama BPMN que não interferem em seu fluxo do processo (OMG, 2014a). A BPMN apresenta alguns tipos pré-definidos de artefatos, como o objeto de dados, anotação e grupo.
Um objeto de dados representa os dados gerados ou utilizados por algum elemento do processo, podendo este ser um documento eletrônico ou não. O objeto de dados é ligado ao elemento do processo através de uma associação.
Anotações são utilizadas para adicionar um comentário a um elemento do processo, acrescentando explicações mais detalhadas à alguma parte do modelo.
O grupo é constituído pela união de diversas atividades ou outros elementos do pro-cesso. Este grupo representa o escopo que a execução de uma tarefa engloba. A BPMN não define uma semântica associada ao grupo, sendo utilizado apenas para fins de visualização no diagrama. A Figura 7 apresenta os símbolos usados para os artefatos da BPMN.
Figura 7 – Tipos de Artefatos da BPMN
Fonte: Adaptado de (OMG, 2014a)
Por meio da utilização dos elementos da notação BPMN é possível fazer a análise dos diagramas de processos de negócio, o que possibilita a extração das informações que serão essen-ciais no processo de transformação de modelos e no seu correto relacionamento com o modelo de análise.
A partir da definição do modelo de processos de negócio, é possível realizar a automati-zação que permite maior rapidez na conclusão das tarefas e consequentemente uma diminuição nas falhas de execução. Para isto é necessário que haja o desenvolvimento de um sistema de informação, o qual possuirá como base um modelo que definirá a estrutura do projeto deste sistema.
2.2 MODELOS DE ANÁLISE (DIAGRAMA DE CLASSES)
Como forma de descrição da importância da realização da modelagem de sistemas, é possível observar que:
Por mais simples que um sistema seja, todo e qualquer sistema deve ser mo-delado antes de se iniciar a sua implementação, entre outras coisas, porque os sistemas de informação frequentemente costumam possuir a propriedade de “crescer”, isto é, aumentar em tamanho, complexidade e abrangência. (GUEDES, 2011, p. 7)
Um sistema de informação precisa de uma documentação detalhada, que possa ser atu-alizada e mantida com facilidade e rapidez, que permita realizar correções sem produzir novos erros (GUEDES, 2011).
Esta documentação, juntamente com a modelagem, é definida pelo analista de sistemas, o qual é responsável por analisar e documentar os requisitos do sistema. O trabalho pode ser realizado de forma conjunta com o analista de negócios, o qual passa a fornecer informações primordiais para a identificação do fluxo e das ligações entre diversos processos organizacionais (HARMON, 2010).
Esses dois profissionais, entretanto, utilizam diferentes métodos para realizar essas ta-refas, tais como notações e linguagens distintas para a criação de seus modelos. No caso da modelagem de sistemas, o padrão utilizado para projetos orientado à objetos é a Unified
Mode-ling Language(UML). Sua documentação é definida em (OMG, 2017) e atualmente está em sua
versão 2.5.1.
Os diagramas da UML são separados por duas grandes categorias: os diagramas de estruturas e os de comportamentos (OMG, 2017). Dentro destas categorias existem diversos outros diagramas, como é possível verificar na Figura 8.
Figura 8 – Diagramas da UML
Fonte: Adaptado de (OMG, 2017)
Dentre os diagramas da UML, o escolhido para a aplicação do método proposto por este trabalho foi o diagrama de classes. Esta decisão foi tomada considerando os resultados obtidos no mapemanto sistemático descrito no Capítulo 3. Nesta revisão, foi perceptível uma maior utilização do diagrama de classes, o que indica que este foi selecionado como diagrama final no processo de transformação mais vezes do que os demais diagramas, mesmo em trabalhos onde eram exigidas primeiramente as transformações em outros modelos inicialmente, para que a partir destes, o diagrama de classes fosse obtido.
Outros fatores que contribuíram para esta decisão foram as afirmações existentes nos trabalhos de Rumbaugh, Jacobson e Booch (1998) e Rumbaugh, Jacobson e Booch (2005), cri-adores da UML, os quais definem a importância do diagrama de classes, caracterizando-o como o mais comum e também o mais importante diagrama encontrado na modelagem orientada a objetos, servindo não somente para a realização da documentação estrutural do sistema, mas também para a construção de sistemas executáveis de engenharia direta e reversa.
O diagrama de classes pode servir como base para a construção da maior parte dos demais modelos. Seu objetivo principal é permitir a visualização das classes que compõe o sistema e proporcionar uma visão estática de como estão organizadas e definidas suas estruturas lógicas (GUEDES, 2011).
A construção do diagrama pode ter três perspectivas diferentes: modelagem de voca-bulário do sistema, de colaboração ou de esquemas. A abstração de cada classe juntamente com seus atributos e métodos, que definem as classes que farão parte do diagrama, correspondem à modelagem de vocabulário do sistema. A definição do relacionamento e colaboração entre as classes para a execução de um determinado processo, corresponde à modelagem de colaboração. A construção de uma estrutura de dados lógicos, utilizados para a formação da base de dados, corresponde à modelagem de esquemas (RUMBAUGH; JACOBSON; BOOCH, 2000).
Para a construção do modelo de sistema que apresenta a estrutura das classes, atributos, métodos e associações é necessário utilizar o metamodelo que será utilizado como referência para a criação deste modelo. Neste caso, o modelo utilizado é o diagrama de classes que é baseado no metamodelo da UML, o qual é apresentado na Figura 9.
Figura 9 – Metamodelo da UML
Fonte: Adaptado de (KLEPPE; WARMER; BAST, 2003)
Com o objetivo de simplificar o metamodelo da UML, o qual envolve também elemen-tos de outros modelos não abordados neste método, o mesmo passou por uma simplificação para exibir apenas elementos relacionados ao modelo de destino da transformação que é o diagrama de classes.
Para realizar o processo de criação de diagramas de classe são utilizados alguns ele-mentos gráficos, juntamente com características descritivas que estão divididos em: classes, re-lacionamentos e estereótipos.
2.2.1 Classes
A estrutura principal do diagrama é composta por classes que se comunicam por meio de associações. A classe pode representar um objeto ou um conjunto de objetos que
comparti-lham uma estrutura e comportamento comum. Uma classe é representada como um retângulo com até três divisões, que são identificadas nesta sequência: descrição, atributos e operações (OMG, 2014a). Estas divisões tem por objetivo definir as seguintes características da classe:
∙ Descrição: identifica o nome da classe e atribui esterótipos quando necessário para indicar funções da classe que são diferentes das demais.
∙ Atributos: representam as características do objeto, descrevendo quais propriedades que o mesmo possui. Cada atributo da classe é exibido em uma linha separada e será relacionado à um tipo de dado.
∙ Operações: são exibidos em formato de lista, com cada operação representando as ações que um objeto pode realizar. Os métodos podem executar funções que recebam valores como parâmetros e retornem valores como resultados. Estes valores podem ser de dife-rentes tipos de dados.
A figura 10 representa a notação da estrutura básica de uma classe.
Figura 10 – Notação UML para Representação da Classe
Fonte: Adaptado de (OMG, 2017)
Em algumas representações do diagrama, uma classe não obrigatoriamente precisa apresentar as três divisões, pois podem haver classes que não contenham atributos ou que não contenham operações, ou ainda seus atributos e operações podem ser ocultados com o objetivo de tornar o diagrama menos poluído.
Como característica adicional, em frente aos atributos e métodos podem existir dife-rentes símbolos, os quais indicam os tipos e níveis de acesso, tais como: público (+), em que todas as demais classes possuem acesso livre, privado (−), fornecendo acesso somente à própria classe, protegido (#), permitindo o acesso da classe de origem e seus descentes e de pacote (∼), onde somente as classes que estiverem no mesmo pacote terão acesso.
2.2.2 Relacionamentos entre Classes
Geralmente uma classe não é criada sem que esta possua relacionamento com outras. Em sistemas complexos em que existem diversas abstrações de classes, os relacionamentos tornam-se fundamentais para que seja possível identificar onde cada classe acessará as infor-mações de que precisa (RUMBAUGH; JACOBSON; BOOCH, 2005).
Dentre as informações presentes nos tipos de relacionamento entre as classes, é pos-sível perceber algumas informações adicionais, que são numerações que representam a mul-tiplicidade. Esta multiplicidade indica o número mínimo e máximo de objetos envolvidos em cada extremidade da associação, além de permitir especificar o nível de dependência de um ob-jeto para com os outros envolvidos na associação. As características destes relacionamentos são apresentados no Quadro 1.
Quadro 1 – Exemplos de Multiplicidade
Multiplicidade Significado
0.. 1 No mínimo zero e no máximo um. Indica que os objetos das classes as-sociadas não precisam obrigatoriamente estar relacionados, mas se houver relacionamento indica que apenas uma instância da classe relaciona-se com as instâncias da outra classe
1.. 1 Um e somente um. Indica que apenas um objeto da classe relaciona-se com os objetos da outra classe.
0.. * No mínimo nenhum e no máximo muitos. Indica que pode ou não haver instâncias da classe participando do relacionamento.
* Muitos. Indica que muitos objetos da classe estão envolvidos na associação. 1.. * No mínimo um e no máximo muitos. Indica que há pelo menos um objeto
envolvido no relacionamento, podendo haver muitos objetos envolvidos. 3.. 5 No mínimo três e no máximo cinco. Estabelece que existem pelo menos três
instâncias envolvidas no relacionamento e que podem ser quatro ou cinco as instâncias envolvidas, mas não mais do que isso.
Fonte: (GUEDES, 2011)
O relacionamento entre as classes definem diferentes tipos de comunicações, sendo estas separadas em sete tipos: associação, agregação, composição, generalização, classe associ-ativa, dependência e realização.
2.2.2.1 Associação
Uma associação descreve um vínculo que ocorre entre os objetos de uma ou mais clas-ses, estabelecendo entre elas um relacionamento simples de comunicação, onde os objetos de uma classe se relacionam com os objetos da outra classe.. As associações são representadas por linhas contínuas que ligam uma classe à outra.
Figura 11 – Exemplo de Relacionamento de Associação
Fonte: Adaptado de (OMG, 2017)
Neste exemplo, é estabelecido um relacionamento do tipo associação entre os objetos pessoa e companhia.
2.2.2.2 Agregação
Agregação representa um tipo especial de associação em que as informações de um objeto, considerado objeto-todo, precisa ser complementada pelas informações contidas em um objeto de outra classe, considerado o objeto-parte. Este tipo de associação tem por objetivo estabelecer uma relação todo/parte entre os objetos associados. Apesar desta relação, os objetos-parte continuam existindo mesmo que o objeto-todo seja destruído.
O símbolo utilizado na agregação é similar à associação, com a diferença que contém um losango na extremidade da classe que representa o todo. Um exemplo deste relacionamento é exibido na Figura 12.
Figura 12 – Exemplo de Relacionamento de Agregação
Fonte: Adaptado de (RUMBAUGH; JACOBSON; BOOCH, 2005)
Neste exemplo, os objetos endereço e mensagem são agregados ao objeto email e con-tinuam existindo mesmo que o objeto email seja destruído.
2.2.2.3 Composição
A composição representa uma relação similar à agregação, ou seja, continua existindo uma relação todo/parte entre os objetos. A diferença é que em uma composição o vínculo é mais forte, fazendo com que caso um objeto-todo seja destruído, consequentemente os objetos-parte ligados a ele também são destruídos.
O símbolo de composição diferencia-se graficamente do símbolo de agregação por uti-lizar um losando preenchido. O losango deve ficar ao lado do objeto todo. A Figura 13 apresenta um exemplo da relação de composição entre as classes.
Figura 13 – Exemplo de Relacionamento de Composição
Fonte: Adaptado de (OMG, 2017)
2.2.2.4 Generalização
Generalização é um relacionamento entre uma classe geral (conhecida como super-classe ou super-classe-pai) e uma super-classe mais específica (chamada de subsuper-classe ou super-classe-filha). Este tipo de relação estabelece uma característica de herança da classe-filha para a classe-pai, o que permite com que uma subclasse possa herdar toda a estrutura de uma superclasse, podendo in-clusive adicionar novas estruturas e comportamentos (RUMBAUGH; JACOBSON; BOOCH, 1998).
Sua aplicação é encontrada geralmente quando existem duas ou mais classes com ca-racterísticas muito semelhantes. Com isso, para evitar declarações duplicadas de atributos ou métodos, é criada uma classe geral que declara estes atributos e métodos comuns a todas as classes envolvidas no processo. A partir disso, as classes especializadas são ligadas à classe geral.
A generalização é representada por uma linha sólida com uma seta triangular na ponta, indo sem das subclasses em direção à superclasse. A representação deste relacionamento pode ser observado na Figura 14.
2.2.2.5 Classe Associativa
Classes associativas são utilizadas quando ocorrem associações que tenham multipli-cidade muitos (*) em todas as suas extremidades. Uma classe associativa representa uma asso-ciação ao mesmo tempo que é uma classe.
Uma classe associativa é necessária quando os atributos relacionados à associação não podem ser armazenados por nenhuma das classes envolvidas. Por esta razão, sua instância possui
Figura 14 – Exemplo de Generalização
Fonte: Adaptado de (RUMBAUGH; JACOBSON; BOOCH, 2005)
valores nos seus atributos que são referências para os demais objetos que estão ligados à ela (RUMBAUGH; JACOBSON; BOOCH, 2005).
Um exemplo de sua aplicação é exibido por meio da Figura 15.
Figura 15 – Exemplo de Classe Associativa
Fonte: Adaptado de (RUMBAUGH; JACOBSON; BOOCH, 2005)
2.2.2.6 Dependência
Um relacionamento de dependência existe quando uma classe independente possui ou-tras classes dependentes ligadas à ela. Isso significa que a mudança nos elementos da classe independente interferem nas demais classes dependentes. Isto ocorre geralmente quando uma classe recebe um objeto de outra classe como parâmetro, fazendo com que uma mudança no elemento independente afete o modelo dependente.
Uma relação de dependência é simbolizada por uma linha tracejada e a navegação é em direção à classe independente. Alguns estereótipos também podem ser utilizados no relaciona-mento para explicitar o tipo de dependência. A representação desta relação pode ser observada por meio da Figura 16.
Figura 16 – Exemplo de Relacionamento de Dependência
Fonte: Adaptado de (RUMBAUGH; JACOBSON; BOOCH, 2005)
2.2.2.7 Realização
A realização possui características dos relacionamento de generalização e de dependên-cia, pois herda o comportamento de uma classe, apesar de não herdar a sua estrutura, e também é utilizada para identificar classes responsáveis por executar funções para outras classes.
O relacionamento de realização é representada por uma linha tracejada contendo uma seta vazia que aponta para a classe, que tem uma ou mais funções que devem ser realizada por outra, enquanto que na outra extremidade da linha é definida a classe que realiza esse compor-tamento (GUEDES, 2011). O relacionamento de realização pode ser observado por meio da Figura 17.
Figura 17 – Exemplo de Relacionamento de Realização
2.2.3 Estereótipos
Estereótipos são utilizados para destacar determinados componentes do diagrama, dando ênfase em suas funções, que são diferentes dos demais.
É possível criar estereótipos particulares, variando conforme a função que o analista quiser dar aos componentes, no entanto, existem três estereótipos principais predefinidos na linguagem UML que são mais utilizados nos diagramas de classe. Estes esteriótipos são: entity,
boudarye control.
O estereótipo do tipo entity tem por objetivo explicitar que a classe é uma entidade, ou seja, que contém informações recebidas e armazenadas pelo sistema ou geradas por meio deste. Isto representa na maior parte dos casos, não sendo obrigatório, que a classe provavelmente precisará ter seus dados persistidos, ou seja, preservados e armazenados de alguma maneira, pois seus objetos terão um período de vida longo (GUEDES, 2011).
O estereótipo boundary, também conhecido como estereótipo de fronteira, representa uma classe que servirá de comunicação entre os atores externos e o sistema. Muitas vezes uma classe Boundary é associada à própria interface do sistema.
O estereótipo control é associado principalmente à classes intermediárias, que farão o controle de comunicação entre objetos boundary e as demais classes, como por exemplo, uma
entity, recebendo e gerenciando informações advindas da interface, como movimentos do mouse
o pressionamento de um botão e retransmitindo aos objetos das classes de entidade que compõem o sistema.
Estereótipos podem ser representados de formas diferentes, podendo ser definidos no topo da classe, aparecendo em destaque com o texto escrito dentro dos símbolos « e », ou então por meio de símbolos. Alguns estereótipos podem ser representados de forma gráfica ao invés do formato tradicional da classe. Seu desenho é modificado e seus atributos e métodos são oculta-dos. Este tipo de representação geralmente é utilizado em diagramas grandes, por exibir a classe de uma forma mais simplificada, facilitando assim a sua interpretação.
Figura 18 – Tipos de Notações de Estereótipos na UML
Fonte: Adaptado de (RUMBAUGH; JACOBSON; BOOCH, 2005)
Por meio da utilização dos elementos da notação UML é possível fazer a construção dos modelos de análise, os quais são fundamentais para que o analista consiga extrair as informações essenciais que serão complementadas e adaptadas conforme a plataforma em que o sistema será desenvolvido.
2.3 TRANSFORMAÇÃO DE MODELOS
A modelagem fundamentada em processos de negócio e de sistema são realizadas, res-pectivamente, pelo analista de negócio e o de sistema. Estes profissionais utilizam notações e linguagens diferentes na construção dos seus modelos, o que ocasiona dificuldades na interpre-tação ao realizar a transformação de um modelo para o outro (ODEH; KAMM, 2003). Para estabelecer esta transição entre modelos, diversos métodos de transformação são propostos na literatura.
O conceito de transformação é utilizado em diferentes contextos na engenharia de soft-ware, no entanto, de acordo com Mens e Gorp (2006) todo tipo de transformação pode ser clas-sificada conforme as seguintes características:
∙ Endógena e exógena: uma transformação é endógena quando o modelo de origem e des-tino compartilham do mesmo metamodelo. Quando os modelos utilizam metamodelos diferentes a transformação é considerada exógena.
∙ Horizontal e vertical: uma transformação é considerada horizontal quando os modelos envolvidos no processo de transformação estão no mesmo nível de abstração. Quando os
níveis de abstração são diferentes, a transformação é considerada vertical.
∙ Sintática e semântica: na transformação sintática ocorre a transformação direta de um ele-mento para outro, apenas transcrevendo seu nome. Por meio da transformação semântica ocorre também a análise do sentido que o elemento possui no modelo, podendo ocorrer variações na transformação de acordo com a apresentação do elemento.
O método proposto neste trabalho aborda um processo de transformação exógeno, ver-tical e semântico. Sua transformação ocorre a partir do modelo definido pela notação do BPMN, por meio do diagrama de processos de negócio, para a notação UML, por meio do diagrama de classes. A razão para a utilização destas notações estão definidas nas seções 2.1 e 2.2.
O processo de transformação proposto segue uma estrutura que define os passos de sua aplicação. Para a realização da transformação entre os modelos foi utilizada a arquitetura
Model-Driven Architecture(MDA), ou Arquitetura Dirigida por Modelos.
2.3.1 Model Driven Architecture(MDA)
A MDA consiste em uma arquitetura que define a criação de modelos como centro do processo de desenvolvimento. Os modelos são construídos a partir da definição dos processos organizacionais sem considerar limitações referentes à qualquer tecnologia ou sistema compu-tacional. Esta arquitetura tem como objetivo permitir uma melhor flexibilidade a longo prazo, pois é possível separar a especificação de operações de detalhes de implementação de uma de-terminada plataforma, o que facilita a realização de alterações nos modelos e consequentemente sua manutenibilidade (OMG, 2014b).
Esta arquitetura permite que sistemas sejam criados focando inicialmente na mode-lagem dos processos de negócio, sem que haja a necessidade de definir antecipadamente em qual linguagem o sistema será programado. Isto permite uma modelagem mais livre e focada na definição do domínio sem haver a preocupação com possíveis limitações da linguagem de programação.
A MDA é dividia em três níveis de modelos diferentes, os quais são: Computation
Independent Model (CIM), Plataform Independent Model (PIM) e o Plataform Specific Model
Figura 19 – Níveis da MDA
Fonte: Adaptado de (HARMON, 2010)
No nível CIM estão os modelos de processos de negócio, como por exemplo o BPMN, que ainda não possui detalhes da estrutura do sistema, mas possui características do domínio no qual será empregado. Neste nível, os modelos geralmente são criados por um analista de negócios e são construídos sem levar em consideração restrições de tecnologia, porém, partes de um modelo CIM podem ser suportados por um sistema e devem ser consideradas ao transformar um modelo CIM para um PIM (OMG, 2014b).
No nível PIM estão os modelos que são focados na operação de sistema, no entanto sem considerar detalhes específicos de qualquer plataforma. Estes modelos podem ser representados por exemplo, por um diagrama de classes, o qual se baseia em uma análise de nível mais elevado em relação ao modelo de negócio e são geralmente direcionados a identificar funcionalidades específicas do sistema, não se abstendo a detalhes de como serão implementadas. Estes modelos geralmente são criados por um analista de sistema (OMG, 2014b).
No nível PSM ocorre um aprimoramento do modelo PIM, havendo uma união do mo-delo conceitual com os detalhes que definem como o sistema se desenvolverá na plataforma
especificada. Neste nível o próprio diagrama de classes pode ser utilizado, havendo o acréscimo de requisitos referentes à conexão e a tecnologia utilizada, permitindo a visualização de como ocorrerá sua implementação. Diagramas adicionais da UML, como diagrama de máquina de es-tados ou diagrama de pacotes também podem ser utilizados, variando conforme a necessidade (OMG, 2014b).
A arquitetura MDA define que a transformação de modelos é o processo de conversão de um modelo para outro de um mesmo sistema. Este processo é composto pela criação de regras refinadas que transformam elementos de um metamodelo de origem para o de destino (OMG, 2014b). Esta estrutura é representada por meio da Figura 20.
Figura 20 – Esquema Geral de Transformação de Modelos
Fonte: Adaptado de (RODRíGUEZ et al., 2010)
As regras que envolvem o processo de transformação podem ser criadas de diversas formas, variando conforme a escolha do analista e do modelo que estiver aplicando para realizar o processo.
Algumas das formas propostas em trabalhos publicados podem ser observadas por meio da Seção 3.8 a qual apresenta processos de transformação que utilizam, por exemplo, um relaci-onamento simplificado entre os modelos de origem e destino, fazendo uma conversão direta dos elementos gráficos existentes entre os modelos. Outra forma, é a identificação dos elementos relacionados por meio de uma análise semântica que envolve um processo manual do analista
que está aplicando o processo de transformação. Utilização de mapas mentais e de diagramas de autoria própria também são utilizados, no entanto, a maior parte não ocorre de forma automática. Para que ocorra um processo que independa de interpretações do analista, faz-se neces-sário a utilização de uma linguagem própria para a transformação de modelos. Estas linguagens permitem criar uma especificação formal que possibilite a implementação de um processo au-tomatizado (OMG, 2016).
Existem diversas linguagens para especificação de transformação de modelos, as quais auxiliam a realização do processo, dando suporte à criação do correto relacionamento entre as especificações presentes em cada modelo.
Estas linguagens funcionam por meio da tipificação dos componentes de acordo com o metamodelo trabalhado, abstraindo desta forma as especificações das funcionalidades do sistema das relacionadas à plataforma tecnológica utilizada no desenvolvimento. Os modelos definidos inicialmente não tem nenhuma dependência quanto à plataforma de desenvolvimento, tendo como escopo apenas a lógica funcional do sistema (JOUAULT et al., 2008).
Conforme foi possível concluir por meio da realização do mapeamento sistemático e pelo resultado obtido no item 3.7, as linguagens mais utilizadas na literatura são a Atlas
Trans-formation Language (ATL) e a Query View Transformation (QVT). Ambas dão suporte para a
realização do processo de transformação de modelos, no entanto, baseado em Brambilla, Cabot e Wimmer (2017) e Jouault e Kurtev (2007), neste trabalho optou-se por utilizar a linguagem ATL em razão de apresentar uma arquitetura simplificada em relação a QVT e por aplicar transforma-ção unidirecional, do modelo de origem para o destino, ao contrário da QVT que é bidirecional, o que tornaria mais difícil o processo de criação do método, além de não corresponder totalmente com o objetivo proposto neste trabalho.
2.3.2 Atlas Transformation Language (ATL)
A Atlas Transformation Language (ATL) é um conjunto de ferramentas e uma lingua-gem de transformação de modelos, a qual provê meios para a criação de modelos de destino por meio da transformação de um conjunto de modelos de origem (ATL, 2019a).
A ATL foi desenvolvida pelo grupo de pesquisa ATLAS INRIA & LINA e foi inspirada a partir das recomendações do padrão QVT, além de se basear no formalismo da Object
Cons-traint Language (OCL), o que a torna uma linguagem híbrida, permitindo tanto programação
declarativa quanto imperativa (ATL, 2006).
Para realizar a construção de um modelo é necessário que este esteja de acordo com a semântica provida por seu metamodelo, que basicamente define os elementos que podem com-por o modelo. Da mesma forma, um metamodelo deve estar em conformidade com seu meta-metamodelo, o qual define os elementos do metamodelo. Isto constitui uma arquitetura de três
camadas (modelo, metamodelo e metametamodelo), sendo que o metametamodelo deve estar em conformidade com sua própria semântica de definição dos elementos, ou seja, tem que ser definido utilizando seus próprios conceitos. A ATL suporta duas tecnologias de metametamo-delos: o Managed Object Format (MOF), o qual é definido pela OMG e o Ecore, definido pelo
Eclipse Modeling Framework (EMF) (ATL, 2012).
A representação desta arquitetura de três camadas é exibida na Figura 21.
Figura 21 – Arquitetura ATL
Fonte: Adaptado de (ATL, 2012)
Esta representação resume o processo completo de transformação. O modelo Ma, que está em conformidade com o metamodelo MMa, é transformado no modelo Mb, o que está em conformidade com o metamodelo MMb. A transformação é definida pelo modelo de trasnforma-ção Mt, o qual está em conformidade com o metamodelo MMt. Todos os metamodelos, MMa,
MMbe MMt tem que estar em conformidade com o metametamodelo.
Na utilização do metametamodelo Ecore, os metamodelos podem ser criados por meio da notação textual via Kernel MetaMetaModel (KM3) ou então pelo editor gráfico Graphical
Modeling Project (GMP), ambos disponíveis no Integrated Development Environment (IDE)
Eclipse, o qual é o ambiente suportado pela ATL e que neste trabalho foi utilizada a versão Neon
3 release 4.6.3. Quanto aos modelos, tanto de origem quanto de destino, ambos são gerados em
XML Metadata Interchange (XMI), padrão da OMG para troca de informações baseadas em
Extensible Markup Language(XML) (ATL, 2012).
A partir da definição do metamodelo de origem e o metamodelo de destino, é necessário criar o modelo de origem que será transformado. O modelo de destino é obtido somente por meio do processo de transformação realizado com a aplicação das regras criadas na ATL. Um resumo
deste processo pode ser observado na Figura 22.
Figura 22 – Processo de Transformação do Modelo na ATL
Fonte: Autoria própria
Neste processo é possível perceber que após a definição dos metamodelos Ecore de origem e de destino, o modelo XMI de origem deve ser criado. Com esta estrutura estabelecida, as regras de transformação da ATL são criadas e após serem executadas devem gerar automati-camente o modelo XMI de destino.
A execução da ATL para a transformação dos modelos ocorre na ATL Virtual Machine, a qual é uma máquina virtual de computação abstrata. Esta máquina virtual é independente da linguagem de transformação ATL e é uma interpretadora de código de bytes que lida com OCL e com tipos de dados específicos da ATL (ATL, 2019b).
O estabelecimento das regras de transformação em ATL permite definir a quantidade de modelos de entrada e saída que serão gerados, além de especificar os elementos envolvidos na transformação juntamente com as características de relacionamento de cada elemento. As regras criadas em ATL seguem uma estrutura, a qual é definida pelos seguintes elementos: header,
import, helpers, rules.
O header, ou cabeçalho, define o nome da transformação e também o modelo de ori-gem e destino que serão utilizados e gerados com a transformação. O import é utilizado quando é necessário realizar a importação de uma biblioteca ATL. Os helpers, ou auxiliares, funcionam como a declaração de métodos, que posteriormente podem ser chamados durante a definição de uma regra. Por fim, as rules ou regras, constituem a parte central da estrutura e definem a trans-formação dos elementos do modelo de origem para os de destino, juntamente com característica específicas de cada regra de transformação (ATL, 2006).
Por meio destas características o processo de transformação é definido, o que permite tratar as restrições existentes entre os modelos de origem e destino para que ocorra a formaliza-ção do processo.
