A aplicação tem duas componentes principais: o servidor, que faz a captura e transformação dos sinais em notas musicais; a interface gráfica que permite ao utilizador visualizar as notas que estão a ser tocadas. Cada componente executa-se em processos diferentes, o que torna necessário desenvolver uma estratégia para que possa haver interacção entre o servidor áudio e o ambiente gráfico. O servidor áudio, é uma aplicação standlone que é executada pela interface gráfica, que vai efectuar todos os processos de captação do sinal áudio e conversão em notas musicais. A interface gráfica permite ao utilizador iniciar ou parar o processo de captura do sinal; neste sentido existem duas formas de comunicação entre a interface gráfica e o GSTTransporter que são as seguintes: ficheiro áudio e fila de mensagem. A Figura 55 ilustra o diagrama de integração entre o servidor e a interface gráfica.
O servidor áudio é iniciado por meio de passagem de parâmetros ao programa executável. Quando o servidor áudio inicia a execução, todo o sinal áudio é gravado num ficheiro no formato especificado pelo utilizador por meio de parâmetro. Os comandos que permitem iniciar a captura são enviados por meio de fila de mensagem. As notas detectadas são armazenadas numa fila de mensagens partilhada entre o servidor áudio e a interface gráfica. Resumindo, a solução para integrar o servidor e a interface gráfica passa pela utilização de métodos de comunicação entre processos. Para implementação destes métodos é utilizada a biblioteca Boost Interprocess [51]. Esta biblioteca implementa vários métodos de comunicação entre processos.
Para além disso, é necessário integrar o código do Transporter desenvolvido em C/C++ com o da interface desenvolvido em C#. Para este efeito foi necessário desenvolver uma camada de integração entre C/C++ e o C#.
A necessidade de integração de código C++ tinha que ser resolvida de forma que se tivesse o menor número de pontos de integração possível, mantendo a simplicidade da sua implementação. O problema de integração levantou-se quanto foi necessário aceder à memória partilhada e à fila de mensagem criada usando a biblioteca Boost interprocess, porque não há mecanismos para aceder a esta memória directamente da plataforma .NET. A comunicação entre processos na plataforma .NET pode ser feita utilizando Named Pipes, Remoting, ou mesmo MicroSoft Message Queue (MSMQ). Mas para o código C++ aceder a estes mecanismos de comunicação entre processos envolveria uma maior complexidade e custo de desenvolvimento. A opção recaiu em desenvolver uma biblioteca dinâmica em C que iria ser chamada pelo código C#.
Dado que a comunicação entre o Transporter e a interface gráfica é feita através de fila de mensagem. O número de funções a serem exportadas para C# não são muitas, e o ponto de integração é único. Neste sentido, de forma resumida é necessário criar uma forma de o código desenvolvido em C# possa aceder à fila de mensagem desenvolvida em C++. Para tal ser possível, foi criada uma biblioteca dinâmica em C/C++, que implementa o acesso a fila de mensagem desenvolvida em C++ com a biblioteca Boost interprocess, para ler e escrever na fila de mensagem. Recorre-se à plataforma .NET, utilizando a InteropServices do namespace System.Runtime.InteropServices [59]. O InteropServices permite carregar bibliotecas desenvolvidos em código nativo. O atributo DllImport [60] permite carregar uma biblioteca dinâmica implementada noutra linguagem e criar um entry point para o método implementado na DLL.
Como a aplicação está implementada para suportar vários sistemas operativos, a biblioteca dinâmica tem uma extensão diferente para cada sistema operativo. No caso do Linux as bibliotecas possuem extensão .so e na plataforma Windows .dll. Por este motivo na biblioteca criada para integração não terá uma extensão nem .so ou .dll. Desta forma não será necessário criar um nome separado para cada plataforma. A diferença no formato binário gerado em cada sistema operativo implica que a biblioteca dinâmica terá que ser compilada separadamente em cada sistema operativo.
A biblioteca criada chama-se Transporter e implementa métodos que permitem interacção entre o GSTTransporter e a interface gráfica. Os métodos com implementação em C++ têm que ser expostos como sendo extern “C” porque assim podem ser chamados como funções C, o que facilita a importação. Quando o método é compilado como código C++, o nome é alterado e a estrutura da chamada o método pode também ser alterada dependendo do compilador. Depois da biblioteca criada em C/C++, uma classe em C# foi criada que importar todos os métodos para .NET, permitindo assim o código C# chamar código nativo C/C++.
No entanto, testes desta solução revelaram que muito embora a biblioteca dinâmica estivesse a exportar as funcionalidades do código C++ como código C, as chamadas nos métodos internos da biblioteca Boost message_queue fazem chamada a estruturas complexas em C++, o que não permitia que esta solução fosse utilizada,e por este motivo foi necessário implementar outra solução.
A solução utilizada passou pela criação de um programa em C++ que é responsável por ler e escrever na fila de mensagens. Este programa é um executável que recebe como parâmetros o número da mensagem a ser enviada e faz a escrita deste valor na fila de mensagem de comandos. Quando esta aplicação é executada sem parâmetro, faz a leitura da fila de mensagem que contém as frames e escreve no standard output no formato XML. Desta forma a aplicação que executa tem que redireccionar a saída do standard output para ler e receber a frame no formato XML. É possível observar a estrutura UML de uma frame na secção 5.1.3 deste Capítulo, Figura 48. O objecto do tipo Frame, é escrito como um objecto em XML no standard output mediante a implementação do operador de escrita“<<”. Desta forma o programa responsável pela leitura da frame na fila de mensagem e posterior escrita no standard output escreve o objecto como uma estrutura XML.