Relatório de Especificação de Requisitos. Pesquisa Em Arquivos

Transcrição

1 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.pt Pedro Andrade ei98030@fe.up.pt

2 Índice I. Introdução Página Objectivo do projecto... 3 Enquadramento do sistema a desenvolver no negócio/organização Riscos... 4 II. Requisitos do sistema Descrição geral dos requisitos do sistema a desenvolver III. Modelo de casos de utilização Visão geral Actores Casos de utilização IV. Requisitos suplementares V. Modelo de classes do domínio Módulo de Unidade de Descrição (UD) Módulo Criador Módulo Proprietário VI. Notas finais VII. Glossário

3 I. INTRODUÇÃO Objectivos O objectivo deste projecto é basicamente o de criar métodos de pesquisa que possam ser aplicados a arquivos gerais, isto é, arquivos que podem ser utilizados seja qual for o seu domínio. Isto envolve uma questão que pode criar um problema: como aproveitar a estrutura conhecida de um arquivo genérico (estrutura da base de dados) para devolver as informações que se pretendem. É este objectivo que nos propomos atingir com a utilização de 3 métodos de pesquisa. O primeiro será uma pesquisa normal, mais conhecida por pesquisa por formulário, e que, como é do conhecimento geral, se trata de uma consulta em que mediante o preenchimento de um formulário é devolvida uma resposta, que neste caso serão documentos que estejam dentro dos parâmetros especificados. A segunda trata-se de uma pesquisa por palavras chave. Este tipo de pesquisa é muitas vezes utilizado para obter páginas web através de um browser. O objectivo é o utilizador introduzir uma série de palavras que estejam relacionados com o que pretende procurar, para que lhe sejam devolvidos documentos que contenham essas palavras. A terceira pesquisa está destinada ao fornecimento de serviços, eventualmente a outros arquivos, através de conceitos (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 uma base de dados já criada e cujos dados já estejam introduzidos, não havendo da nossa parte qualquer responsabilidade, no âmbito deste projecto, na componente de alteração e validação dos dados, nem na criação da base de dados propriamente dita. Neste projecto, os objectivos são também a utilização da comunicação das aplicações através de webservices sobre SOAP, bem como o recurso ao conceito de extreme programming (xp) Enquadramento do sistema na organização Qualquer instituição pública (e não só), por natureza própria, produz material susceptível de ser arquivado; seja um estabelecimento de ensino, de saúde, de justiça... Deste modo, um estabelecimento de saúde, necessita que seja constantemente guardada informação histórica relativa por exemplo aos seus pacientes, como radiografias, electrocardiogramas, e outros exames; ou das doenças conhecias, ou outro qualquer tipo de informação. 3

4 De qualquer modo, devemos acrescentar que, neste projecto, a base de dados, não está de acordo com quaisquer dados relativos a um serviço de saúde, mas de um arquivo do Eça de Queirós já existente. Importa mesmo assim referir que tal facto nada altera o conteúdo e os objectivos da disciplina. Riscos Os riscos subjacentes ao projecto estão relacionados com escolhas que teremos de fazer e que de certo modo poderão condicionar o resultado final 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), que vão ser seleccionados, e sobre os quais assentarão as consultas. Outro problema poderá passar pela definição dos conceitos para os serviços que irão ser disponibilizados, isto é, saber claramente que campos é que estão, de uma forma consensual, relacionados com os conceitos que iremos abordar. Por fim, a tecnologia também poderá ser um risco, uma vez que para nós a utilização de webservices é uma novidade. 4

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 delas visando um utilizador comum e a outra uma entidade externa (electrónica ou não). É sobre estas três consultas e o cada uma delas implica que nos iremos debruçar. Consulta por chave A consulta por chave é destinada ao utilizador que queira informação relacionada com algumas palavras que servem como chaves, isto é, que queiram obter unidades de descrição sem conhecerem a estrutura da base de dados. O objectivo será simplesmente devolver, como resultado da pesquisa, unidades de descrição que estejam relacionadas com as palavras que se introduziram. Esta consulta deve ser realizada por nós campo a campo de todas as tabelas relacionadas (directa ou indirectamente) com os documentos, atribuindo uma classificação distinta consoante o campo em que as palavras aparecem. Assim a classificação final vai ser tanto maior quanto mais vezes as palavras aparecerem em campos considerados mais importantes. A saída deve devolver todas as unidades de descrição que concordem, de acordo com o que nós especificarmos, com as palavras introduzidas pelo utilizador, devendo estas estar ordenadas de forma decrescente 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 conhecimento prévio por parte de quem consulta, de alguns campos que existem na base de dados. Deste modo, deve ser apresentado ao utilizador um formulário com os campos que serão definidos pela nossa cliente, como mais importantes. É neste momento certo, contudo, que farão parte deste formulário dados relativos a documentos, criadores e detentores (eventualmente as suas chaves e descrições entre outros campos). Os resultados das pesquisas deverão ser sempre as unidades de descrição que estejam dentro dos 5

6 Arquivo de Doenças Hepatite Meningite Hepatite A Hepatite B Hepatite C Meningite Tipo 1 Meningite Tipo 2 Meningite Tipo 3 Fig. 1 Exemplo de um arquivo de doenças onde cada doença corresponde a uma unidade de descrição da nossa base de dados. parâmetros especificados. Uma vez que as unidades de descrição possuem uma hierarquia, isto é, têm uma estrutura semelhante a directórios, está especificado como requisito que nos resultados da pesquisa, se existirem várias unidades de descrição que apareçam dentro de outras na resposta da pesquisa, deve aparecer em primeiro lugar a unidade do nível mais acima encontrada e abaixo desta, mas no mesmo tópico as restantes unidades encontradas. Analogamente, no nosso exemplo de directórios, se compararmos as drives (C,D...) a arquivos, e se efectuarmos uma pesquisa em que apareçam dois directórios como resultado de uma pesquisa, em que um deles está na sub-árvore inferior do outro, só aparece o directório que tiver o nível mais alto como tópico as ocorrências dos seus filhos agrupadas abaixo (Fig1 e Fig2). Hepatite Hepatite A Hepatite B Fig. 2 Exemplo de uma pesquisa em que os resultados tenham sido as unidades de descrição Hepatite, Hepatite A e Hepatite B Na base de dados que possuímos existe contudo um conceito de herança em alguns campos das unidades de descrição e que são importantes para descrever essas mesmas unidades de descrição, nomeadamente o conceito de criador e de detentor. Deste modo, nos resultados da pesquisa deve aparecer sempre os dados relativos a estes conceitos, mesmo que estejam num nível mais acima do que o mais alto encontrado (Fig3). 6

7 Hepatite João António Arquivo do Hospital do Porto Unidades de descrição relacionadas: Hepatite A João António Arquivo do Hospital do Porto Hepatite B João António Arquivo do Hospital do Porto Fig 3 A informação sobre o criador (João António) e o detentor (Arquivo do Hospital do Porto) provém da unidade Arquivo de Doenças(Fig1). Consulta por conceito A consulta por conceito pressupõe uma entidade externa que pode perfeitamente ser outro arquivo que pode desconhecer a estrutura do arquivo já implementado. Deste modo, a única coisa que o arquivo externo necessita de conhecer são conceitos que estejam definidos e sejam consensuais, como por 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, 7

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 que disponibilize os dados que se pretenderem, isto é, disponibiliza, entre outros, os campos especificados acima mediante a apresentação de alguns desses campos preenchidos. De uma forma geral, esta consulta será semelhante à consulta por formulário, mas para além de ser utilizado um webservice para a efectuar, os resultados serão relativos, não só a unidades de descrição, mas também a conceitos relacionados com criadores e detentores. 8

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 pormenor no tópico seguinte. Sobre os actores há que referir o facto de o utilizador comum ser uma generalização do arquivista uma vez que o arquivista pode, ele próprio, ser um utilizador comum. 9

10 No que diz respeito às acções do diagrama, a cada utilizador cabe-lhe unicamente uma função, excepto no caso do utilizador comum onde existem duas funções. Estas duas funções são consultas de documentos mas aparecem individualizadas pelo facto de estarem assentes em objectivos e pressupostos de implementação distintos. Actores Responsável do arquivo Ao responsável pelo arquivo cabe o papel de definir os esquemas usados no arquivo. Assim, é o responsável do arquivo que define de que modo, ou seja, segundo que organização e sobre que características é que os diversos documentos são classificados para serem arquivados. Desta forma é o responsável do arquivo que cria as bases para o arquivista executar as suas funções. As funcionalidades relativas a este actor não são implementadas neste projecto. Nota: Para mais informações sobre este item consultar a documentação do projecto MetaMedia Arquivista Sobre o arquivista recaem basicamente duas funções: a de recolher a informação desejada e inserir os dados na base de dados. Estas duas funcionalidades também não são, por nós, implementadas no âmbito deste projecto. Utilizador Comum O utilizador comum tem como principal função a pesquisa de dados na base de dados. Para isso pode fazer uso dos dois tipos consultas que para si são reservadas por formulário e por palavras-chave. 10

11 Serviços externos Este actor representa todo um conjunto de serviços externos que realizam consultas sobre o arquivo. A função deste actor é então a de realizar pesquisas 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 classes do domínio fazemos uma referência para o capítulo V - Modelo de Classes do Domínio. Definir os esquemas do arquivo Este caso de uso consiste na definição e implementação do esquema de armazenamento dos documentos geridos pelo arquivo. A definição dos esquemas do arquivo não será alvo de implementação neste projecto pelo facto de não ser um dos requisitos do mesmo. É apenas apresentado 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 um arquivo e armazená-la na base de dados, ou seja, a partir de qualquer tipo de informação existente ou novos dados recolhidos de uma qualquer fonte, introduzi-los numa base de dados usando a estrutura definida pelo responsá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 11

12 sobre os campos que vai pesquisar. Assim, pelo facto de não haver conhecimento sobre a estrutura da base de dados em causa, a pesquisa é feita por palavra-chave, ou seja, através de um conjunto de palavras que caracterizam o que o utilizador deseja consultar (consulta não estruturada). A informação introduzida é analisada e como resposta é exibida uma lista de Unidades de Descrição (UD s), que contêm dados diversos sobre o que se introduziu, classificadas e ordenadas por valor. Esta valorização é feita com base na proveniência (entenda-se campos da base de dados) dos atributos que se está a pesquisar. Cada campo possui um peso específico o que assim permite 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 face ao 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 a nível de saída de dados está representado genericamente na Fig6. As palavras-chave são inseridas usando uma text box e o resultado da pesquisa é apresentado por ordem de classificação obtida. Cada documento possui um link que exibe toda a informação que este contém. Tal como neste caso de uso, nos seguintes casos de utilização este tópico será tratado do mesmo modo. Contudo esta consulta pesquisa utiliza todas as classes do domínio exposto mais adiante. 12

13 Fig. 6 - Interface com o utilizador Consultar documentos por formulários Tal como no caso de uso anterior, neste pretende-se que o SGA responda a uma pesquisa de um utilizador comum. A grande diferença centra-se no facto de neste caso o utilizador comum possuir um conhecimento mais elevado dos campos que deseja pesquisar. Assim, a pesquisa passa a ser estruturada, isto é, em vez de se basear em palavraschaves, a consulta é realizada com base num formulário. Este formulário contém os atributos mais importantes quer das unidades de descrição quer dos criadores. Dentro dos atributos a incluir no formulário encontram-se as chaves primárias, que descrevem unicamente os diversos dados e alguns campos de datas (estes últimos muito importantes neste tipo de pesquisas). 13

14 Neste caso de uso o resultado dado pelo SGA é um conjunto de UD s que contêm textualmente a informação que foi introduzida no formulário de acordo 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êm informação igual ao seu "pai" não deverão constar de forma directa na resposta (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 s serem 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ções deste caso de uso envolve: em primeiro o utilizador comum preenche o formulário com dados de acordo com a pesquisa que pretende efectuar. O Sistema Geral de Arquivo (SGA) responde então de acordo com o descrito em cima. Sobre a interface com o utilizador para este caso de uso são também apresentados esquemas para a entrada e para a saída de dados. Na entrada de dados são exibidas algumas text boxes referentes a alguns campos da base de dados (os campos exibidos não são obrigatoriamente os que serão usados, servem apenas de exemplo). De notar a existência de campos quer relativos as UD s quer relativos aos criadores. O resultado simplificado dos diversos documentos encontrados é exibido e estes possuem links que contêm informação sobre o próprio documento bem como permite aceder a 14

15 outros documentos da sua sub-árvore que contenham informação relacionada. Fig. 8 - Interface com o utilizador Esta consulta utiliza os elementos do domínio relativo às unidades de descrição e criador. Consultar dados por conceitos Este último caso de uso diverge um pouco dos anteriores em alguns aspectos. Em primeiro lugar pelo actor que deixa de ser obrigatoriamente um utilizador real (humano), e passa a ser uma entidade externa que por meio de serviços disponibilizados pela aplicação executa diversas consultas. Em segundo lugar o facto de os resultados devolvidos, face a um conjunto de palavras-chaves dadas, não serem um conjunto de UD s mas sim um 15

16 conjunto de informações que respondem concretamente ao conceito que é pedido. Neste caso as pesquisas passam a ser mais abrangentes e podem estar relacionadas não só com UD s mas também com informação relativa a criadores e proprietários. Fig. 9 - Diagrama de sequência A sequência de acções baseia-se também numa entrada de dados e respectiva devolução de resultados por parte do SGA. A realçar que o utilizador neste caso é uma entidade externa. O resultado da pesquisa é fornecido através da utilização de um webservice. Esta consulta utiliza os elementos do domínio relativo às unidades de descrição, criador e proprietário consoante a informação que se pretende obter. 16

17 IV. REQUISITOS SUPLEMENTARES No contexto dos requisitos suplementares, podemos falar essencialmente de questão que se relacionam com a eficiência. Assim a aplicação deve ser eficiente, isto é, deve possuir um tempo de resposta relativamente baixo, para as diversas consultas. Um outro aspecto a referir como requisito suplementar tem a ver com a interface que deve ser de fácil uso e não gerar erros. 17

18 V - MODELO DE CLASSES DO DOMÍNIO Os esquemas de classes que iremos apresentar são preexistentes e portanto, este capítulo visa simplesmente a familiarização com o esquema da base de dados, não nos pertencendo portanto a defesa desta implementação. Módulo da Unidade de Descrição (UD) Fig Diagrama de classes do módulo das UD s Sistema de Descrição Este é o sistema principal de todo o projecto e visa essencialmente oferecer uma estrutura que possa efectuar a gestão de um arquivo genérico. 18

19 Description Unit A unidade de descrição (description unit) é um conceito que abrange as 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 e outra informação desta natureza. É sem dúvida o conceito mais poderoso e mais importante de todo o arquivo, pois todos os outros conceitos circulam à sua volta. Possui ainda uma estrutura interna muito semelhante à estrutura de directórios (em árvore), em que uma unidade de descrição pode ter várias unidades de descrição no nível abaixo do seu. Esta hierárquia representa, em muitos dos seus campos, uma generalização das unidades que estão abaixo de 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 modo como os documentos de um arquivo estão dispostos. Estes conceitos embora possuam uma hierarquia, esta não está disposta da mesma forma que a das unidades de descrição. Deste modo, a hierárquia dos esquemas pode ser mais facilmente percebida como uma categorização em que uma categoria pode conter subcategorias que aparecem noutros locais da estrutura, do que propriamente como uma estrutura em árvore. Assim e uma vez que estes conceitos são muito abstractos para quem não tem um contacto muito próximo com eles vamos dar um exemplo concreto (Fig11). Colecção de Selos Coleccção Sub-Colecção Fotos Fotos Fig. 11 Possível esquema de uma colecção de selos portugueses, que contem uma categoria 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 de fotografias dentro de si. Suponhamos que possuímos um arquivo de selos, que possui documentos relativos ao conjunto de selos, mas possui também um subdocumento que continha informações de um conjunto de selos com uma determinada característica comum (neste caso, reis de Portugal). Suponhamos que queremos ainda guardar documentos de fotografias de ambas as colecções... Teríamos que ter na estrutura dos documentos uma categoria que tinha que estar tanto na colecção principal, como na sub- 19

20 colecção. Os esquemas são assim estruturas que permitem capturar a estrutura do arquivo em si. Deste modo este modelo é um arquivo que pode ser aplicado em qualquer caso especifico; porque é esta estrutura, que normalmente é fixa para cada arquivo especifico, que pode ter a forma que se desejar. No documento em UML, o esquema (Scheme) representa só o nome e a descrição do esquema em si, enquanto que a entidade DescriptionLevel tem 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 (Description Unit) representa uma certa abstracção, que contem as informações mais gerais de um arquivo. Se percebermos este tipo de abordagem, então podemos referir que um segmento representa a concretização de um determinado documento, ou por outro lado permite transportar os documentos que como já referimos, possuem certas características gerais, em fotografias, textos ou em vídeos. O conceito de segmento não é incorporado nas pesquisas propriamente ditas, a serem efectuadas no âmbito da disciplina de LIA. Contudo deve poder-se-lhes aceder a partir da amostragem de um determinado documento resultante de uma pesquisa. Dado este facto não adianta 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ários segmentos, e um segmento associado a vários documentos (Time Period). 20

21 Módulo do Criador Fig Diagrama de classes do módulo do criador Componente de criação A componente de criação pretende capturar a informação relativa aos criadores de um arquivo. De salientar desde já que um documento pode possuir mais do que um criador. Creator A entidade creator permite armazenar a informação relativa a um criador. A relação entre unidade de descrição e criador, é a relação de criação, que define entre outros, a data e o lugar da criação, e o tipo de participação (Role) que teve aquele criador na criação. Está também definido que cada criador (que pode possuir uma identificação diferente ao longo do tempo) possui um historial (CreatorDescription) e pode ainda pertencer a outro criador, estando a identificação deste ligada ao primeiro através da 21

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

23 Módulo do Proprietário Fig Diagrama de classes do módulo do proprietário Componente de propriedade Cada unidade de descrição possui material susceptível de ser possuído por alguém e é isso que este modelo pretende representar com esta componente. Detentor A um conjunto de documentos associados a um proprietário, existe a indicação se é copia ou não, e o local onde estão guardadas as copias de um determinado documento. Esta informação está contemplada em Copy. A este conjunto podem estar também outras matérias relacionadas (por exemplo, outros arquivos que possam eventualmente ter interesse para quem conhece 23

24 o conjunto já mencionado), com a indicação do local onde estão armazenadas (AssociatedMaterials). A associação RelatedDescriptionUnit serve simplesmente para registar unidades de descrição que estejam associadas a esta. A entidade Custody é importante, uma vez que um conjunto de documentos pode ter detentores diferentes em datas diferentes, e por isso, torna-se importante registar quem é que tem a sua custódia num determinado momento. O proprietário tem associado sempre uma localização geográfica, contemplada em Location. 24

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

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 a informação está estruturada ao ser armazenada Documentos Descritos por unidades de descrição; Unidades de descrição Elemento mais importante de um arquivo, que captura os atributos dos documentos: titulo, datas... De referir que sempre que nos referimos a uma unidade de descrição esta está a descrever um documento individual ou uma colecção. 26