Metodologia para a Concepção e Construção de Sistemas de IR

Este capítulo descreve a metodologia proposta para a concepção e construção de um sistema de IR, usando a linguagem IR (vid. Capítulo 3), a biblioteca de modelos abstracta para IR (vid. Capítulo 4) e uma infra-estrutura disponível (OpenFTS).

5.1 Motivação

Actualmente não existe uniformização de conceitos de sistemas para a IR, pois a generalidade da investigação na área da IR é orientada essencialmente para os processos e algoritmos e não para os sistemas. Dos sistemas comerciais pouca informação está disponível e o número de sistemas académicos não é significativo, sendo habitualmente desenvolvidos por grupos de investigação, da área de IR, orientados essencialmente aos processos e aos algoritmos (vid. Secção 2.8).

O objectivo proposto neste trabalho é conceber e criar sistemas que se possam adaptar às diferentes necessidades dos utilizadores de sistemas de IR e contribuir desta forma para o desenvolvimento da IR. Os principais desafios na construção de sistema de IR são:

− Capacidade de armazenamento e manipulação de informação. Devido à grande quantidade de informação, é necessário construir representativos que permitam aceder aos documentos de uma forma rápida e fiável. Este problema é comum a todos os sistemas de recuperação.

− Capacidade de poder computacional para suportar a comparação entre os representativos de informação e as necessidades de informação dos utilizadores. Existem diversos algoritmos de comparação, que implementados no sistema permitem explorar diferentes abordagens. A forma de comparação ou a introdução de módulos de combinações, classificação e o cálculo das medidas de hubs e autoridades são as principais diferenças entre os sistemas de recuperação criados. − Permitir a melhoraria dos resultados, pela introdução de processos de optimização,

entre os quais se destacam os algoritmos de retroacção e de combinação de resultados. Nesta linha de pensamento é interessante incluir o uso do espaço de conhecimento, nomeadamente os sistemas de classificação, dicionários e comunidades.

− Satisfazer o utilizador, ou seja, encontrar a generalidade dos documentos relevantes.

− Se for um sistema de teste deve operar num ambiente controlado, de forma a poder medir-se o desempenho ou eficácia do sistema.

5.2 Metodologia

A metodologia, para além da sequência de etapas e procedimentos recomendados para serem aplicados durante o processo de desenvolvimento de sistemas de informação (neste caso sistemas de IR), inclui a utilização de um conjunto de ferramentas, técnicas e notações (Booch 94), adaptados à IR.

Figura 5.1: Principais actores na produção de sistemas de IR

As metodologias orientam o processo de construção, permitindo o desenvolvimento de sistemas melhor adaptado às necessidades específicas dos seus utilizadores.

A metodologia proposta é orientada ao desenvolvimento de IR-System, sendo apresentada na Figura 5.2 uma visão geral e simplificada do fluxo de actividades. São evidenciados os principais actores e as suas respectivas actividades, ilustrados na Figura 5.1: P ro d u ç ã o S is te m a s IR A rq u ite c to E n g . R e q u is ito s M o d e la d o r C lie n te \U tiliz a d o r P ro g ra m a d o r In te g ra d o r

− O Arquitecto é responsável pela definição: (1) da linguagem IRML (vid. Capítulo 3); (2) dos modelos abstractos de IR (vid. Capítulo 4); (3) da selecção da plataforma IR (vid. Capítulo 6); (4) processos/templates de geração (vid. Secção 5.2.1).

− O Engenheiro de Requisitos é o responsável pelo levantamento dos requisitos, Na Engenharia de Requisitos, primeira fase do ciclo de vida do desenvolvimento de software, um dos grandes desafios é a obtenção de requisitos que sejam os mais precisos possível para possibilitarem um bom entendimento do que é desejado e esperado do produto final do processo (Sommerville 1997), (Kotonga 1998) e (Zanlorenci 1998).

− O Modelador (designer) responsável pela concepção do sistema de IR. É realizada a definição detalhada da arquitectura global da solução (módulos, tabelas, interface, máquinas, etc).

− O Programador tem a tarefa de programação dos diversos componentes do sistema por meio da abordagem MDA.

− Integrador, é necessário a intervenção do engenheiro de testes e de integração

para planear e realizar os vários testes e garantir que os requisitos são suportados de acordo com os níveis de qualidade inicialmente definidos. (Esta intervenção está sugerida ao nível da actividade “Preparar, Realizar Testes e Integração de Sistemas de IR”).

O presente trabalho de investigação aplica a metodologia até ao papel do modelador.. De acordo com a metodologia, o ênfase deve ser reforçado nas actividades de concepção e projecto e, consequentemente, o esforço nas actividades de produção deve ser minimizado e realizado tanto quanto possível de forma automática, tal como acontece noutras indústrias, como por exemplo na indústria automóvel, alimentar ou farmacêutica. Os aspectos relacionados com o “como fazer” são relevantes, mas são tratados principalmente pelos arquitectos de software que são os responsáveis por providenciar arquitecturas elegantes, flexíveis e reutilizáveis.

As principais actividades são ilustradas na Figura 5.2: (1) definição da linguagem IRML (Capítulo 3); (2) definição dos modelos abstractos de IR (Capítulo 4); (3) definição e escolha da infra-estrutura de IR; (4) definição dos templates e do processo de geração do código; (5) levantamento dos requisitos; (6) concepção do sistema; (7) produção do sistema de IR, com base na aproximação MDA; (8) preparação, realização de testes e integração do sistema de IR .

Figura 5.2: Metodologia proposta para a concepção de sistemas de IR.

Arquitecto

As actividades realizadas pelo arquitecto de software, ilustradas na Figura 5.2, consistem genericamente na definição de todos aspectos arquitecturais de suporte ao adequado funcionamento do sistema de IR: (1) definição da linguagem IRML; (2) definição dos modelos abstractos de IR; (3) define e selecciona a infra-estrutura existente; (4) definição do template/processo de geração

Note-se que estas actividades desenvolvidas pelo arquitecto são realizadas de forma independente do desenvolvimento específico de cada sistema de informação concreto.

Selecção da Infra-Estrutura

Os sistemas de IR exigem uma base de dados robusta e um processo de indexação eficiente. A construção de raiz deste tipo de módulos tornaria o processo bastante lento e implicaria um elevado volume de trabalho. Dada a oferta existente no mercado, é de bom senso procurar uma infra-estrutura e adaptá-la ao problema em questão. Das alternativas existentes por volta do ano de 2000, e de modo a não implicar encargos

In te gr a dor M ode la dor ( D e s ign) P ro g ram ad o r ( D evel o p e r) E ng. R e qui s it o s A rqui te c to D e fin e Ling ua g e m IR M L D e fin e M od e los A bs tra c tos de IR D e fin e e S e le c c iona

Infra -E s trutura d e IR D e fine Te m pla te s / P roc e s s os de G e ra ç ã o « IR -L a n g u a g e » :IR M L L e v a n ta m e nto de R e quis itos :B ilb io te c a M o de lo s IR

:Infra -E s tru tura IR

:E s pe c ific a ç ã o de R e qu is ito s (O bj e c tiv o s ) C on c e p ç ã o d o S is te m a de IR :V is ta C a s os d e U tiliza ç ã o (IR M L-b a s e d) :V is ta In fo rm a ç ã o (IR M L -b a s e d) :V is ta d e P roc e s s os (IR M L-ba s e d ) e .g . O p e n FT S P ro duz S is te m a de IR , v ia M D A a p pro a c h P re pa ra r, R e a liza r Te s te s e In te gra ç ã o d e S is te m a de IR « IR -S yste m » :S is te m a IR (qua s e c o m ple to) « IR -S yste m » :S is te m a IR (fin a l) :Te m p la te d e G e ra ç ã o A rq uite c to E ng. R e quis itos M o de la dor (D e s ig n) P rogra m a d or (D e v e lo pe r) Inte g ra d or :M otiv a ç ã o u sa u sa p ro d u z p ro d u z p ro d u z b a se a d o e m

financeiros e ter uma base de dados robusta (postgresql) e uma estrutura modular, escolheu-se a infra-estrutura OpenFTS baseada na base de dados postgresql (vid. Capítulo 6).

Definição de Templates/Processos de Geração

Esta actividade pode ser decomposta em duas; (1) definição do template de suporte à transformação T2 (vid. Figura 5.6), de modelos em formato XMI para formato XIS/XML; e (2) definição de templates de arquitecturas de software de suporte à transformação T3 (vid. Figura 5.6), de modelos em formato XIS/XML para artefactos digitais, tais como componentes de software. Note-se que estas actividades desenvolvidas pelo arquitecto são realizadas de forma independente do desenvolvimento específico de cada sistema de informação concreto.