Análise de requisitos

Os requisitos fundamentais estão assentes na necessidade de criar um sistema base de suporte a um observatório. Os mesmos serão fundamentais para que a base seja fiável e de suporte para novos desenvolvimentos. A análise de requisitos foi efetuada partindo de um estudo exaustivo que é apresentado e analisado nos subcapítulos seguintes.

3.1.1. Requisitos funcionais

Os requisitos podem ser classificados de diversas formas no que toca ao entendimento do comportamento dos objetivos, funções e tarefas. Neste modo existem os requisitos funcionais onde são declaradas funções que regem o comportamento do sistema sob determinadas situações sendo especificação de cada uma detalhada e consistente. É uma interação entre o sistema e o ambiente.

 Autenticação: é necessário um mecanismo de autenticação que identifique inequivocamente o papel de cada utilizador no sistema. Está também previsto o papel de convidado para utilizadores não autenticados;

 Moderação: a moderação tem como principal objetivo evitar abusos e erros. A moderação é concretizada através da visualização de todas as operações realizadas pelos utilizadores;

 Controlo: é obrigatório a existência de um mecanismo de controlo capaz de retirar ou adicionar permissões da respetiva interação. Estas permissões são colocados por grupos e revogadas individualmente;

 Interação: é imperativo um mecanismo de interação entre os utilizadores, por exemplo, um mecanismo que permita que os utilizadores possam ter um meio de anotações colocando assim o seu ponto de vista sobre determinado artigo;

 Visualização: um mecanismo básico mas ao mesmo tempo essencial, o campo da visualização de todos os elementos presentes, sejam eles publicações, utilizadores, detalhes de autores, etc.;

 Segurança: o mecanismo de segurança garante que nada é acedido sem autorização.

Tabela 2 - Tabela de equivalência de requisitos - funcionalidades

Requisito Funcionalidade

Autenticação Sistema de Autenticação

Moderação Perfil de moderador

Controlo Permissões

Interação Sistema de anotações

Visualização Listagem dos elementos

19

3.1.2. Qualidade

Os requisitos relativos à qualidade do software são os seguintes:

 Usabilidade: um dos requisitos básicos é a usabilidade, este campo permite que o utilizador ter uma melhor perceção da página que está a visitar. Neste requisito, é necessário ter atenção ao contraste das cores, à disposição dos menus e à localização do site durante aa navegação. É também neste requisito que se define que atenções são dadas pessoas com necessidades especiais;

 Desempenho: como se prevê que o sistema possa englobar vários tipos de publicações bem como um número elevado de informação relativas às mesmas, deve- se garantir desempenho adequado em condições de carga elevada;

 Suportabilidade: dada a existência de uma ligação a uma base de dados (contendo toda a informação), é necessário que essa ligação não falhe. Caso exista falha nessa ligação, o sistema não deve permitir operações, colocando-se em modo de manutenção.

3.1.3. Interfaces

Na conceção de qualquer projeto de software é sempre necessário ter em atenção aos diversos tipos de interfaces existentes, neste caso temos a interface responsável pela interação humano-máquina.

 Interação Humana: esta interface é apresentada pelo sistema através de um navegador de internet. Além desta funcionalidade, deve adaptar-se aos diversos perfis existentes no sistema, pois cada utilizador tem o seu próprio perfil, um administrador não tem o mesmo tipo de perfil e página que um utilizador comum.

3.1.4. Restrições

Todo o processo de desenvolvimento sofre de restrições, que podem ser associadas a diversos fatores, que vão desde a linguagem de programação ao tipo de licença no qual o programa vai funcionar.

 Desenvolvimento em PHP;

 Suporte a diversos Navegadores Web;

 Suporte da comunidade;

20

3.2. Modelo do sistema

A arquitetura de três camadas (Figura 2) permite que o sistema seja bem compreendido e bem documentado. Esta topologia define que haja uma separação entre as camadas de código para que uma mudança de implementação de uma camada não afete outra bem como que uma camada trabalhe com diferentes versões de outras camadas (Microsoft, 2009), tendo como vantagens principais escalabilidade, desempenho e disponibilidade. Esta topologia permite que sejam feitas modificações de camadas sem que as outras sejam afetadas. Por exemplo, é possível modificar a camada de apresentação sem termos de modificar as restantes ou, no caso de existirem alterações das demais, não serem alterações de nível crítico.

Figura 2 - Arquitetura do Observatório (Correia et. al., 2013)

Como já referido, a arquitetura (Figura 2) é responsável pelo transporte e manipulação entre as diferentes interfaces (base de dados e o apresentação). É necessário ter em atenção aos futuros processos de desenvolvimento e ter a necessidade de possuir uma arquitetura bem estruturada para que a possível distribuição do código detalhadamente documentado para suporte e apoio da comunidade (Santos et al., 2012). De acordo com as características já referidas, fazem com que as camadas tenham como objetivo o seguinte:

 Cliente: pode ser usado um qualquer navegador que suporte código HTML, no entanto, e com os Serviços Web, é deixada uma porta aberta para um cliente de várias plataformas, sejam por dispositivos móveis ou pelas tradicionais aplicações tipo janelas;

 Camada de Apresentação: responsável pela transformação do código com os dados vindos da camada de negócio mais o HTML, enviando assim para o navegador do cliente para que o mesmo interprete e mostre o resultado final;

21

 Camada de negócio: esta camada faz o processamento da informação entre a camada de apresentação e a camada de dados. É onde existe toda a verificação de informação, segurança, etc. Esta camada, por exemplo, tanto recolhe os dados da BD para enviar para a camada de apresentação como da camada de apresentação para a camada de dados. Nesta camada é também onde se manipula ou cria objetos temporários.

 Camada de dados: a camada de dados é a representação da base de dados em códigos. Esta representação tem a vantagem de o programador não precisar de usar tanto o SQL, usando para isso métodos, uma vez que as tabelas da base de dados estão representadas aqui como classes.

 Serviços Web: interface que permite a entidades externas aceder aos serviços da plataforma.

 Base de dados: esta parte, responsável pelo armazenamento da informação, pode ser usada por um qualquer servidor de base de dados, seja ele Mysql, SQL Server, etc. Isto só é possível, o uso de um qualquer tipo de base de dados, pois existe uma abstração (camada de dados), que liberta o programador da preocupação de como ligar as diferentes base de dados e de escrever o SQL.

3.2.1. Especificação do sistema

Este sistema tem como objetivo ser uma base do observatório cujos requisitos que definem as características mais importantes são apresentados na Tabela 2. A evolução do observatório será gradual e evolutiva pelo que é de todo importante que a base seja robusta para o suporte dessa evolução. É também previsível o surgimento de novas funcionalidades ao longo do tempo.

De forma a compreender melhor quais as formas como deve ser a interação entre o computador e o utilizador, são apresentados diagramas de caso mais importantes. São expostos os mais importantes pois é neles que residem as partes principais desta base: controlo de permissões e inserção de publicações.

22 Tabela 3 - Inserção de publicações

Âmbito Inserção de uma publicação

Finalidade Utilizador insere uma nova publicação Pré-condições Estar registado no sistema com permissão Condição de

sucesso

A publicação é criada pelo utilizador Condição de falha A publicação é rejeitada pelo sistema Atores primários Administradores e utilizadores registados Sequência típica dos

eventos

1. O utilizador faz o processo de autenticação

2. O sistema fornece-lhe todas as opções e condições relativas ao perfil 3. O utilizador cria uma nova publicação

4. O sistema apresenta-lhe a publicação criada mas por aprovar 5. O utilizador deixa de estar autenticado

6. Caso termina com sucesso. Sequência

alternativa e extensões

1. Autenticação Inválida

1.1. Se autenticação Inválida:

1.1.1. Apresenta mensagem de erro

1.1.2. Caso de uso retomado ao estado de autenticação

2. Se o utilizador fizer logout em qualquer sequencia típica de eventos, então:

2.1. O sistema pede ao utilizador para confirmar o lougout 2.2. O caso acaba

3. Se o utilizador tentar inserir uma publicação já existente 3.1. É apresentada uma mensagem de duplicação de dados Requisitos especiais Permissões de inserção

Aspetos em aberto Base de dados indisponível

Figura 3 - Caso de uso da inserção de uma publicação uc Publicações Aprovação Publicações Inserir Alterar Remov er Aprov ação Moderador Administrador Utilizador

23 Tabela 4 - Registo de utilizadores

Âmbito Registo de um utilizador Finalidade Utilizador regista-se no sistema Pré-condições Nenhumas

Condição de sucesso

Registo do utilizador com sucesso Condição de falha O registo do utilizador é rejeitado Atores primários Administradores e moderadores Sequência típica dos

eventos

1. O utilizador faz o processo de registo

2. O sistema pede autorização aos atores primários 3. É concedida a validação do registo ao utilizador. 4. O sistema apresenta-lhe a página de perfil. 5. O utilizador deixa de estar autenticado 6. Caso termina com sucesso.

Sequência alternativa e extensões

1. Autenticação Inválida

1.1. Se autenticação Inválida:

1.1.1. Apresenta mensagem de erro

1.1.2. Caso de uso retomado ao estado de autenticação

2. Se o utilizador fizer logout em qualquer sequencia típica de eventos, então:

2.1. O sistema pede ao utilizador para confirmar o lougout 2.2. O caso acaba

Requisitos especiais Nenhumas

Aspetos em aberto Espera de aprovação

Figura 4 - Casos de uso de registo de utilizador

Por último temos o diagrama de entidade relação que permite verificar como a base de dados será criada, sendo proposta a base de dados presente na Figura 5.

uc Registo Utilizador Administrador Registo Registar Alterar Eliminar Aprovação Aprov ação

24

Publicação

N

Tem

N

Autor

N

Tem

N

Instituição

N

Tem

1

País

N

Tem

N

Editor

N

Tem

1

Tem

1

Tem

N

Publicador

N

Tipo

N

Tipo de Identificação

Utilizador

Tem

Grupo

N N

Tem

Permissão

N N

25

No documento Observatório de publicações científicas de CSCW (páginas 34-41)