Faculdade de Engenharia da Universidade do Porto

Licenciatura em Engenharia Informática e Computação

LABORATÓRIO DE INFORMÁTICA AVANÇADA

Relatório de Especificação de Requisitos

Pesquisa Em Arquivos

Março de 2002

Hugo Marques – ei98043@fe.up.ptPedro Andrade – ei98030@fe.up.pt

2

Índice

PáginaI. Introdução

Objectivo do projecto ............................................................... 3

Enquadramento do sistema a desenvolver nonegócio/organização ................................................................

3 - 4

Riscos ...................................................................................... 4

II. Requisitos do sistema

Descrição geral dos requisitos do sistema a desenvolver ....... 5 - 8

III. Modelo de casos de utilização

Visão geral ............................................................................... 9 - 10

Actores ..................................................................................... 10

Casos de utilização .................................................................. 11 -16

IV. Requisitos suplementares ............................................................. 17

V. Modelo de classes do domínio

Módulo de Unidade de Descrição (UD) ................................... 18-20

Módulo Criador ........................................................................ 21

Módulo Proprietário ................................................................. 22 - 23

VI. Notas finais ................................................................................... 24

VII. Glossário ...................................................................................... 25

3

I. INTRODUÇÃO

Objectivos

O objectivo deste projecto é basicamente o de criar métodos depesquisa que possam ser aplicados a arquivos gerais, isto é, arquivos quepodem ser utilizados seja qual for o seu domínio. Isto envolve uma questãoque pode criar um problema: como aproveitar a estrutura conhecida de umarquivo genérico (estrutura da base de dados) para devolver as informaçõesque se pretendem. É este objectivo que nos propomos atingir com autilização de 3 métodos de pesquisa. O primeiro será uma pesquisa “normal”,mais conhecida por pesquisa por formulário, e que, como é do conhecimentogeral, se trata de uma consulta em que mediante o preenchimento de umformulário é devolvida uma resposta, que neste caso serão documentos queestejam dentro dos parâmetros especificados. A segunda trata-se de umapesquisa por palavras chave. Este tipo de pesquisa é muitas vezes utilizadopara obter páginas web através de um browser. O objectivo é o utilizadorintroduzir uma série de palavras que estejam relacionados com o quepretende procurar, para que lhe sejam devolvidos documentos quecontenham essas palavras. A terceira pesquisa está destinada aofornecimento de serviços, eventualmente a outros arquivos, através deconceitos (conhecidos e perfeitamente definidos em ambos os arquivos)como criador, detentor e documentos.

Para este projecto ter viabilidade pressupõe-se a existência de umabase de dados já criada e cujos dados já estejam introduzidos, não havendoda nossa parte qualquer responsabilidade, no âmbito deste projecto, nacomponente de alteração e validação dos dados, nem na criação da base dedados propriamente dita.

Neste projecto, os objectivos são também a utilização da comunicaçãodas aplicações através de webservices sobre SOAP, bem como o recurso aoconceito de extreme programming (xp)

Enquadramento do sistema na organização

Qualquer instituição pública (e não só), por natureza própria, produzmaterial susceptível de ser arquivado; seja um estabelecimento de ensino, desaúde, de justiça... Deste modo, um estabelecimento de saúde, necessitaque seja constantemente guardada informação histórica relativa por exemploaos seus pacientes, como radiografias, electrocardiogramas, e outrosexames; ou das doenças conhecias, ou outro qualquer tipo de informação.

4

De qualquer modo, devemos acrescentar que, neste projecto, a base dedados, não está de acordo com quaisquer dados relativos a um serviço desaúde, mas de um arquivo do Eça de Queirós já existente. Importa mesmoassim referir que tal facto nada altera o conteúdo e os objectivos dadisciplina.

Riscos

Os riscos subjacentes ao projecto estão relacionados com escolhasque teremos de fazer e que de certo modo poderão condicionar o resultadofinal do trabalho. Assim, uma das dificuldades estará na escolha dos campos(e a sua pontuação, no caso de se tratar de uma consulta por chave), quevão ser seleccionados, e sobre os quais assentarão as consultas. Outroproblema poderá passar pela definição dos conceitos para os serviços queirão ser disponibilizados, isto é, saber claramente que campos é que estão,de uma forma consensual, relacionados com os conceitos que iremosabordar. Por fim, a tecnologia também poderá ser um risco, uma vez quepara nós a utilização de webservices é uma novidade.

5

II. REQUISITOS DO SISTEMA A DESENVOLVER

Descrição geral dos requisitos

Basicamente o sistema destina-se a consultar um arquivo genérico.Foi-nos pedido que executássemos 3 operações de consulta: duas delasvisando um utilizador comum e a outra uma entidade externa (electrónica ounão). É sobre estas três consultas e o cada uma delas implica que nosiremos debruçar.

Consulta por chave

A consulta por chave é destinada ao utilizador que queira informaçãorelacionada com algumas palavras que servem como chaves, isto é, quequeiram obter unidades de descrição sem conhecerem a estrutura da basede dados. O objectivo será simplesmente devolver, como resultado dapesquisa, unidades de descrição que estejam relacionadas com as palavrasque se introduziram. Esta consulta deve ser realizada por nós campo acampo de todas as tabelas relacionadas (directa ou indirectamente) com osdocumentos, atribuindo uma classificação distinta consoante o campo emque as palavras aparecem. Assim a classificação final vai ser tanto maiorquanto mais vezes as palavras aparecerem em campos considerados maisimportantes.

A saída deve devolver todas as unidades de descrição queconcordem, de acordo com o que nós especificarmos, com as palavrasintroduzidas pelo utilizador, devendo estas estar ordenadas de formadecrescente de classificação. Um exemplo mais claro deste tipo de consultasé um motor de pesquisa como o sapo, altavista, google...

Consulta por formulário

O conceito de consulta por formulário pressupõe um conhecimentoprévio por parte de quem consulta, de alguns campos que existem na basede dados. Deste modo, deve ser apresentado ao utilizador um formulário comos campos que serão definidos pela nossa cliente, como mais importantes. Éneste momento certo, contudo, que farão parte deste formulário dadosrelativos a documentos, criadores e detentores (eventualmente as suaschaves e descrições entre outros campos). Os resultados das pesquisasdeverão ser sempre as unidades de descrição que estejam dentro dos

6

parâmetros especificados. Uma vez que as unidades de descrição possuemuma hierarquia, isto é, têm uma estrutura semelhante a directórios, estáespecificado como requisito que nos resultados da pesquisa, se existiremvárias unidades de descrição que apareçam dentro de outras na resposta dapesquisa, deve aparecer em primeiro lugar a unidade do nível mais acimaencontrada e abaixo desta, mas no mesmo tópico as restantes unidadesencontradas. Analogamente, no nosso exemplo de directórios, secompararmos as drives (C,D...) a arquivos, e se efectuarmos uma pesquisaem que apareçam dois directórios como resultado de uma pesquisa, em queum deles está na sub-árvore inferior do outro, só aparece o directório quetiver o nível mais alto como tópico as ocorrências dos seus filhos agrupadasabaixo (Fig1 e Fig2).

Na base de dados que possuímos existe contudo um conceito deherança em alguns campos das unidades de descrição e que sãoimportantes para descrever essas mesmas unidades de descrição,nomeadamente o conceito de criador e de detentor. Deste modo, nosresultados da pesquisa deve aparecer sempre os dados relativos a estesconceitos, mesmo que estejam num nível mais acima do que o mais altoencontrado (Fig3).

Arquivode

DoençasHepatite A

Hepatite

Hepatite BHepatite C

Meningite Tipo 1Meningite

Meningite Tipo 2Meningite Tipo 3

Fig. 1 – Exemplo de um arquivo de doenças onde cada doença corresponde a uma unidadede descrição da nossa base de dados.

Hepatite

Hepatite A

Hepatite B

Fig. 2 – Exemplo de uma pesquisa em que os resultados tenham sido as unidades dedescrição Hepatite, Hepatite A e Hepatite B

7

Consulta por conceito

A consulta por conceito pressupõe uma entidade externa que podeperfeitamente ser outro arquivo que pode desconhecer a estrutura do arquivojá implementado. Deste modo, a única coisa que o arquivo externo necessitade conhecer são conceitos que estejam definidos e sejam consensuais, comopor exemplo, para todos os arquivos existir um detentor que é definido por:

- um nome,- um tipo de detentor- se é uma cópia,- materiais associados,- quem é que detém e em que momento a custódia do arquivo, ...

ou um criador definido por:- uma identificação,- um tipo de criador,- uma data de criação- um local associado, ...

ou um documento definido por:- uma descrição,- um título e subtítulo,

Hepatite

Hepatite A

Hepatite B

João António

Fig 3 – A informação sobre o criador (João António) e o detentor (Arquivo doHospital do Porto) provém da unidade Arquivo de Doenças(Fig1).

Arquivo do Hospital do Porto

Unidades de descrição relacionadas:

João AntónioArquivo do Hospital do Porto

João AntónioArquivo do Hospital do Porto

8

- qual o documento acima,- qual o esquema e o nível em que se insere o documento, ...

Deste modo, a consulta realizar-se-á mediante um webservice quedisponibilize os dados que se pretenderem, isto é, disponibiliza, entre outros,os campos especificados acima mediante a apresentação de alguns dessescampos preenchidos. De uma forma geral, esta consulta será semelhante àconsulta por formulário, mas para além de ser utilizado um webservice para aefectuar, os resultados serão relativos, não só a unidades de descrição, mastambém a conceitos relacionados com criadores e detentores.

9

III. MODELO DE CASOS DE UTILIZAÇÃO

Visão Geral

Fig. 4 - Diagrama de casos de uso

No diagrama de caso de uso do nosso projecto verifica-se logo àpartida a existência de quatro actores: responsável do arquivo, arquivista,utilizador comum e entidade externa que serão descritos com mais pormenorno tópico seguinte. Sobre os actores há que referir o facto de o utilizadorcomum ser uma generalização do arquivista uma vez que o arquivista pode,ele próprio, ser um utilizador comum.

10

No que diz respeito às acções do diagrama, a cada utilizador cabe-lheunicamente uma função, excepto no caso do utilizador comum onde existemduas funções. Estas duas funções são consultas de documentos masaparecem individualizadas pelo facto de estarem assentes em objectivos epressupostos de implementação distintos.

Actores

Responsável do arquivo

Ao responsável pelo arquivo cabe o papel de definir os esquemasusados no arquivo. Assim, é o responsável do arquivo que define de quemodo, ou seja, segundo que organização e sobre que características é queos diversos documentos são classificados para serem arquivados.

Desta forma é o responsável do arquivo que cria as bases para oarquivista executar as suas funções. As funcionalidades relativas a este actornão são implementadas neste projecto.

Nota: Para mais informações sobre este item consultar adocumentação do projecto MetaMedia

Arquivista

Sobre o arquivista recaem basicamente duas funções: a de recolher ainformação desejada e inserir os dados na base de dados. Estas duasfuncionalidades também não são, por nós, implementadas no âmbito desteprojecto.

Utilizador Comum

O utilizador comum tem como principal função a pesquisa de dados nabase de dados. Para isso pode fazer uso dos dois tipos consultas que para sisão reservadas – por formulário e por palavras-chave.

11

Serviços externos

Este actor representa todo um conjunto de serviços externos querealizam consultas sobre o arquivo. A função deste actor é então a de realizarpesquisas na base de dados usando webservices.

Casos de Utilização

O modelo de domínio parcial não irá ser apresentado nesta secção,uma vez que os casos de usos utilizam quase sempre as mesmas classes.Deste modo, sempre que quisermos relacionar o caso de uso com as classesdo domínio fazemos uma referência para o capítulo V - Modelo de Classes doDomínio.

Definir os esquemas do arquivo

Este caso de uso consiste na definição e implementação do esquemade armazenamento dos documentos geridos pelo arquivo.

A definição dos esquemas do arquivo não será alvo de implementaçãoneste projecto pelo facto de não ser um dos requisitos do mesmo. É apenasapresentado para clarificar o contexto do nosso trabalho.

Recolher informação e armazenar na base de dados

Este caso de uso tem como objectivo recolher informação sobre umarquivo e armazená-la na base de dados, ou seja, a partir de qualquer tipo deinformação existente ou novos dados recolhidos de uma qualquer fonte,introduzi-los numa base de dados usando a estrutura definida peloresponsável do arquivo.

Consultar documentos por palavras-chave

Este caso de uso corresponde ao uso que um utilizador comum faz,quando deseja efectuar uma pesquisa e não possui informação concreta

12

sobre os campos que vai pesquisar. Assim, pelo facto de não haverconhecimento sobre a estrutura da base de dados em causa, a pesquisa éfeita por palavra-chave, ou seja, através de um conjunto de palavras quecaracterizam o que o utilizador deseja consultar (consulta não estruturada). Ainformação introduzida é analisada e como resposta é exibida uma lista deUnidades de Descrição (UD’s), que contêm dados diversos sobre o que seintroduziu, classificadas e ordenadas por valor. Esta valorização é feita combase na proveniência (entenda-se campos da base de dados) dos atributosque se está a pesquisar. Cada campo possui um peso específico o que assimpermite a classificação e respectiva resposta como um “ranking de UD’s”.

Fig. 5 - Diagrama de sequência

A sequência de funcionamento é a apresentada em cima (Fig5).Basicamente o utilizador comum introduz o conjunto de palavra-chave faceao que deseja encontrar e em seguida o Sistema de Gestão do Arquivo(SGA) responde tal como especificado atrás.

A interface com o utilizador quer a nível de entrada de dados, quer anível de saída de dados está representado genericamente na Fig6. Aspalavras-chave são inseridas usando uma text box e o resultado da pesquisaé apresentado por ordem de classificação obtida. Cada documento possui umlink que exibe toda a informação que este contém.

Tal como neste caso de uso, nos seguintes casos de utilização estetópico será tratado do mesmo modo. Contudo esta consulta pesquisa utilizatodas as classes do domínio exposto mais adiante.

13

Fig. 6 - Interface com o utilizador

Consultar documentos por formulários

Tal como no caso de uso anterior, neste pretende-se que o SGAresponda a uma pesquisa de um utilizador comum. A grande diferençacentra-se no facto de neste caso o utilizador comum possuir umconhecimento mais elevado dos campos que deseja pesquisar. Assim, apesquisa passa a ser estruturada, isto é, em vez de se basear em palavras-chaves, a consulta é realizada com base num formulário. Este formuláriocontém os atributos mais importantes quer das unidades de descrição querdos criadores. Dentro dos atributos a incluir no formulário encontram-se aschaves primárias, que descrevem unicamente os diversos dados e algunscampos de datas (estes últimos muito importantes neste tipo de pesquisas).

14

Neste caso de uso o resultado dado pelo SGA é um conjunto de UD’sque contêm textualmente a informação que foi introduzida no formulário deacordo com os respectivos campos da base de dados. O resultado deveráser sempre simplificado, ou seja, as UD's de nível inferior que contêminformação igual ao seu "pai" não deverão constar de forma directa naresposta (contudo poderão entrar com sub-itens). Nestes casos, na respostaé então associado um link que permite navegar por entre a sub-árvore do“pai”, de modo a ser possível visualizar também os filhos. No caso de as UD’sserem “irmãs” aparecem ambas na resposta.

Fig. 7 - Diagrama de sequência

De modo semelhante ao caso de uso anterior, a sequência de acçõesdeste caso de uso envolve: em primeiro o utilizador comum preenche oformulário com dados de acordo com a pesquisa que pretende efectuar. OSistema Geral de Arquivo (SGA) responde então de acordo com o descritoem cima.

Sobre a interface com o utilizador para este caso de uso são tambémapresentados esquemas para a entrada e para a saída de dados. Na entradade dados são exibidas algumas text boxes referentes a alguns campos dabase de dados (os campos exibidos não são obrigatoriamente os que serãousados, servem apenas de exemplo). De notar a existência de campos querrelativos as UD’s quer relativos aos criadores. O resultado simplificado dosdiversos documentos encontrados é exibido e estes possuem links quecontêm informação sobre o próprio documento bem como permite aceder a

15

outros documentos da sua sub-árvore que contenham informaçãorelacionada.

Fig. 8 - Interface com o utilizador

Esta consulta utiliza os elementos do domínio relativo às unidades dedescrição e criador.

Consultar dados por conceitos

Este último caso de uso diverge um pouco dos anteriores em algunsaspectos. Em primeiro lugar pelo actor que deixa de ser obrigatoriamente umutilizador real (humano), e passa a ser uma entidade externa que por meio deserviços disponibilizados pela aplicação executa diversas consultas. Emsegundo lugar o facto de os resultados devolvidos, face a um conjunto depalavras-chaves dadas, não serem um conjunto de UD’s mas sim um

16

conjunto de informações que respondem concretamente ao conceito que épedido. Neste caso as pesquisas passam a ser mais abrangentes e podemestar relacionadas não só com UD’s mas também com informação relativa acriadores e proprietários.

Fig. 9 - Diagrama de sequência

A sequência de acções baseia-se também numa entrada de dados erespectiva devolução de resultados por parte do SGA. A realçar que outilizador neste caso é uma entidade externa.

O resultado da pesquisa é fornecido através da utilização de umwebservice.

Esta consulta utiliza os elementos do domínio relativo às unidades dedescrição, criador e proprietário consoante a informação que se pretendeobter.

17

IV. REQUISITOS SUPLEMENTARES

No contexto dos requisitos suplementares, podemos falaressencialmente de questão que se relacionam com a eficiência. Assim aaplicação deve ser eficiente, isto é, deve possuir um tempo de respostarelativamente baixo, para as diversas consultas. Um outro aspecto a referircomo requisito suplementar tem a ver com a interface que deve ser de fáciluso e não gerar erros.

18

V - MODELO DE CLASSES DO DOMÍNIO

Os esquemas de classes que iremos apresentar são preexistentes eportanto, este capítulo visa simplesmente a familiarização com o esquema dabase de dados, não nos pertencendo portanto a defesa destaimplementação.

Módulo da Unidade de Descrição (UD)

Fig. 10 - Diagrama de classes do módulo das UD’s

Sistema de Descrição

Este é o sistema principal de todo o projecto e visa essencialmenteoferecer uma estrutura que possa efectuar a gestão de um arquivo genérico.

19

Description Unit

A unidade de descrição (description unit) é um conceito que abrangeas características mais gerais de um arquivo, como: titulo, descrição, género,documento acima de si, esquema e nível em que se insere, algumas datas eoutra informação desta natureza. É sem dúvida o conceito mais poderoso emais importante de todo o arquivo, pois todos os outros conceitos circulam àsua volta. Possui ainda uma estrutura interna muito semelhante à estruturade directórios (em árvore), em que uma unidade de descrição pode ter váriasunidades de descrição no nível abaixo do seu. Esta hierárquia representa, emmuitos dos seus campos, uma generalização das unidades que estão abaixode si e que, para estes campos, herdam as suas características.

Scheme e Description Level

Um esquema tem como objectivo definir a estrutura de um arquivo.Serve de um modo geral, como uma meta informação que captura o modocomo os documentos de um arquivo estão dispostos. Estes conceitos emborapossuam uma hierarquia, esta não está disposta da mesma forma que a dasunidades de descrição. Deste modo, a hierárquia dos esquemas pode sermais facilmente percebida como uma categorização em que uma categoriapode conter subcategorias que aparecem noutros locais da estrutura, do quepropriamente como uma estrutura em árvore. Assim e uma vez que estesconceitos são muito abstractos para quem não tem um contacto muitopróximo com eles vamos dar um exemplo concreto (Fig11).

Fig. 11 – Possível esquema de uma colecção de selos portugueses, que contem umacategoria da colecção, que tem dentro as categorias: fotografias e uma sub-colecção de

selos só de todos os reis portugueses, que por sua vez possui o mesmo esquema defotografias dentro de si.

Suponhamos que possuímos um arquivo de selos, que possuidocumentos relativos ao conjunto de selos, mas possui também um sub-documento que continha informações de um conjunto de selos com umadeterminada característica comum (neste caso, reis de Portugal).Suponhamos que queremos ainda guardar documentos de fotografias deambas as colecções... Teríamos que ter na estrutura dos documentos umacategoria que tinha que estar tanto na colecção principal, como na sub-

Colecçãode

SelosColeccção

Sub-Colecção

FotosFotos

20

colecção. Os esquemas são assim estruturas que permitem capturar aestrutura do arquivo em si. Deste modo este modelo é um arquivo que podeser aplicado em qualquer caso especifico; porque é esta estrutura, quenormalmente é fixa para cada arquivo especifico, que pode ter a forma quese desejar.

No documento em UML, o esquema (Scheme) representa só o nome ea descrição do esquema em si, enquanto que a entidade DescriptionLeveltem como função descrever a estrutura (níveis e subníveis Fig4) do esquema.

Segment (Text, Image ou Vídeo)

Já tivemos oportunidade de referir que um documento (DescriptionUnit) representa uma certa abstracção, que contem as informações maisgerais de um arquivo. Se percebermos este tipo de abordagem, entãopodemos referir que um segmento representa a concretização de umdeterminado documento, ou por outro lado permite transportar osdocumentos que como já referimos, possuem certas características gerais,em fotografias, textos ou em vídeos.

O conceito de segmento não é incorporado nas pesquisaspropriamente ditas, a serem efectuadas no âmbito da disciplina de LIA.Contudo deve poder-se-lhes aceder a partir da amostragem de umdeterminado documento resultante de uma pesquisa. Dado este facto nãoadianta expandir os comentários às entidades associadas aos vídeos,ficando-nos simplesmente pela sua referência.

De referir ainda que um documento pode estar associado a váriossegmentos, e um segmento associado a vários documentos (Time Period).

21

Módulo do Criador

Fig. 12 - Diagrama de classes do módulo do criador

Componente de criação

A componente de criação pretende capturar a informação relativa aoscriadores de um arquivo. De salientar desde já que um documento podepossuir mais do que um criador.

Creator

A entidade creator permite armazenar a informação relativa a umcriador. A relação entre unidade de descrição e criador, é a relação decriação, que define entre outros, a data e o lugar da criação, e o tipo departicipação (Role) que teve aquele criador na criação. Está também definidoque cada criador (que pode possuir uma identificação diferente ao longo dotempo) possui um historial (CreatorDescription) e pode ainda pertencer aoutro criador, estando a identificação deste ligada ao primeiro através da

22

MainIdentification. O criador tem associado sempre uma localizaçãogeográfica, contemplada em Location.

23

Módulo do Proprietário

Fig. 13 - Diagrama de classes do módulo do proprietário

Componente de propriedade

Cada unidade de descrição possui material susceptível de serpossuído por alguém e é isso que este modelo pretende representar comesta componente.

Detentor

A um conjunto de documentos associados a um proprietário, existe aindicação se é copia ou não, e o local onde estão guardadas as copias de umdeterminado documento. Esta informação está contemplada em Copy. A esteconjunto podem estar também outras matérias relacionadas (por exemplo,outros arquivos que possam eventualmente ter interesse para quem conhece

24

o conjunto já mencionado), com a indicação do local onde estãoarmazenadas (AssociatedMaterials).

A associação RelatedDescriptionUnit serve simplesmente para registarunidades de descrição que estejam associadas a esta.

A entidade Custody é importante, uma vez que um conjunto dedocumentos pode ter detentores diferentes em datas diferentes, e por isso,torna-se importante registar quem é que tem a sua custódia num determinadomomento.

O proprietário tem associado sempre uma localização geográfica,contemplada em Location.

25

VI. NOTAS FINAIS

Decidimos introduzir este tópico para fazer referência ao facto da basede dados não ser uma base de dados muito intuitiva, o que torna mais difícil otrabalho, tanto para quem a tenta expor, como para quem a tentacompreender através de um relatório escrito. Contudo pensamos que fomossuficientemente explícitos, tentando não entrar em excessivo pormenor nabase de dados já criada (até porque não é esse o objectivo deste relatório) efocar simplesmente os conceitos subjacentes a um arquivo de modo a quepossa mais facilmente ser entendido o nosso trabalho no âmbito de LIA.

26

VII - GLOSSÁRIO

Criador – Pessoa ou entidade que criou o documento

Detentor – Pessoa ou entidade que possui o documento

Esquema – Conjunto hierárquico de níveis que definem o modo como ainformação está estruturada ao ser armazenada

Documentos – Descritos por unidades de descrição;

Unidades de descrição – Elemento mais importante de um arquivo, quecaptura os atributos dos documentos: titulo, datas... De referir que sempreque nos referimos a uma unidade de descrição esta está a descrever umdocumento individual ou uma colecção.