• Nenhum resultado encontrado

Capítulo 5   Back-End e Front-End 37

5.1   Back-End 37

Um dos objectivos secundários deste trabalho era a actualização dos scripts das ferramentas de modo a estas formatarem os resultados num formato pedido pelo utilizador, TSV, CSV, JSON ou XML. Para ambas as ferramentas, ProteInOn e CMPSim, a estratégia tomada foi idêntica, adicionar um novo argumento na chamada destas ferramentas, que iria indicar qual o formato pretendido, e, no ciclo onde os resultados eram formatados, verificar qual era o formato pretendido, e assim, devolver os resultados nesse formato. Para além destas modificações, foi também adicionado um argumento opcional de modo a incluir a informação adicional desejada pelo utilizador.

5.1.1 ProteInOn

No caso do ProteInOn esta actualização quase que foi automática, pois já tinha sido feita uma actualização prévia do ProteInOn de modo a este receber um argumento correspondente ao formato pedido pelo utilizador e, os resultados eram formatados em dois formatos, XML e numa tabela HTML. Assim, foi só necessário actualizar o formato XML e introduzir os outros três formatos, JSON, CSV e TSV. De seguida foi acrescentado um argumento que indicasse que informação adicional o utilizador deseja. Este argumento foi introduzido no final da chamada da ferramenta. Assim, não só não era necessário fazer alterações em termos de código, como se torna opcional.

5.1.2 CMPSim

Para o CMPSim esta actualização sofreu uns passos adicionais, visto esta ferramenta só permitir o cálculo da semelhança semântica entre dois compostos ou duas

38

vias metabólicas, usando duas medidas implementadas, simGIC e simUI. Por esta razão foi modificado a chamada da ferramenta de modo a receber como argumentos, para além do formato desejado, qual a medida para o cálculo da semelhança semântica e, utilizado no mesmo modo que para o ProteInOn, um argumento opcional para a informação adicional. Por outro lado, foi adicionado um ciclo de modo a percorrer o input de compostos ou vias metabólicas e, assim calcular a semelhança semântica entre os diferentes pares, sendo formatados no formato pedido pelo utilizador. No caso da funcionalidade Characterization, e vista a estrutura da ontologia ChEBI ser idêntica ao GO, foi aproveitado o código do ProteInOn para, com as devidas adaptações, se poder ter esta funcionalidade no CMPSim.

5.1.3 Guia

Para as futuras ferramentas ou funcionalidades é necessário ter em conta dois pontos: i) a formatação dos resultados em quatro formatos diferentes, TSV, CSV, JSON e XML; ii) e a possibilidade de informação adicional pedida pelo utilizador. É então sugerido que: i) para novas funcionalidades (ontologias biomédicas já em uso) seja primeiro feito um resultado base para cada um dos formatos (TSV, CSV, JSON e XML), de modo a ser o mais transversal possível para as diferentes ontologias biomédicas, e só depois especificar todos os formatos base para cada ontologia em uso; ii) no caso de novas ferramentas, com utilização de outras ontologias biomédicas e as mesmas funcionalidades (as que sejam aplicáveis a essas ontologias), sejam utilizados os formatos base apresentados no Capítulo 4 (4.4 Resultados). Para as novas ferramentas é ainda sugerido seguir a estratégia tomada quer no ProteInOn como no CMPSim, de ter um argumento opcional (como último argumento da chamada dos scripts) para as informações adicionais pedidas pelo utilizador.

5.2 Front-End

Tal como já foi dito, a actualização do Front-End teve dois propósitos : i) por um lado, fazer com que as páginas web das ferramentas usassem os serviços web criados; ii) por outro lado, dar ao utilizador mais funcionalidades e tornar a página dinâmica não aumentando a carga de informação trocada com o servidor.

39

5.2.1 ProteInOn

No caso do ProteInOn a actualização do Front-End foi um processo facilitado, pois já tinha sido feito por mim uma actualização deste, anteriormente. Esta actualização teve assim dois passos: i) trocar os serviços web anteriormente utilizados pelos que foram criados (arquitectura RPC) e ii) processar os resultados para visualização destes. Em relação ao primeiro ponto, como todo o Javascript (AJAX) já tinha sido escrito, foi só alterar o URL do XMLHTTPRequest pelos respectivos endpoints (SSM e Characterization) e o conteúdo do envelope (SOAP). Em relação ao segundo ponto implementei dois processos: i) criei um ciclo que percorre todos os resultados e introduz estes numa tabela HTML e ii) criei um pequeno módulo Javascript que permite a páginação da tabela de resultados e a ordenação destas.

5.2.2 CMPSim

A actualização do Front-End do CMPSim foi um processo que se fez em mais passos. i) foi modificar o Front-End de modo a receber mais que dois compostos ou vias metabólicas, para tal, foram substituídas as duas etiquetas “input” por uma “text-area” e incluído uma “select” (drop-down list), ii) foi também necessário escrever todo o código Javascript, pois esta ainda era uma simples página estática, onde se inclui a utilização dos serviços web criados no XMLHTTPRequest, iii) por último, foi utilizado o pequeno módulo criado anteriormente (ProteInOn) para manipular a tabela de resultados.

5.2.3 Exemplos

Tal como indiquei, a integração dos serviços web no Front-End é a partir da função XMLHTTPRequest do Javascript, na Figura 22 encontra-se um exemplo de como fazer essa chamada.

function Request( url , query , param , measure , goType , IEA ) { xmlhttp = null;

if ( window.XMLHttpRequest ) { xmlhttp = new XMLHttpRequest( ); }

else {

xmlhttp = new ActiveXObject( "Microsoft.XMLHTTP" ); }

40

if (xmlhttp.readyState==4 && xmlhttp.status==200) { respostaJSON = eval('(' + xmlhttp.responseText + ')'); for( var i in respostaJSON['Char'] ) {

... } } }

xmlhttp.open( "POST" , url+"/BOA/SSM/" , true );

xmlhttp.setRequestHeader( 'SOAPAction' , url+'/BOA/SSM/' ); xmlhttp.setRequestHeader( 'Content-Type' , 'application/json' ); var xml = '<?xml version="1.0" encoding="utf-8"?>' +

'<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ' + 'xmlns:xsd="http://www.w3.org/2001/XMLSchema" ' + 'xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">' + '<soap:Body> ' + '<BOArequest xmlns="http://www.webserviceX.NET/"> ' + '<query>' + query + '</query> ' +

'<acc>' + param + '</acc> ' +

'<measure>' + measure + '</measure> ' + '<goType>' + goType + '</goType> ' + '<IEA>' + IEA + '</IEA> ' +

'<include>name</include> ' + '</BOArequest> ' + '</soap:Body> ' + '</soap:Envelope>'; xmlhttp.send( xml ); }

Figura 22 – Exemplo de um pedido XMLHTTPResquest para os serviços web arquitectura RPC

Mas não é só a partir de Javascript que se pode aceder aos serviços web, e também não é obrigatório que sejam utilizados os serviços web de arquitectura RPC, na Figura 23 está um exemplo de como aceder aos serviços web de arquitectura RESTful a partir de um script em Perl.

#!/usr/bin/perl use strict; use warnings;

# Create a user agent object use LWP::UserAgent;

my $ua = LWP::UserAgent->new; $ua->agent("MyUserAgent");

#array containing the ids to be processed

my @id = (28385,28386,28387,28388,28389,28390); my $ids = join(',',@id);

41 my $req = HTTP::Request->new(GET =>

"http://xldb.fc.ul.pt/biotools/BOA/Chebi/compound/$ids/SSM/measure/sim GIC");

$req->content_type('text/tab-separated-values');

# Pass request to the user agent and get a response back my $res = $ua->request($req);

# Check the outcome of the response if ($res->is_success) {

my $result = $res->content;

my @result = split(/\n/, $result); my $index=0;

while ($index < @result) {

if ($result[$index] =~ m/\d+\t*\d+\t*\d+.\d+\s*/ig) { print "$index:\t$result[$index]\n"; } $index++; } } else { print $res->status_line, "\n"; }

43

Capítulo 6 Conclusão

Em modo de conclusão, todos os objectivos, principais e secundários, foram concluídos com sucesso. Foi criada uma nova framework para o projecto BOA, onde i) foram criados serviços web que permitem a ligação entre Back-End e Front-End, para além de permitirem a utilização entre todo o tipo de utilizadores, ii) foram feitas alterações no Back-End de modo a serem disponibilizados os resultados em diferentes formatos e iii) foram feitas também alterações no Front-End tornando as páginas das ferramentas dinâmicas com recurso a tecnologia AJAX.

6.1 Framework do BOA

A criação de uma nova framework do BOA era o objectivo principal, para tal tinha sido proposto a criação de serviços web que servissem de mediador entre as ferramentas criadas pelo grupo e as respectivas páginas web. Estes serviços web foram concluídos com sucesso, estando desde já operacionais. Fazendo também parte desta framework, mas sendo objectivos secundários, as modificações do Back-End e Front- End também foram executadas com sucesso.

6.1.1 Mediador

No que diz respeito aos serviços web houve uma alteração importante em relação ao inicialmente proposto. Estava previsto a criação de serviços web numa arquitectura RESTful, mas devido a limitação de caracteres do URL (à volta de 2000 caracteres) e da capacidade das nossas ferramentas (um limite de 1000 proteínas/termos GO/vias metabólicas/compostos químicos que daria mais de 6000 caracteres), decidi implementar os serviços web em duas arquitecturas diferentes, RESTful e RPC. Embora a arquitectura RPC não tenha esta limitação, não é uma arquitectura aconselhada a utilizadores sem conhecimentos de informática, que é o caso de alguns dos nossos utilizadores. Esta alteração levou a um atraso relativamente ao planeamento inicial de

44

cerca de um mês. Mas esta alteração permitiu ter um mediador capaz de satisfazer todos os requisitos, i) comunicação entre Back-End e Front-End e ii) permite à comunidade científica a integração das nossas ferramentas e funcionalidades nos seus projectos (quer tenham ou não conhecimentos de informática).

6.1.2 Back-End

Em termos de Back-End foram então alterados os diversos scripts de modo a disponibilizar os resultados nos diferentes formatos escolhidos, TSV, CSV, XML e JSON. Em termos dos formatos foi tomada a decisão de, em caso de omissão, serem enviados os resultados i) no formato TSV, para a arquitectura RESTful, pois é um formato de fácil compreensão para humanos o que faz sentido pois esta arquitectura foi precisamente escolhida por ser fácil de usar pelos utilizadores; ii) e no formato JSON, para a arquitectura RPC, pois é um formato que é interpretado directamente por diversas linguagens de programação (por exemplo: Javascript e Python). De salientar também a modificação do script do CMPSim de modo a permitir mais que dois compostos químicos ou vias metabólicas com lista de entrada.

6.1.3 Front-End

Em relação ao Front-End as alterações feitas foram divididas em duas partes, i) por um lado tornar as páginas dinâmicas com recurso à tecnologia AJAX e ii) por outro lado passar a utilizar os serviços web criados. A única decisão que tomei neste ponto foi a criação de um pequeno módulo em Javascript de modo a poder manipular a tabela de resultados. Esta decisão foi tomada pois os diferentes módulos encontrados, criados por outros, não estavam a funcionar em pleno. Esta decisão não alterou o planeamento pois aproveitei o facto da página web do ProteInOn já ser uma página dinâmica (AJAX) e assim as alterações a executar eram de rápida implementação. Implementei também o módulo de modo a ser facilmente integrado na página web do CMPSim (e de futuras páginas web de outras ferramentas do grupo). De notar que, a par do Back-End, também foi alterada a página web do CMPSim de modo a permitir a introdução de mais que dois compostos químicos ou vias metabólicas como lista de entrada.

45

6.2 Planeamento

Tal como já foi referido, algumas das decisão tomadas levaram a um atraso no planeamento deste trabalho. O principal motivo foi a opção de implementar duas arquitecturas ao invés de uma. Esta decisão aumentou o tempo de execução da tarefa 2. Esta tarefa passou de 2 meses para 3, mas também aumentou ligeiramente o tempo da execução das tarefas 3 e 5 (passando de 4 semanas para 5). Apesar da modificação nos serviços web, as tarefas 4 e 6, referentes ao back-end e front-end respectivamente, não sofreram alterações. Em suma este projecto teve um atraso de 9/10 semanas, a Tabela 6 tem a calendarização seguida neste projecto.

Tabela 6 – Indicação das tarefas e início e fim da execução destas.

Tarefa Início Fim

1 – Escrita relatório preliminar 1 Setembro 31 Outubro

2 – Serviços web 1 Novembro 31 Janeiro

3 – Teste e integração 21 Janeiro 21 Fevereiro

4 – Back-end 15 Fevereiro 15 Abril

5 – Teste e integração 21 Abril 21 Maio

6 – Front-end 15 Maio 15 Julho

7 – Escrita tese 15 Julho 15 Outubro

As tarefas apresentadas são as seguintes: 1 – escrita do relatório preliminar; 2 – implementação dos serviços web; 3 e 5 – teste das tarefas anteriores e integração com as seguintes; 4 – modificações no back-end; 6 – modificações do front-end e 7 – escrita da tese.

6.3 Trabalho Futuro

Em relação ao trabalho futuro, podemos dividir em duas partes: i) melhorias ao trabalho executado e ii) e extensões ao trabalho executado que agora podem ser feitas com maior facilidade e um maior nível de integração.

No que diz respeito às melhorias do trabalho executado, embora se tenham cumprido os objectivos propostos, existem alterações possíveis de realizar: i) aumentar o número de formatos disponibilizados, ii) permitir no CMPSim a utilização dos

46

resultados obtidos como entrada para uma nova pesquisa, tal como acontece no ProteInOn e iii) criar uma ligação entre o ProteInOn e o CMPSim (já existe uma versão alfa). Em termos das extensões ao trabalho executado: i) a criação de novas ferramentas com base noutras ontologias biomédicas, com base no trabalho feito para o GO e o ChEBI, ii) novas ferramentas que utilizem funcionalidades das ferramentas já existentes e a iii) criação de novas funcionalidades para as ferramentas já criadas.

47

Capítulo 7 Bibliografia

1. Smith, B. Blackwell Guide to the Philosophy of Computing and Information Blackwell Guide to the Philosophy of Computing and Information. s.l. : Oxford: Blackwell, 2003, p. chapter Ontology: An Introduction.

2. linkeddata. [Online] http://linkeddata.org/.

3. Charro, N., Hood, B.L., Pacheco, P., Azevedo, P., Lopes, C., Almeida A.B.,

Faria, D., Couto, F.M., Conrads, T.P., Penque, D. Serum Proteomics Signature of

Cystic Fibrosis Patients: a Complementary 2-DE and LC-MS/MS Approach. Journal of Proteome Research. 2010.

4. The Gene Ontology Consortium. Gene Ontology: tool for the unification of biology. Nature Genetics. 25, 2010, pp. 25–29.

5. The UniProt Consortium. The Universal Protein Resource (UniProt). Nucleic Acids Research. 2010, Vol. 38, Database issue, pp. D142-D148.

6. Pesquita, C., Faria, D., Bastos, H., Ferreira, A., Falcão, A., Couto F.M. Metrics for GO based protein semantic similarity: a systematic evaluation. BMC Bioinformatics. 2008.

7. Couto, F.M., Silva, M.J., Coutinho, P.M. Semantic similarity over the gene ontology: Family correlation and selecting disjunctive ancestors. Proceedings of the ACM Conference in Information and Knowledge Management. 2005.

8. Pesquita, C., Faria, D., Falcão, A.O., Lord, P., Couto, F.M. Semantic Similarity in Biomedical Ontologies. PLoS Computational Biology. 2009.

9. Faria, D. Pesquita, C., Couto F.M., Falcão A. ProteInOn: A Web Tool for Protein Semantic Similarity. DI/FCUL TR 07-6, Department of Informatics, University of Lisbon. 2007.

10. Leonard Richardson, Sam Ruby. RESTful Web Services. 2007. 0-596- 52926-0.

11. Aranda, B., et al., et al. The IntAct molecular interaction database. Nucleic Acids Research. 2010, Vol. 38, Database issue, pp. D525-D531.

48

12. Degtyarenko, K., et al., et al. ChEBI: a database and ontology for chemical entities of biological interest. Nucleic acids research. 2007.

13. Gentleman, R. Visualizing and Distances Using GO. [Online] 2005. http://www.bioconductor.org/docs/vignettes.html.

14. Semantic similarity based on corpus statistics and lexical taxonomy. Jiang, J.

e Conrath, D. Taiwan : s.n., 1997. Proceedings of the 10th International Conference on

Research on Computational Linguistics.

15. Kanehisa, M., et al., et al. From genomics to chemical genomics: new developments in KEGG. Nucleic acids research. 2006, Vol. 34, Database Issue, p. D354.

16. An information-theoretic definition of similarity. Lin, D. 1998. Proceedings of the 15th International Conference on Machine Learning. pp. 296–304. San Francisco, CA: Morgan Kaufmann.

17. Lord, P., et al., et al. Investigating semantic similarity measures across the Gene Ontology: the relationship between sequence and annotation. Bioinformatics. Vol. 19, pp. 1275–1283.

18. Using information content to evaluate semantic similarity in a taxonomy.

Resnik, P. 1995. In Proc. of the 14th International Joint Conference on Artificial

Intelligence.

19. Hugo Bastos, Bruno Tavares, Cátia Pesquita, Daniel Faria, Francisco

Couto. Application of Gene Ontology to Gene Identification. In Silico Tools for Gene

Discovery: Methods in Molecular Biology. s.l. : Springer, 2011.

20. The Biomedical Ontology Applications (BOA) framework. Bruno Tavares,

Hugo Bastos, Daniel Faria, João Ferreira, Tiago Grego, Cátia Pesquita. USA :

Documentos relacionados