Os modelos CIM e PIM são constituídos por diferentes elementos de entrada e saída. Por meio da análise destes elementos é possível identificar semelhanças existentes entre os mode- los, tanto em relação à sua estrutura quanto ao seu comportamento. A partir desta identificação, são criadas as regras de relacionamentos que definem como os elementos são transformados de um modelo para o outro.
Os modelos utilizados para a criação do CIM e do PIM, são os modelos BPMN e de diagrama de classes, respectivamente. Estes modelos apresentam diferenças em relação à sua estrutura de construção. Por esta razão, cada metamodelo e seus elementos são analisados se- manticamente para que os mesmos possam ser relacionados no processo de transformação.
Para criar este relacionamento, o método de transformação segue a arquitetura definida na ATL e sua consequente aplicação resulta na estrutura definida na Figura 26.
Figura 26 – Arquitetura ATL Aplicada ao Método de Transformação
Fonte: Autoria própria
A arquitetura ATL de três camadas aplicada ao método de transformação define a se- guinte estrutura: o metametamodelo é determinado pela tecnologia Ecore. Os metamodelos MMBPMN e MMUML são estabelecidos em conformidade com esta tecnologia. Os modelos MBPMN e MDiagramaClasses são criados em conformidade com os elementos delimitados em seus respectivos metamodelos. Para a criação das regras de transformação é utilizada a ATL que está em conformidade com o Ecore. A partir da ATL são criadas as regras de transforma- ção, a qual foi nomeada como BPMN2UML, que após ser executada realiza automaticamente a transformação do modelo MBPMN para o MDiagramaClasses.
A transformação proposta neste trabalho é do tipo exógena, pois os modelos de entrada e de saída utilizam diferentes metamodelos e consequentemente possuem estruturas de cons- trução diferentes. Com isso os elementos do modelo de origem são analisados para verificar a possibilidade de sua transformação para o modelo de destino.
Por meio desta análise são construídos os relacionamentos que são subdivididos de acordo com cada elemento transformado do modelo de origem para o de destino. Cada relaci- onamento é representado por uma regra que contém as orientações de transformação de cada elemento. Estas regras recebem a nomenclatura "R"seguido do número de sua identificação, o qual serve como referência para a descrição dos processos do método de transformação.
Para organizar as regras entre os modelos, foi criada uma estrutura que representa a ligação entre os elementos de entrada e saída. Esta estrutura é apresentada na Figura 27.
Figura 27 – Relacionamentos entre o Modelo BPMN e o Modelo de Diagrama de Classes
Fonte: Autoria própria
Do lado esquerdo são exibidos os elementos do modelo BPMN envolvidos no processo de transformação, enquanto que do lado direito ficam os elementos do diagrama de classes. Entre os dois modelos ficam as regras que estabelecem as transformações entre os elementos, as quais definem como um elemento do modelo de origem se transforma em um ou mais elementos do modelo de destino.
Para exemplificação da transformação de cada regra será utilizado trechos do estudo de caso 3 presente na seção 5.3, o qual foi criado exclusivamente para este trabalho para representar em um único modelo a transformação dos elementos de todas as regras abordadas neste método. Na regra R1 uma piscina do BPMN é transformada em uma classe do diagrama de clas- ses. Esta conclusão foi obtida em razão de uma piscina representar um participante do processo, o qual realiza tarefas que alteram o seu comportamento, podendo ser associado à uma classe. Uma piscina é o executor da ação, e em razão disso, a classe gerada nesta transformação recebe o estereótipo boundary e tem acrescido no início do seu nome o termo "IU", significando que é uma classe de fronteira e está representando uma interface de usuário. A relação entre estes dois elementos é exemplificada na Figura 28.
Figura 28 – Regra R1 - Transformação de Piscina para Classe
Fonte: Autoria própria
No relacionamento R2 uma raia do BPMN é transformada em uma classe do diagrama de classes. A raia pode representar diferentes papéis em uma organização, como um operador do sistema ou até mesmo um setor inteiro. Estes papéis possuem representação ativa no diagrama, pois podem exercer tarefas e ações, o que os caracteriza como classes no diagrama de classes. As classes geradas no processo passam por uma transformação similar ao que acontece na regra R1, ou seja, recebem o estereótipo boundary e tem seu nome precedido por "IU", representando uma classe de fronteira e consequentemente uma interface de usuário. As classes geradas no processo possuem um relacionamento de associação com a classe gerada pela transformação da piscina, mantendo a navegabilidade sempre em direção à classe gerada pela raia. A Figura 29 representa a transformação da regra R2.
Figura 29 – Regra R2 - Transformação de Raia para Classe
Fonte: Autoria própria
O relacionamento R3 define a transformação de um grupo do BPMN em uma classe do diagrama de classes. O grupo abrange um conjunto de tarefas responsáveis pela execução de uma função específica. O nome deste grupo se transforma em uma classe e mantém um relacio- namento de associação, o qual pode ser relacionado como prioridade à uma classe gerada pela regra R2, caso o grupo esteja contido em uma raia, ou então pela regra R1, caso o grupo não esteja contido em uma raia e esteja contido apenas em uma piscina. A navegabilidade do relacio- namento é sempre em direção da classe gerada pelo grupo. A representação desta transformação
pode ser observada na Figura 30.
Figura 30 – Relacionamentos R3 - Transformação de Grupo para Classe
Fonte: Autoria própria
O relacionamento R4 define a transformação de tarefas do BPMN em classes ou ope- rações no diagrama de classes. Uma tarefa descreve uma ação que pode ser executada dentro de uma organização e uma operação representa as ações que um objeto pode realizar. Em razão dos dois elementos possuírem similaridades em suas semânticas, os mesmos podem ser relacionados no processo de transformação.
Na transformação da tarefa para classe, o substantivo que está contido na descrição da tarefa dá o nome à classe. Esta classe tem um relacionamento de associação, o qual pode ser relacionada de três formas diferentes: i) com uma classe gerada pela regra R3, caso esteja contida em um grupo, ii) com uma classe gerada pela regra R2, caso não esteja contida em um grupo mas esteja contida em uma raia, iii) com a classe gerada pela regra R1, caso não esteja contida em um grupo ou uma raia, mas esteja contida em uma piscina. Para todos os relacionamentos de associação a navegabilidade é sempre em direção às classes geradas pelas tarefas, pois estas representam objetos que são instanciados pelas demais classes. Uma exceção a esta transformação ocorre quando esta tarefa antecede um portal exclusivo, em que acontecerá a geração de uma classe extra, a qual recebe o nome completo da tarefa, o estereótipo de interface e o relacionamento de agregação que possui a navegabilidade em direção à esta classe extra. Tarefas que estão contidas dentro de um portal exclusivo não são consideradas na regra, sendo transformadas apenas pela regra R5. A representação da transformação da regra R4 pode ser observada na Figura 31.
Figura 31 – Relacionamentos R4 - Transformação de Tarefa para Classe
Fonte: Autoria própria
Na transformação da tarefa para operação, a descrição integral da tarefa fornece nome à operação. Esta transformação terá dois comportamentos distintos, i) quando a tarefa está fora do grupo e ii) quando ela está dentro de um grupo.
Estas transformações funcionam da seguinte maneira: i) caso a tarefa esteja fora de um grupo, esta é transformada em uma operação que está contida na classe que foi gerada pelo substantivo desta tarefa, criada de acordo com o descrito no processo de transformação anterior. Esta classe possui um relacionamento com outra classe do tipo interface de usuário e é gerada uma operação adicional, que utiliza a descrição integral da tarefa para nomear a operação, mas
que tem seu nome precedido pela palavra "acao", que representa uma operação que chama a execução da outra operação que está contida na sua classe de relacionamento. A representação desta transformação é apresentada na Figura 32.
Figura 32 – Relacionamentos R4 - Transformação de Tarefa para Operação no Caso 1
Fonte: Autoria própria
Na situação ii) caso a tarefa esteja dentro de um grupo, então a operação estará contida dentro da classe originada pela transformação deste grupo, de acordo com a regra R3. A operação adicional representada pela precedência da palavra "acao"por sua vez, está contida na classe gerada pela raia de acordo com a regra R2, caso o grupo esteja em uma raia, ou então estará contida na classe gerada pela piscina de acordo com a regra R1, caso o grupo não esteja em uma raia e esteja apenas em uma piscina. A representação desta transformação é apresentada na Figura 33.
Figura 33 – Relacionamentos R4 - Transformação de Tarefa para Operação no Caso 2
Fonte: Autoria própria
O relacionamento R5 define a transformação de um portal exclusivo do BPMN para uma classe no diagrama de classes. Em um portal exclusivo a sequência de execução das tarefas é dividida em dois ou mais fluxos e apenas um caminho pode ser seguido. No diagrama de classe este elemento é transformado em classes da seguinte maneira: a descrição integral de cada tarefa contida dentro do portal dá origem à uma classe distinta e cada uma destas classes conterá uma operação que recebe o nome igual à descrição integral da tarefa que antecede este portal exclusivo. Além disso, as classes geradas possuirão um relacionamento do tipo realização com a classe formada por meio da exceção da regra R4, referente à criação adicional de classe quando uma tarefa antecede um portal. Estes relacionamentos tem navegabilidade sempre em direção à esta classe criada na regra R4, a qual receberá uma operação com a descrição integral da tarefa que antecede ao portal exclusivo. A representação desta transformação é exibida na Figura 34.
Figura 34 – Relacionamentos R5 - Transformação do Portal Exclusivo para Classe
Fonte: Autoria própria
No relacionamento R6 um objeto de dados do BPMN é transformado em uma classe no diagrama de classes. O objeto de dados representa os dados gerados por um processo e es- tes dados devem ser persistidos. Para que esta transformação ocorra o nome integral do objeto de dados se transforma em uma classe. Esta classe receberá o estereótipo entity e terá um re- lacionamento do tipo associação com a classe que foi gerada, de acordo com a regra R4, pelo substantivo presente na descrição da tarefa a qual este objeto de dados está relacionado. A nave- gabilidade deste relacionamento é em direção à classe gerada pelo objeto de dados. O resultado deste relacionamento é apresentado na Figura 35.
Figura 35 – Relacionamentos R6 - Transformação de Objeto de Dados para Classe
Fonte: Autoria própria
O relacionamento R7 define a transformação de um fluxo de mensagem do BPMN para um relacionamento de associação no diagrama de classes. O fluxo de mensagem é usado para mostrar a troca de mensagens entre participantes do processo, o que permite que duas ou mais piscinas se relacionem.
No diagrama de classes esta transformação permite que as classes geradas em piscinas diferentes possam se relacionar. A primeira classe relacionada pode ser identificada por duas formas diferentes: i) caso a origem do fluxo de mensagem seja a partir de uma raia, o relaci- onamento será com a classe gerada pela transformação desta raia de acordo com a regra R2, ou ii) caso a origem do fluxo de mensagem não seja a partir de uma raia, mas apenas de uma piscina, o relacionamento será com a classe gerada pela transformação desta piscina de acordo com a regra R1. Fluxos de mensagens originados em outros elementos, como um grupo, não estabelecem interferência na identificação da primeira classe.
Para identificar a segunda classe do relacionamento, é utilizado a classe gerada pelo substantivo contido na descrição da tarefa de destino do fluxo de mensagem. Esta classe já foi criada previamente pela regra de transformação R4. A navegabilidade deste relacionamento é sempre em direção à segunda classe identificada. A representação desta transformação é apre- sentada na Figura 36.
Figura 36 – Relacionamentos R7 - Transformação de Fluxo de Mensagem para Associação
Fonte: Autoria própria
Nos relacionamentos obtidos com a transformação das regras do método TMBC não foi possível aplicar a multiplicidades nos mesmos, pois a análise realizada nos modelos é de alto nível, sendo possível abstrair e identificar apenas as classes e a navegabilidade dos relaciona- mentos. Para se obter detalhes como a multiplicidades seria necessário outro tipo de abordagem ou um detalhamento diferente do que ocorre no método TMBC.
No entanto, em razão do método TMBC ser iterativo entre suas fases, regras adicionais podem ser adicionados nesta etapa para que contemplem elementos ainda não abordados neste método de transformação ou que resultem em variações de elementos já utilizados, como a
associação que pode se tornar uma classe associativa. Para cada mudança realizada é necessário retornar para a fase anterior para que o modelo de entrada seja revisto, identificando alterações que precisam ser realizadas para readequação às regras de transformação.
Uma vez que as regras de transformação estejam definidas, é necessário que as mesmas passem por um processo de formalização, que neste caso é realizado por meio da criação das regras na ATL.