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 classe-pai) e uma classe mais específica (chamada de subclasse ou 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.