• Nenhum resultado encontrado

Capítulo 5 Avaliação de Componentes para o Contexto de Execução de Sistemas

5.3 Implementação e Resultados de Experimentos

5.3.1 Prova de Conceito

Objetivando verificar a viabilidade de utilização dos serviços de avaliação de componentes providos pelo módulo Avaliador, uma implementação desse módulo foi utilizada em um experimento que consistiu no acionamento do módulo, fornecendo como entradas um arquivo Descritor de Componente e representações de diferentes contextos de execução de um sistema cliente. Nesse experimento, o arquivo Descritor de Componente continha regras fuzzy que utilizavam duas variáveis de contexto: dispositivo.resolução e

vídeo.resolução, referentes respectivamente à resolução do dispositivo de exibição e do sinal de vídeo recebido pelo sistema cliente. Nesse caso, cada variável pode assumir um valor numérico entre 0 e 1920, que representa o número de linhas da resolução. Após serem fuzificadas, as variáveis podem pertencer a três conjuntos fuzzy: LDTV, SDTV e HDTV, que representavam respectivamente vídeos de resolução baixa, padrão ou alta. A variável de saída pode assumir valores de 0 a 100, de tal forma que quanto maior for o valor da variável de saída, mais adequado é o componente para o contexto de execução. Antes da desfuzificação, a variável de saída pode pertencer aos conjuntos fuzzy: ADEQUADO,

REGULAR ou INADEQUADO. Assim sendo, as seguintes regras fuzzy foram especificadas

Se dispositivo.resolução = LDTV e vídeo.resolução = LDTV então artefato é ADEQUADO Se dispositivo.resolução = LDTV e vídeo.resolução = SDTV então artefato é REGULAR Se dispositivo.resolução = LDTV e vídeo.resolução = HDTV então artefato é INADEQUADO Se dispositivo.resolução = SDTV e vídeo.resolução = LDTV então artefato é REGULAR Se dispositivo.resolução = SDTV e vídeo.resolução = SDTV então artefato é ADEQUADO Se dispositivo.resolução = SDTV e vídeo.resolução = HDTV então artefato é REGULAR Se dispositivo.resolução = HDTV e vídeo.resolução = LDTV então artefato é INADEQUADO Se dispositivo.resolução = HDTV e vídeo.resolução = SDTV então artefato é REGULAR Se dispositivo.resolução = HDTV e vídeo.resolução = HDTV então artefato é ADEQUADO

Essas regras foram especificadas na forma de um arquivo FIS com o auxílio da ferramenta de programação Matlab. Além das regras fuzzy, constam no arquivo FIS a definição dos possíveis valores que as variáveis de entrada podem assumir e os parâmetros que determinam o funcionamento do motor de inferência. A definição desses elementos através da ferramenta de programação matemática é ilustrada respectivamente nas Figuras 5.3, 5.4 e 5.5.

Figura 5.4 – Utilização da ferramenta Matlab para definição das variáveis de entrada

Figura 5.5 - Utilização da ferramenta Matlab para definição dos parâmetros do motor fuzzy

Os testes foram executados utilizando diversos valores para as variáveis

quando o DRTVD e o vídeo recebido possuíam a mesma resolução, o grau de adequação do componente era máximo. Quanto maior a diferença entre as resoluções do DRTVD e do vídeo recebido, menor foi o grau de adequação do componente. Como esse era o objetivo do Descritor do Componente, considerou-se que o experimento foi bem sucedido.

Em outros experimentos, cinco desenvolvedores de componentes foram convidados a tentar expressar através de regras da lógica fuzzy os contextos para os quais eles consideram que seus componentes são mais ou menos adequados. Foram gerados

Descritores de Componentes para 25 componentes, todos desenvolvidos para o middleware

FlexTV. Cada descritor utilizava em média 10 variáveis de contexto, sendo 33 o número máximo de variáveis de contexto utilizadas por um mesmo Descritor de Componente e 3 o número mínimo. Em um simulador, variou-se o valor de cada variável de entrada e analisou-se o valor da avaliação feita pelo Avaliador. Na visão dos desenvolvedores, os resultados retornados pelo módulo avaliador foram condizentes com os contextos que eles consideram adequados para os seus componentes. Ou seja, quanto melhor eles consideravam que era o contexto, maior era o valor retornado pelo módulo Avaliador do REATIVO e vice versa.

Cabe aqui ressaltar que a avaliação de um componente com relação ao seu grau de adequação para um determinado contexto de execução, por parte do desenvolvedor do componente, normalmente é feita de forma subjetiva. O desenvolvedor faz essa avaliação com base nas suas experiências anteriores e no comportamento que ele espera para o componente em cada contexto de execução. O objetivo dos experimentos realizados foi verificar se o mecanismo baseado em formulações da lógica fuzzy, utilizado pelo Avaliador, é suficiente para que o desenvolvedor consiga expressar o conhecimento necessário para avaliação dos componentes. Para o conjunto de componentes considerados no experimento, constatou-se que o mecanismo baseado em lógica fuzzy foi suficiente para a captura do conhecimento.

5.4 Considerações Finais

Esse capítulo destacou quais módulos da arquitetura do REATIVO estão diretamente envolvidos no processo de avaliação de componentes para o contexto de execução dos

sistemas clientes, identificando o papel de cada módulo e a forma como eles interagem para prover o serviço de avaliação.

Para que os desenvolvedores de componentes possam considerar as variáveis coletadas pelos monitores de contexto no processo de avaliação de seus componentes, é necessário que tais variáveis contextuais sejam muito bem definidas semântica e sintaticamente. Neste trabalho, essas definições são feitas através de uma Ontologia de Domínio para TV Digital.

O mecanismo de inferência utilizado pelo módulo Avaliador do REATIVO é baseado em um motor de inferência da lógica fuzzy. Utilizando tal mecanismo, nos experimentos realizados, verificou-se ser possível definir regras que definem para que contextos de execução os componentes são mais ou menos adequados. Os resultados das avaliações feitas pelo módulo Avaliador foram adequados aos contextos de execução considerados nos experimentos, na visão dos desenvolvedores.

O emprego de outros mecanismos de avaliação que podem ser utilizados pelo módulo Avaliador é deixado para trabalhos futuros. Por exemplo, o próprio componente software a ser avaliado poderia ser instanciado pelo módulo Avaliador e se auto-avaliar para o contexto de execução, considerando as variáveis presentes na Base de Fatos. Nesse caso o componente precisaria implementar interfaces específicas que seriam utilizadas pelo módulo Avaliador.

Capítulo 6 - Geração de Configurações de