Mac499 - Trabalho de Formatura Supervisionado - Monografia
Autor: Andrei Goldchleger
Parceiro de iniciação científica: David Correa Martins Junior
Orientador: João Eduardo Ferreira
Agradecimentos especiais a Roberto Hirata pelo auxílio no decorrer do projeto e ao professor Carlos Hitoshi Morimoto pelos conselhos sobre à interface gráfica
1) Parte Técnica
1.1) O projeto CAGE2) Parte pessoal
1.2) Problemas que tivemos de resolver
1.2.1) Definição do Problema1.3) Metodologia de Trabalho
1.2.2) Primeiras impressões da solução
1.4) Descrição do Sistema
1.4.1) Escolha Geométrica1.5) Ferramenta Utilizada
1.4.2) Escolha por nomes
1.4.3) Scatterplot
1.4.4) Clustering
1.6) Atividades Realizadas
1.6.1) Leitura de Artigos1.7) Cronograma das Atividades Realizadas
1.6.2) Reuniões
1.6.3) Palestras
1.6.4) Elaboração de PICTIVE
1.8) Considerações Finais - Resultados
2.1) Desafios e frustrações encontrados
2.2) lista das disciplinas cursadas no BCC mais relevantes para o estágio
2.3) Interação com colegas ou professores que tenham agido como mentores do trabalho
2.4) Diferenças notadas entre a forma de cooperação com colegas do BCC nas tarefas em grupo das disciplinas e a forma de trabalho da iniciação
2.5) Observações sobre a aplicação de conceitos estudados no curso no que foi estudado
2.6) Pretende continuar estudando o tema, ou tema correlato em uma pós-graduação
2.7) Se o aluno fosse continuar pesquisando na área, que passos tomaria para aprimorar os conhecimentos técnicos/ metodológicos/científicos/etc relevantes para esta atividade?
1) Parte Técnica
O projeto CAGE (Cooperation Analisys for Gene Expression) visa estudar genes através de suas expressões, utilizando uma técnica denominada Microarray ou DNA Chip. Consiste em utilizar um braço mecânico de alta precisão para depositar pequenas quantidades de cDNA em lâminas de laboratório (Chips) para submetê-las a diversos experimentos. Esses experimentos normalmente são feitos utilizando substâncias denominadas hibridizantes, que eventualmente reagem com os genes, produzindo alterações que posteriormente são analisadas por um microscópio e os dados resultantes são carregados para bancos de dados.
Por envolverem grandes quantidades de dados e necessidade da análise das imagens captadas pelo microscópio, o projeto necessita de forte apoio das ciências da computação, notadamente banco de dados e a área de visão, processamento e análise de imagens. O IME possui dois laboratórios envolvidos no projeto: O BioInfo - laboratório de processamento de imagens e o BioInfo - Laboratório de banco de dados. Outros institutos que participam do projeto são o Instituto de Química da Universidade de São Paulo e institutos internacionais, sendo eles: National Human Genome Research Institute (NHGRI), NIH, Bethesda, MA, USA e Texas A&M University, Texas Center for Applied Technology, Department of Electrical Engineering, Texas, USA.
1.2) Problemas que tivemos de resolver
O tema central de nosso estudo foi o de desenvolver uma ferramenta computacional que permitisse que qualquer pesquisador do Projeto Cage pudesse realizar busca e análise eficiente dos dados gerados pelo processo já descrito. A interface teria de ser, na medida do possível, utilizável por qualquer leigo na área de computação, mas obviamente o usuário necessitaria de conhecimento do que está sendo tratado na ferramenta e como pode ajudá-lo no seu trabalho.
Um problema central que tivemos que enfrentar durante todo o projeto foi a substancial quantidade de dados que o pesquisador poderia tratar ao mesmo tempo. Isto porque o objeto de estudo do pesquisador é comportamento dos genes com relação a certas condições impostas . Por exemplo, um chip de microarray pode conter milhares de genes (até quase 20000 genes). A idéia inicial do nosso projeto é permitir que o pesquisador possa correlacionar esses genes de várias maneiras.
O que descreveremos a seguir é a estrutura do conjunto dos dados que nossa ferramenta deve analisar.
Spot hibridizado: É a menor unidade na nossa hierarquia. Cada spot hibridizado corresponde a um experimento de hibridização dos genes com um ou mais cDNAs.
Subarray: É uma unidade geométrica de agrupamento de spots. Nos dados que utilizamos para teste, um subarray é um quadrado de 22 spots de lado, totalizando 484 spots. Entretanto, outras configurações podem existir.
Array: É um grupo de subarrays. Nos dados utilizados, cada array possui 16 subarrays, totalizando 7744 spots por array.
Chip: Corresponde a uma lâmina com material genético depositado pelo braço mecânico. É composto por arrays. Nos dados utilizados, cada chip possui dois arrays, sendo que um é uma réplica do outro, para validar a medição.
Subject: É a característica cuja variação está sendo estudada. Um exemplo de subject é a variação do tempo de exposição à substâncias hibridizantes, com o intuito de verificar como os genes comportam-se. Normalmente, para um dado Subject, utilizam-se alguns chips, para detectar erros experimentais.
Experiment: É um conjunto de genes, que por apresentar determinada característica, torna-se objeto de estudo. Um exemplo de característica comum é que os genes pertençam a determinada linhagem, por exemplo.
Como pode-se perceber, a hierarquia dos dados que devemos tratar é complexa, o que aumenta a dificuldade de nossa tarefa. Além disso, deveríamos oferecer flexibilidade para que o pesquisador analisasse esses dados. Este foi o nosso desafio.
1.2.2) Primeiras impressões da solução
Antes do nosso ingresso no projeto já havia uma pequena interface de escolha inicial dos dados. Já se havia pensado que, antes de qualquer coisa, o usuário deveria fazer uma escolha preliminar dos dados para que ele possa limitar bastante seu espaço de busca, facilitando o seu uso em atividades posteriores. Era a única parte da interface que estava mais ou menos bem definida, mas ainda apresentava certos problemas.
Entretanto, com relação a outras partes do projeto, não tínhamos muita noção de quais funcionalidades o sistema deveria ter, como deveria ser o desenho das janelas nem a navegação entre elas. Quando finalmente terminamos de construir a janela citada, começamos a estudar como seriam as outras partes do sistema.
Utilizamos a programação pareada para desenvolver o sistema. O sistema foi bastante complexo de ser desenvolvido envolvendo estruturas de dados complicadas e indexação intensa de matriz. Por conta disso, tornou-se apreciável a programação pareada, pois assim que idealizávamos uma solução podíamos discutir as qualidades, seus defeitos e os problemas envolvidos ao aplicar tal solução. Na hora de implementar uma solução, ficava fácil também detectar erros que eram bastante comuns. Mesmo assim, alguns erros davam bastante trabalho e tomavam bom tempo para serem corrigidos, principalmente no início, por causa de algumas peculiaridades da linguagem utilizada.
Reuniões com o nosso coordenador também eram bastante freqüentes. Isto porque o coordenador já vivenciava o problema e a necessidade de criar um sistema utilizável para o pesquisador da área muito antes de nós ingressarmos no projeto. O processo que o pesquisador fazia para obtenção e análise dos dados já era bastante conhecido por ele. Por isso era ele quem nos orientava de maneira mais direta através de reuniões e troca de mensagens por email ou até por ICQ.
Havia reuniões esporádicas com os responsáveis pelo banco de dados do Projeto CAGE. O propósito dessas reuniões era descobrir se existiam rotinas de banco que atendessem nossas necessidades. Se não houvesse tais procedimentos, explicávamos a eles nosso problema para que eles pudessem sugerir alternativas. Mas às vezes não existia alternativa a não ser encomendar os procedimentos que precisávamos para dar continuidade ao projeto.
Não havia uma especificação formal de requisitos, pois ninguém sabia muito bem as funcionalidades que o sistema deveria e poderia apresentar. Isto devido ao fato das principais características desse sistema: algo novo e experimental. Portanto, a medida que surgiam novas idéias, discutíamos e logo implementávamos para testá-las. Se era satisfatório, seguíamos em frente. Se não, analisávamos os erros e adotávamos alternativas para corrigí-los. Infelizmente, perdíamos muito tempo com esses erros, principalmente por não conseguirmos prever antes os problemas que poderiam acontecer.
A implementação do sistema se deu exclusivamente nos laboratórios da BIO-INFO no IME, pois era essencial a utilização do banco de dados do laboratório para testar trechos de código.
A interface de escolha geométrica foi o nosso ponto de partida na confecção do sistema. O objetivo da escolha geométrica é possibilitar que o pesquisador realize uma escolha preliminar dos dados com os quais deseja trabalhar, de modo a reduzir seu espaço de busca nas atividades posteriores, facilitando assim o uso. Já existia uma interface preliminar, que pode ser vista abaixo:
O problema com esta interface é que ela limitava a escolha dos dados a um único experimento, o que era indesejável. Partimos então para a idéia de uma interface mais flexível, que pode ser vista abaixo:
Na lista da esquerda, inicialmente aparecem os experimentos disponíveis para uso. Note os '+' antes do nome de cada experimento; isso é devido ao fato dos dados serem apresentados em uma estrutura semelhante árvore de diretórios, respeitando a hierarquia mencionada anteriormente.
Clicando em um experimento, abrem-se os subjects disponíveis nesse experimento; clicando num subject, abrem-se os chips do mesmo, e assim por diante. Observe os botões etiquetados com '>>', '<<' e 'Clear'. Ao clicar em '>>' , a linha selecionada na árvore é adicionada como um caminho na lista de seleções à direita. Assim, se a linha selecionada na árvore é um chip denominado 508, do subject 12, experimento Ax4, na lista da direita é adicionado o seguinte caminho: Ax4>>12>>508. Esse caminho é marcado na árvore com '*' precedendo cada nome do caminho, e esse ramo na árvore não pode ser fechado, a não ser que o caminho seja removido da lista de seleções, clicando em '<<'. Finalmente, o botão 'Clear' limpa a lista de seleções.
Mais um detalhe importante que definimos anteriormente sobre a escolha geométrica é que a árvore deveria exibir informações até o nível de subarray. Se a árvore exibisse informações até o nível de spot, a explosão de dados mostrada na árvore tornaria sua operação muito inconveniente. Mesmo apresentando dados até o nível de subarray, a quantidade de dados exibida ao mesmo tempo já se torna um pouco imprópria.
Problemas associados a essa interface:
Quando começamos a fazer a nova versão dessa interface, começamos a sentir as deficiências da ferramenta Guide do Matlab de construção de interfaces gráficas. Os Widgets disponíveis são poucos, e não existe o widget árvore. Logo, tivemos que implementar a árvore sobre um listbox comum, o que foi muito trabalhoso, pois envolvia escrever caractere a caractere na listbox, de modo a propiciar a aparência de árvore. Como na época dominávamos pouco as estruturas do Matlab, a nossa estrutura de dados também deixou um pouco a desejar, pois era a própria matriz de caracteres.
Um problema apontado pelo professor Hitoshi, em uma reunião na qual foi convidado para opinar sobre a interface, era que, conforme o usuário abre a árvore e esta se expande, cria-se a necessidade de mais espaço para visualização, o que faz aparecer a barra de rolagem. Do ponto de vista do usuário, isto é um aspecto negativo pois o excesso de scrolling necessário caso o usuário abra vários ramos de vários experimentos é grande, o que pode confundí-lo.
Finalmente, a maneira como recuperávamos para memória os dados que o usuário selecionou mostrou-se um problema. Como sabíamos que as operações de abertura de conexão com o banco de dados constituiam o gargalo do sistema, optamos por recuperar todas as seleções do usuário de uma só vez, ao invés de recuperá-las sob demanda. Isso resolveu em parte o problema, mas cria um ponto de espera para o usuário que pode ser grande, dependendo da quantidade de seleções realizadas. Ainda assim, cremos que essa é a melhor solução.
A escolha por nomes de genes é uma segunda opção de seleção que o usuário pode fazer com base na seleção feita na escolha geométrica. Isto permite que o usuário refine ainda mais seus dados de entrada. O sistema exibe todos os spots contidos na escolha geométrica e o usuário pode selecionar spots específicos para posterior análise. A escolha geométrica e a filtragem por nomes não servem para analisar os dados propriamente, mas são essenciais para reduzir o espaço amostral do pesquisador. Abaixo segue uma ilustração da janela de escolha por nomes.
Na combo-box, são listados os diversos experimentos que o usuário escolheu na fase de escolha geométrica. A cada experimento é associado um conjunto de nomes de genes disponíveis, resultado da escolha geométrica do usuário. Por exemplo, se o usuário escolheu apenas um chip do experimento 'Ax4', apenas os genes desse chip serão listados. Note que podem existir genes repetidos em um mesmo chip. Os genes disponíveis são mostrados na listbox da esquerda, entitulada 'Available genes' . O usuário pode realizar uma procura pelo nome do gene ou por um prefixo do nome, digitando o mesmo no campo de texto acima da listbox 'Available genes'. Utilizando os botões '>>', '<<', 'Add All' e 'Clear All', o usuário adiciona , remove, adiciona todos ou remove todos. As seleções são guardadas para cada experimento e são persistentes durante a execução do programa, isto é, o usuário pode alterar seleções já feitas sem ter que refazê-las do início.
Problemas associados a esta interface:
A escolha por nomes parecia uma tarefa simples, mas conforme avançávamos na implementação do sistema, encontramos dificuldades não previstas. Algumas delas foram:
Necessidade de associação dos nomes de genes a cada experimento: a princípio, a interface de escolha por nomes mostrava todos os genes disponíveis no sistema, independente da seleção do usuário. Isso mostrou-se altamente indesejável, e tivemos que alterar para a forma atual, ou seja, mostramos apenas os nomes correspondentes às seleções do usuário.
Reação a mudanças nas escolhas realizadas na interface de escolha geométrica: como o sistema permite navegação livre, o usuário pode invalidar os nomes que ele escolheu, por exemplo, voltando e desfazendo seleções nas quais alguns genes estavam incluídos na seleção por nomes.
O objetivo do "Scatterplot", também chamado de gráfico de dispersão, é determinar se certo dado sofreu alterações em seu comportamento quando submetido a condições diferentes. No caso que tratamos, o objetivo era evidenciar se os genes previamente escolhidos pelo usuário expressam-se de forma diferente quando submetidos a condições diferentes. Isto é importante pois se um gene se comportou de maneira diferente quando submetido a mudanças de condição, provavelmente tal condição é relevante para seu funcionamento, e merece estudo aprofundado.
Em nossos testes, todos os chips de todos os experimentos são idênticos em termos de distribuição de genes. As expressões gênicas podem variar, mas se em um chip, no spot identificado por x, existe o gene a, em todos os outros chips, no spot x, também existe o gene a.
A unidade de comparação dos dados em nossa ferramenta é um chip. Caso o usuário tenha selecionado partes desse chip, só estas partes serão comparadas. Entretanto, os dados devem ser consistentes, isto é, os spots de referência devem ter o mesmo identificador que os de prova. O usuário também pode escolher Subjects para realizar o scatterplot. Nesse caso, é feita uma média contendo todos os chips de um determinado subject, produzindo um chip virtual, onde o i-ésimo spot é a média das expressôes dos i-ésimos spots dos chips pertencentes ao subject escolhido.
Escolhidos os conjuntos de referência e de prova, ainda resta ao pesquisador determinar quanto devem ser as alterações entre os conjuntos para serem consideradas relevantes. No nosso caso, essas magnitudes são os fatores de subexpressão e superexpressão. Eles classificam os genes em três grupos, da seguinte forma:
Sejam:
Eref - Expressão de
determinado gene na condição de referência
Eprova - Expressão do mesmo gene na
condição de prova
Fsub - Fator se subexpressão
Fsuper - Fator se superexpressão
Se Eprova/Eref < Fsub , o gene é categorizado como
subexpresso
Se Eprova/Eref > Fsuper , o gene é categorizado como
superexpresso
Se Fsub <= Eprova/Eref <= Fsuper, o gene é
categorizado como não-expresso
A seguinte interface permite que o usuário realize as operações descritas acima:
O scatterplot possui duas utilidades. A primeira é produzir um gráfico que representa o scatterplot. Nossa ferramenta gera um relatório em HTML, contendo um gráfico colorido, evidenciando cada um dos conjuntos de genes, e uma listagem dos nomes dos genes agrupados em suas respectivas categorias. Abaixo temos um exemplo de um gráfico de scatterplot:
Outra possibilidade é utilizar os conjuntos como filtragem para atividades posteriores. Assim, o pesquisador pode decidir que, após um scatterplot, só trabalhará com genes subexpressos, por exemplo. Tal atividade pode ser feita utilizando a interface denominada "Filter by scatterplot", idêntica a interface de scatterplot, com a única diferença que não gera o relatório HTML.
Uma outra possível análise de expressão de spots é chamada de Clustering ou análise de aglomerados. O Clustering utiliza algoritmos para agrupar genes de acordo com alguns critérios. O nosso sistema apenas prepara os dados para fazer o clustering, gerando automaticamente arquivos com dados de entrada baseados na pré seleção do usuário e chamando a interface que realiza o clustering propriamente dito. Tal parte do sistema já estava pronta antes do início de nossa participação, não sendo necessárias alterações. O clustering gera várias tabelas e gráficos. Veja um exemplo de gráfico gerado pelo clustering:
Na janela de Clustering, o usuário deve fornecer um identificador para denominar sua análise de clustering, o experimento no qual deseja aplicar o clustering e escolher em qual diretório devem ser armazenados os arquivos gerados pelo clustering. Ainda deve decidir se ele quer levar em conta apenas os genes escolhidos na seleção por nomes. Caso já tenha sido processado um filtragem por scatterplot dos dados, o usuário também poderá decidir se deseja trabalhar apenas com um dos seguintes grupos de genes: subexpressos, superexpressos ou não expressos. O usuário também pode ignorar qualquer filtragem e levar em conta todos os genes incluídos na seleção geométrica feita anteriormente. Abaixo segue a janela de clustering:
A ferramenta utilizada para criação do sistema foi a linguagem MATLAB versão 6 em conjunto com um recurso novo de criação de interfaces gráficas (GUI) para o MATLAB chamado GUIDE. Decidimos usar o MATLAB devido à grande parte dos outros programas do projeto terem sido escritos no MATLAB, pois este é uma ferramenta apropriada para computação científica, própria para trabalhar com grandes volumes de dados sobre matrizes.
O GUIDE possui apenas widgets básicos para trabalhar com GUI´s. Faltava muitos recursos se comparado com outras ferramentas como o GLADE, o GTK, ou o FORTE (AWT / SWING) do JAVA. A implementação de uma árvore sobre lista, como discutimos anteriormente, foi uma atividade penosa e entediante. A falta de recursos do GUIDE nos impressionou a tal ponto que muitas vezes chegamos a achar que não era a versão completa, pois parecia que ainda estava em desenvolvimento. Mas a ferramenta já estava concluída.
O MATLAB realmente não é uma linguagem apropriada para criação de um sistema complexo de interface orientada à usuário, pois na hora de implementarmos callbacks (codificação de uma ação realizada pelo usuário), sentíamos bastante dificuldades principalmente no início porque não estávamos acostumados com as estruturas de dados internas do MATLAB. Existia também inúmeros detalhes que demoramos para descobrir com relação à navegação entre janelas e como era possível realizar uma transmissão de dados entre janelas sem gravação em arquivo. Sentimos também que a criação de interfaces gráficas em um paradigma não orientado a objetos é mais vagarosa e menos flexível.
A atividade predominante realizada durante o projeto foi a codificação do sistema. Discutiremos aqui outras atividades pertinentes ao projeto.
Lemos alguns artigos contendo idéias sobre as técnicas que os pesquisadores utilizam para produzir as lâminas (chips) e também sobre as necessidades computacionais das mesmas, além de artigos sobre interface homem-computador, que também foi um dos principais enfoques do projeto.
Computational Analysis of Microarray Data
Autor: John Quackenbush
Neste artigo, o autor faz uma discussão sobre a real necessidade que o pesquisador do Projeto Genoma tem de ferramentas computacionais que façam cálculos estatísticos, simulações e geração de tabelas, gráficos e relatórios. Ele apresenta uma descrição sobre técnicas de coleção de dados, normalização, comparação entre expressões através de criação de gráficos estatísticos e alguns algoritmos para fazer análise de aglomerados (clustering).
A Specification Language for Direct Manipulation User Interfaces
Autor: Robert J. K. Jacob
Explicação de técnicas formais para criação de interface orientada ao usuário final usando uma linguagem de especificação. Utilização de diagramas de estado (autômatos) e linguagem de programação Ada para descrever formalmente botões, barras de rolagem, caixas de texto, popup menus, formulários e outros widgets comuns encontrados numa interface. Noções de orientação à objetos que podem ser aplicados à uma interface gráfica como herança, componentes e interação entre objetos (troca de mensagens).
Grande parte das reuniões contavam com a participação do nosso coordenador do projeto: Roberto Hirata. À medida que íamos encontrando problemas, recorríamos à ele para que nos ajudasse a solucioná-los. As reuniões ocorriam com freqüência semanal.
Os problemas que mais discutíamos nas reuniões eram relacionados à dificuldade de saber que funcionalidades os pesquisadores necessitariam no sistema. Mesmo os outros integrantes do projeto, que já trabalhavam há algum tempo com problemas computacionais do Projeto CAGE, tinham dificuldade em saber quais funcionalidades a ferramenta deveria ter e como essas funcionalidades deveriam ser apresentadas ao usuário. Houve algumas reuniões com o pessoal do Instituo de Química para perguntar-lhes o que o sistema deveria ter, mas eles também não davam informações suficientes por não terem conhecimento do que pode e o que não pode ser feito.
Muitas vezes, nós, juntamente com outros integrantes do projeto, discutíamos o que o sistema deveria ter e depois verificávamos os resultados da implementação. Houve inevitavelmente muitos furos de implementação durante o projeto por não termos definido anteriormente o comportamento do sistema.
Houve reuniões com os responsáveis pelo banco de dados da BIO-INFO para discutirmos soluções que precisavam utilizar rotinas de banco. Além disso detectávamos muitas ineficiências em vários pontos do sistema que eram provocadas principalmente por inúmeras chamadas ao banco. Alguns desses problemas foram solucionados através da criação de rotinas de banco que trabalhassem com a maior quantidade possível de dados simultaneamente, diminuindo significativamente o overhead de conexões com o banco.
Houve também uma reunião com o professor Carlos Hitoshi Morimoto, especialista em interfaces homem-máquina, que analisou a nossa interface de escolha geométrica e nos deu algumas idéias de como ela poderia ser melhorada.
Sistema de Desenvolvimento Rational Rose: Sistema que busca uma automatização da atividade de engenharia de software necessária para o desenvolvimento de qualquer tipo de sistema computacional de médio e grande porte. O nosso sistema tem um porte considerável, mas não conseguimos definir até hoje todos os requisitos necessários. Isto principalmente se deu pelo fato de que o nosso sistema possui um caráter experimental, ou seja, o sistema exibe inúmeras funcionalidades que podem ser oferecidas ao usuário final para que se possa definir o que é inútil e o que é útil. Portanto, acabamos por não optar pela utilização do sistema Rational Rose.
Palestra sobre o Banco de Dados do Projeto Genoma:
Palestrante: Dr. João Eduardo Ferreira
Explicação das partes principais do banco de dados do Projeto Genoma (GenBank) e como se dá o relacionamento entre essas partes com outras camadas do sistema. Divisão do banco de dados do Projeto Genoma em duas partes principais: Projeto CAGE e Projeto Genoma Vírus. O banco de dados do Projeto CAGE trata de dados para análise de um único microorganismos ou célula em nível microarray (chip, spots, etc.). Já o banco de dados do Projeto Vírus trata de dados para análise genética sobre um conjunto de tecidos ou um conjunto de organismos (população).
Logo depois de concluírmos a janela de escolha geométrica, tínhamos que saber como seriam as outras janelas e como elas iriam se relacionar. O nosso coordenador nos dava informações do que deveria ser feito dali para frente, mas nem ele e nem nós tínhamos idéia de qual seria uma boa forma de exibição das informações para os dados. Tivemos então que apelar para o PICTIVE que é uma técnica que utiliza apenas papel e lápis para uma rápida prototipação das janelas. Esta técnica prega que o indivíduo não perca muito tempo no desenho das janelas (máximo 1 hora). Cada janela é disposta em uma folha própria, inclusive as janelas de diálogo e de erro. Quando estiver pronto, o PICTIVE permite uma simulação do uso da interface. Assim fica fácil de detectar problemas e assimilar novas idéias com relação à interface. E acabou dando certo, pois após o PICTIVE tivemos idéias mais claras do que o sistema deveria apresentar e como ele iria se comportar dadas as possíveis ações do usuário.
1.7) Cronograma das Atividades Realizadas
Março: Reunião inicial com a equipe de banco de dados, juntamente com o Professor João Eduardo Ferreira e o coordenador Roberto Hirata. Aprendizagem inicial da ferramenta GUIDE de criação de interfaces do MATLAB. Entendimento do código da interface antiga de escolha geométrica e seus principais problemas.
Abril: Implementação da nova interface de escolha geométrica. Palestra sobre Banco de Dados do Projeto Genoma (GenBank).
Maio: Término da Implementação da interface de escolha geométrica. Criação de tabelas e estruturas de dados convenientes para utilização em todas as outras partes do sistema. Palestra sobre a ferramenta de engenharia de software Rational Rose.
Junho: Testes, correções e reformulações sobre as tabelas e estruturas de dados criadas. Entendimento das funcionalidades básicas do sistema. Elaboração de um PICTIVE para dar uma visão melhor do que o sistema deve apresentar e de como deve se comportar.
Julho: Desenho inicial no GUIDE de todas as janelas que obtivemos no PICTIVE. Reformulações das janelas.
Agosto: Inclusão de navegação entre janelas. Início da implementação da funcionalidade das janelas, começando por Scatterplot.
Setembro: Continuação da implementação do Scatterplot, testes e término da implementação do Scatterplot. Início da implementação de escolha por nome de genes. Discussão sobre trechos bastante ineficientes do código e como solucioná-los. Provamos que na maioria das vezes, as ineficiências eram causadas pelas inúmeras chamadas ao banco de dados.
Outubro: Início da implementação do Clustering. Descobertas inúmeras deficiências e inconsistências na implementação do Scatterplot, do Clustering e da seleção por nomes. Conserto da interface de Scatterplot, término da implementação de seleção por nomes e de Clustering. Testes e correções finais. Inclusão de janelas de diálogo e mensagens de erro para o usuário na tentativa de deixar o sistema à prova de qualquer usuário (user-proof).
Novembro: Término do sistema e início da monografia.
1.8) Considerações Finais e Resultados
Aqui descreveremos dois objetivos que nós não conseguimos atingir, seja por falta de tempo ou por inviabilidades decorrentes do sistema:
Integração do sistema na WEB: Era previsto desde o início que o sistema pudesse ser utilizado com relativa eficiência na Internet. Infelizmente este aspecto acabou ficando inviabilizado devido à grande quantidade de dados manipulada pelo sistema. Já é relativamente lenta a execução local do sistema. Outro problema é que não íamos ter tempo suficiente para descobrir se haveria maneira de integrar um sistema em MATLAB com ferramentas de tecnologia WEB como Applets, Servlets ou CGI, mas pelo menos conseguimos fazer com que o scatterplot e o clustering gerassem relatórios com tabelas e gráficos em formato HTML, o que facilita sua publicação na WEB.
Uma conta para cada usuário: Esta funcionalidade foi idealizada em julho. Nessa época começávamos a vislumbrar que seria útil se cada usuário pudesse salvar uma ou várias sessões para que posteriormente ele pudesse continuar a trabalhar exatamente a partir de onde havia parado. Cada usuário teria um login e uma senha, e cada um poderia salvar quantas sessões quisesse como se cada sessão fosse uma espécie de arquivo em disco. Mas para isto eram necessárias funções e tabelas em banco de dados não previstas anteriormente. Além disso, este seria um recurso que deixaríamos por último, pois era menos importante do que outras partes do projeto, mas não sobrou tempo para a implementação dessa funcionalidade. Apesar de tudo, desenhamos as janelas de login e de menu principal associadas a esta funcionalidade, faltando a implementação das mesmas.
Apesar de não termos conseguido implementar tudo, atingimos o objetivo principal do projeto que é o de fornecer um primeiro sistema simples e utilizável, que seja capaz de oferecer funcionalidades básicas que auxiliem o pesquisador do Projeto CAGE a estabelecer relações e tirar conclusões dos dados de experimentos envolvendo genes e suas expressões sob determinadas condições.
2) Parte pessoal
2.1) Desafios e
frustrações encontrados
Algumas vezes quando programávamos a realidade das coisas
me deixava desanimado. Isto porque geralmente as coisas levavam
mais tempo para ser feitas do que o estimado. Alguns bugs
ridículos nos atrasavam bastante. Outras vezes,
acabávamos em "becos sem saída", e tínhamos
que refazer algumas coisas, dado que nossa
especificação sempre estava sujeita a
mudanças. Às vezes as peculiaridades da linguagem
Matlab conseguiam me irritar bastante. Creio que o desafio foi a
própria iniciação científica, e as
novidades que ela apresentou na maneira de conduzir o trabalho e
cooperar com outros.
2.2) lista das
disciplinas cursadas no BCC mais relevantes para o
estágio
Disciplinas introdutórias(Mac 110, 122, ED): Forneceram os
conceitos de lógica de programação e primeiras
noções de análise de algoritmos
Mac 300 - Métodos Numéricos da Álgebra
Linear: Primeiro contato com uma liguagem de
programação parecida com a do Matlab, a linguagem do
Scilab
Mac 332 - Engenharia de Software: Noções de
construção de interfaces gráficas e
importância dos testes
Programacao eXtrema - Ensinou a importância dos testes
2.3)
Interação com colegas ou professores que tenham agido
como mentores do trabalho
Realizei a minha iniciação científica junto
com David Correa Martins Junior. Como ele era colega do BCC, nossa
interação foi bastante parecida a que temos durante o
curso. A menos do início, programamos praticamente todo o
sistema juntos, na mesma máquina, trocando idéias ao
longo da confecção do código. É
interessante notar que quando iniciamos o trabalho, eu ainda
não conhecia os preceitos de Programação
eXtrema, portanto foi uma coincidência já estar
programando pareado. A atividade era bem produtiva, e ,
considerando que mexíamos com matrizes o tempo inteiro, era
útil ter alguem do lado para detectar os índices
inválidos.
Não tive muita interação com o meu
orientador, João Eduardo Ferreira. Tivemos algumas
reuniões em que ele apresentou as outras áreas e
atividades do projeto, outras para acompanhar como o nosso trabalho
se desenvolvia. Grande parte da nossa interação foi
com Roberto Hirata, que também participava do projeto. Foi
importante porque não tivemos nenhuma reunião com os
clientes do nosso software, sendo ele a ponte entre as necessidades
do cliente e nossas atividades. A sua ajuda foi muito importante
nas decisões de interface e sugestões de
implementação, especialmente no início, quando
não dominávamos a linguagem Matlab.
Em relação às outras pessoas do projeto,
minha interação mais relevante foi com os
responsáveis pelo banco de dados do projeto, sendo eles
Thiago Teixeira Santos e Gustavo Tadao Okida. Eles estavam
presentes em algumas reuniões em que demonstramos a
interface, e também recorríamos a eles quando
tínhamos dúvidas sobre funções
já implementadas no banco de dados, ou pedidos de novas
funções.
2.4)
Diferenças notadas entre a forma de cooperação
com colegas do BCC nas tarefas em grupo das disciplinas e a forma
de trabalho da iniciação
Talvez a diferença mais relevante entre a
cooperação com colegas no BCC e a realizada na
iniciação científica seja que nesta
realizávamos muitas reuniões. Apesar de todos no
projeto sempre serem muito receptivos quando tinhamos
dúvidas, todos tinham atividades paralelas e nem sempre
estavam presentes no momento em que estávamos programando.
Assim, as reuniões adquiriam grande importância, uma
vez que era o melhor momento para tirarmos dúvidas e
sobretudo tomar decisões sobre o sistema. Várias
vezes passavam de uma hora, eram muito produtivas e o fórum
ideal para discutir idéias, sobretudo a
disposição das interfaces, seu conteúdo e
funcionalidade.
2.5)
Observações sobre a aplicação de
conceitos estudados no curso no que foi estudado
Os conceitos estudados que mais apliquei na
iniciação certamente foram aprendidos em engenharia
de software, em uma breve seção do curso em que
aprendemos noções de construção de
interfaces gráficas. Também pode ser considerada,
junto com programação eXtrema, a responsável
por outro conceito importante que aplicamos: os testes. A maioria
dos testes do sistema foram feitos empiricamente, mas o
código de teste que escrevemos encontrou bugs, ou seja, foi
bem sucedido.
2.6) Pretende continuar estudando o tema, ou tema correlato em uma pós-graduação
Apesar de possuir interesses na construção de interfaces gráficas, provavelmente este não é o tema pelo qual mais me interesso. Entretanto, gostaria de estudá-lo se associado a outros temas.
Minha iniciação científica
não foi muito teórica, caracterizando-se mais pela
implementação de código. Este código,
apesar de trabalhoso, não envolveu conhecimentos
avançados. Conceitos de Interação Homem
Computador foram úteis, entretanto creio que talvez poderia
desenvolvê-los ainda mais, através da leitura de
textos da área ou cursando a matéria
Princípios de Interação Homem Computador, que
creio que teria grande utilidade para o meu trabalho. Tenho algumas
sugestões de como gostaria de prosseguir com o trabalho,
caso fosse esta a situação:
Porte do código para uma outra linguagem: Matlab mostrou-se
uma linguagem inadequada para a confecção de
interfaces gráficas. Apesar de possuir uma ferramenta
independente para isso, o GUIDE, todas as estruturas de dados
são baseadas em matrizes e structs, não havendo a
possibilidade de criar objetos, por exemplo. Isso tornou nossas
estruturas de dados estranhas, fato que não ocorreria se
utilizássemos uma linguagem como C ou Java. Se pudesse
escolher uma nova linguagem para o desenvolvimento, escolheria
Java, pois é orientada a objetos, o que na minha
opinião ajuda a produzir código de melhor qualidade,
possui excelente documentação, muitos features
já implementados e toolkits gráficos (awt e Swing)
muito mais poderosos que os presentes no GUIDE. Além disso,
creio que seria bem mais direto quando tivéssemos de
permitir o uso da inteface via web.
Mas, caso tivesse de manter a base de código Matlab, teria
algumas idéias para melhorias. Aqui cito uma delas:
Pre-fetching de dados na interface de escolha geométrica:
Nas operações de árvore presentes na interface
de escolha geométrica, primeira que descrevi nessa
monografia, cada operação na árvore de
experimentos realiza uma consulta ao banco de dados. Isso
não é muito bom, porque cada operação
demora em torno de três segundos, e se o usuário
manipular muito a árvore, isto pode tornar-se
desagradável. Uma solução seria carregar a
árvore com as hierarquias no início da carga da
interface, gravando-a num struct Matlab. Como essa hierarquia
não tende a ocupar muito espaço de memória,
creio que não seria um problema nesse sentido. Não
utilizamos essa solução porque no início do
nosso trabalho nem sabíamos da existência dos structs
Matlab.