Mapeamento de Zhang, Diedrich e Halang

O paradigma FBUML _{proposto por Zhang, Diedrich e Halang (2005) prevê a}

extensão dos metamodelos da UML – ou seja, modelos em UML que definem essa mesma linguagem – através da definição de novos estereótipos, restrições e valores rotulados, agrupados em um perfil, os quais descrevem os principais conceitos relacionados à norma IEC 61499. Dessa maneira, a UML pode ser usada, junto aos diagramas de blocos funcionais e de configuração de dispositivos, para o projeto de um sistema de automação distribuído, sendo esses últimos responsáveis pela especificação arquitetural abstrata do sistema. A seguir, é detalhada a função de cada um dos diagramas da UML nesse mapeamento UML-IEC61499.

3.1.4.1. Diagramas da UML usados no mapeamento de Zhang, Diedrich e Halang

Os diagramas da UML usados nesse mapeamento são os Diagramas de Classes, de Estruturas Compostas, de Máquinas de Estado, de Atividades e de Interação.

[1] Capturar estrutura dos diagramas da UML [2] Eliminar os dados irrelevantes

[3] Selecionar SYSTEM para captar a estrutura do sistema: [3.1] Escrever informações relacionadas à versão do XML [3.2] Escrever o nome do sistema, i := 0

[3.3] Ler Dispositivo(i) (Device(i))

SE Dispositivo = último ENTÃO ir para [4] SENÃO

INICIAR

[3.3.1] Escrever o nome do Dispositivo(i), j := 0 [3.3.2] Ler Recurso(i) (Resource(i))

SE Recurso = último ENTÃO ir para [3.3] SENÃO

INICIAR

[3.3.2.1] Escrever o nome do Recurso(i,j)

[3.3.2.2] Compor a rede de blocos funcionais (RedeBF): Acrescentar FB (nome, parâmetros, etc.) Acrescentar conexões entre eventos Acrescentar conexões entre dados SE RedeBF != fim ENTÃO

voltar para [3.3.2.2] SENÃO

SE Recurso != último ENTÃO

(j := j + 1), voltar para [3.3.2] SENÃO

(i := i + 1), voltar para [3.3] [4] FIM (i := 0, j := 0)

3.1.4.1.1. Diagrama de Classes

Os Diagramas de Classes representam os diferentes tipos de blocos funcionais e suas interfaces. Os blocos funcionais são representados por classes, que podem possuir os seguintes estereótipos: BasicFB (para blocos funcionais básicos), CompositeFB (para blocos funcionais compostos) e SIFB (para blocos funcionais de interface de serviços). A partir daí, as interfaces dos tipos de blocos funcionais são determinadas pelos elementos de sua classe representante: os eventos de entrada são métodos públicos de estereótipo EventInput; os eventos de saída são métodos privados de estereótipo EventOutput; os dados de entrada são atributos privados de estereótipo InputVariable; os dados de saída são atributos públicos de estereótipo OutputVariable; e as variáveis internas são atributos privados estereotipados como InternalVariable.

Para estabelecer uma associação entre eventos e dados, como ocorre na norma IEC 61499 ao se utilizar o qualificador WITH, emprega-se entre o evento e o dado um relacionamento de dependência de estereótipo AssociateWith. Já para estabelecer a relação entre um evento de entrada e seus dados e eventos de saída deve ser posto entre eles um relacionamento de dependência de estereótipo obsOutput (partindo do evento de entrada para as saídas), tanto no caso de blocos funcionais básicos como compostos.

Por fim, para a representação de redes de blocos funcionais (ou seja, de blocos funcionais compostos ou de subaplicações), são usadas classes com os estereótipos CompositeFB (para blocos funcionais compostos) ou Application e SubApplication (para aplicações e subaplicações), cujas interfaces externas são especificadas da mesma maneira descrita anteriormente. Tais classes são associadas às suas instâncias de blocos funcionais internas através de relacionamentos de agregação.

3.1.4.1.2. Diagrama de Estruturas Compostas

Uma alternativa para expressar os elementos internos de blocos funcionais compostos, aplicações ou subaplicações é fazer o Diagrama de Estrutura Composta da classe que representa o bloco funcional.

pelas partes da classe composta) podem ser especificadas como instâncias da metaclasse InformationFlow (fluxo de informação), sendo seus estereótipos, respectivamente, EventConnection ou DataConnection. Os estereótipos citados são definidos pela extensão das metaclasses InformationItem (item de informação) e Connector (conector). Como um InformationFlow pode transferir alguns InformationItem, eventos e dados (instâncias de InformationItem) são passados por uma mesma conexão de eventos e dados. Colaborações podem ser usadas para descrever mais detalhes das conexões entre as instâncias contidas em uma classe, e as conexões entre a classe composta e seus componentes pode ser especificada com o uso de instâncias de portas e conectores.

3.1.4.1.3. Diagrama de Máquinas de Estados

O Diagrama de Máquinas de Estados da UML é utilizado para a representação do diagrama de controle de execução de um bloco funcional, e, nesse caso, seu estereótipo denomina-se ECC. Os estados do ECC são marcados pelo estereótipo ECState, enquanto suas transições são de estereótipo ECTransition. Estas, por sua vez, podem ter apenas um evento como gatilho (não havendo guarda ou atividade na transição), ou podem ser disparadas por um evento e uma expressão booleana simultaneamente (caso em que a transição tem o evento por gatilho e a expressão por guarda). Por fim, vale lembrar que, para manter compatibilidade com a norma IEC 61499, o estereótipo ECC possui como restrições

Figura 37: Relação entre os estereótipos DataConnection e EventConnection com as metaclasses

Connector e InformationItem da UML (a), e exemplo de Diagrama de Estrutura Composta segundo o

os fatos de que nem seus estados nem suas transições podem ser compostos, além de que seu estado inicial deve ser sempre denominado START.

3.1.4.1.4. Diagrama de Atividades

O(s) algoritmo(s) ligado(s) à(s) atividade(s) executada(s) na entrada a um estado do ECC pode(m) ser representado(s) na UML por um método privado. Assim, para cada um deles atribui-se o estereótipo Algorithm, que estende a metaclasse Operation e que possui visibilidade privada fixa. Por fim, como ocorre para qualquer método da UML, seu comportamento pode ser especificado através de um Diagrama de Atividades.

3.1.4.1.5. Diagrama de Interação

Os Diagramas de Interação da UML previstos para uso no mapeamento de Zhang, Diedrich e Halang são o Diagrama de Seqüência e o Diagrama de Colaboração/Comunicação.

Os Diagramas de Seqüência são responsáveis por indicar a interação entre as instâncias dos componentes de uma rede de blocos funcionais e suas conexões de eventos e dados, dando destaque à visão sobre os tempos de execução de tais interações. Os Diagramas de Colaboração/Comunicação, por sua vez, são empregados para mostrar a cooperação entre essas instâncias do ponto de vista estrutural. A conexão entre eventos (de entrada e saída) é descrita por uma mensagem (de estereótipo EventConnection), dirigida do objeto remetente ao objeto destinatário. Nesse contexto, os dados associados ao evento são passados como parâmetros das mensagens. Para não haver conflito na nomenclatura de tais mensagens, a seguinte regra é sugerida: “objeto_receptor evento_do_remetente evento_do_destinatário”. Para os parâmetros, a regra aplicada deve ser: “objeto.variável” (sendo esse objeto o dono da variável declarada). Deve-se esclarecer que as mensagens das instâncias para a classe agregadora da rede de blocos funcionais são operações da classe (ou bloco funcional composto) que representam eventos de saída da mesma, enquanto aquelas que partem da classe para as instâncias identificam seus eventos de entrada.