ESCOLA POLITÉCNICA DA UNIVERSIDADE DE SÃO PAULO

Transcrição

1 5. Requisitos do Sistema No: 01 ( X ) Funcional ( ) Não funcional Requisito: Armazenamento Descrição: O sistema deve permitir o armazenamento de experimentos de biodiversidade produzidos no openmodeller. Prioridade: ( X ) Alta ( ) Média ( ) Baixa Requisitos associados: No: 02 ( X ) Funcional ( ) Não funcional Requisito: Recuperação Descrição: O sistema deve permitir a recuperação de experimentos de biodiversidade produzidos no openmodeller. Prioridade: ( X ) Alta ( ) Média ( ) Baixa Requisitos associados: 16 / 68

2 No: 03 ( X ) Funcional ( ) Não funcional Requisito: Alteração Descrição: O sistema deve permitir a alteração de experimentos de biodiversidade produzidos no openmodeller Prioridade: ( X ) Alta ( ) Média ( ) Baixa Requisitos associados: No: 04 ( X ) Funcional ( ) Não funcional Requisito: Versionamento Descrição: O sistema deve permitir o versionamento de experimentos de biodiversidade produzidos no openmodeller. Prioridade: ( X ) Alta ( ) Média ( ) Baixa Requisitos associados: 17 / 68

3 No: 05 ( X ) Funcional ( ) Não funcional Requisito: Controle de usuários Descrição: O Sistema deve fazer o controle de usuários, dando permissões de acordo com sua característica. Prioridade: ( X ) Alta ( ) Média ( ) Baixa Requisitos associados: No: 06 ( X ) Funcional ( ) Não funcional Requisito: Controle de licensas Descrição: O Sistema deve respeitar as licenças e direitos autorais em que os experimentos foram distribuídos, promovendo a segurança dos dados e dos resultados; Prioridade: ( X ) Alta ( ) Média ( ) Baixa Requisitos associados: 18 / 68

4 No: 07 ( ) Funcional ( X ) Não funcional Requisito: Interface entre Banco de dados e Plugin Descrição: O Sistema deve utilizar Web Services para fazer a interface entre o banco de dados e o plugin do openmodeller. Prioridade: ( X ) Alta ( ) Média ( ) Baixa Requisitos associados: No: 08 ( ) Funcional ( X ) Não funcional Requisito: Desenvolvimento do Plugin Descrição: O Plugin deve ser desenvolvido utilizando a linguagem C++, utilizando a biblioteca Qt para o desenvolvimento das interfaces. Prioridade: ( X ) Alta ( ) Média ( ) Baixa Requisitos associados: No: 09 ( ) Funcional ( X ) Não funcional Requisito: Banco de Dados Descrição: O banco de dados deve estar distribuído em um cluster e ser capaz de armazenar dados 19 / 68

5 geográficos. Prioridade: ( X) Alta ( ) Média ( ) Baixa Requisitos associados: No: 10 ( ) Funcional ( X ) Não funcional Requisito: Integração Descrição: O sistema deve integrar o plugin desenvolvido no openmodeller com os Web Services desenvolvidos. Prioridade: ( X) Alta ( ) Média ( ) Baixa Requisitos associados: Todos No: 11 ( X ) Funcional ( ) Não funcional Requisito: Visualização de experimento armazenado Descrição: O sistema deve permitir que o usuário visualize um experimento armazenado junto com sua respectiva descrição. Prioridade: ( X) Alta ( ) Média ( ) Baixa 20 / 68

6 Requisitos associados: Todos No: 12 ( ) Funcional ( X ) Não funcional Requisito: Integridade dos dados Descrição: Os dados de um experimento não podem ser modificados a não ser pelo seu criador original. Prioridade: ( X) Alta ( ) Média ( ) Baixa Requisitos associados: / 68

7 No: 13 ( ) Funcional ( X ) Não funcional Requisito: Tratamento de erros Descrição: Caso ocorra erros de conexão, comunicação, ou outros tipos o sistema não deve exibir erros ou travar, deixando o funcionamento transparente para o usuário. Prioridade: ( X) Alta ( ) Média ( ) Baixa Requisitos associados: No: 14 ( ) Funcional ( X ) Não funcional Requisito: Atomicidade do banco de dados Descrição: As transações devem ser atômicas, sendo que etapas parciais não devem influir no estado do banco de dados. Prioridade: ( X) Alta ( ) Média ( ) Baixa Requisitos associados: 22 / 68

8 No: 15 ( ) Funcional ( X ) Não funcional Requisito: Consistência do banco de dados Descrição: A integridade dos dados deve assegurada, ou seja, as transações não podem quebrar as regras do Banco de Dados. Prioridade: ( X) Alta ( ) Média ( ) Baixa Requisitos associados: No: 16 ( ) Funcional ( X ) Não funcional Requisito: Isolamento do banco de dados Descrição: Nenhuma transação pode ocorrer concomitantemente se essas transações alterarem o mesmo dado no banco de dados. Prioridade: ( X) Alta ( ) Média ( ) Baixa Requisitos associados: 23 / 68

9 No: 17 ( ) Funcional ( X ) Não funcional Requisito: Durabilidade do banco de dados Descrição: Os efeitos de uma transação em caso de sucesso são permanentes, mesmo em presença de falhas. Prioridade: ( X) Alta ( ) Média ( ) Baixa Requisitos associados: 24 / 68

10 6. Arquitetura do Sistema A arquitetura do sistema pode ser vista na figura abaixo, a interface do plugin é o plugin que será desenvolvido na ferramenta openmodeller, que fará a interface entre usuário e os serviços do repositório. Na figura abaixo estão representados as tecnologias envolvidas na criação do repositório e do plugin para openmodeller. 25 / 68

11 ESCOLA POLITÉCNICA DA UNIVERSIDADE DE SÃO PAULO Departamento de Engenharia de Computação e Sistemas Digitais 6.1 Projeto de interface Abaixo estão representados os protótipos das interfaces desenvolvidas, nelas ainda não estão contemplados todos os requisitos e casos de uso, mas exemplifica comoo será o padrão do sistema. Versão do Documento 0. 3 Data: 04/01/20122 Alunos: Flávio Sales Truzzi Página: 26 / 68

12 ESCOLA POLITÉCNICA DA UNIVERSIDADE DE SÃO PAULO Departamento de Engenharia de Computação e Sistemas Digitais Versão do Documento 0. 3 Data: 04/01/20122 Alunos: Flávio Sales Truzzi Página: 27 / 68

13 ESCOLA POLITÉCNICA DA UNIVERSIDADE DE SÃO PAULO Departamento de Engenharia de Computação e Sistemas Digitais 7. Casos de Uso Caso de uso 1: Manipulação de usuários Caso de uso 1.1: Cadastro de usuárioss Descrição: Este caso de uso descreve o processo de cadastro de usuárioss no sistema. Atores: novo usuário Caso de uso 1.2: Exclusão de conta de usuários Descrição: Este caso de uso descreve a remoção de um usuário existentee Caso de uso 1.3: Alteração de usuários. Descrição: Este caso de uso descreve a alteração dos dados de um usuário existentee Caso de uso 1.4: Recuperação de usuário Descrição: Este caso de uso descreve a consulta aos dados de um espetáculo existente Versão do Documento 0. 3 Data: 04/01/20122 Alunos: Flávio Sales Truzzi Página: 28 / 68

14 Caso de Uso 2: Manipulação de Experimento Caso de Uso 2.1: Cadastro de Experimento Descrição: Este caso de uso descreve o processo de cadastro de novos experimentos no sistema Caso de Uso 2.2: Remoção de Experimento Descrição: Este caso de uso descreve o processo de remoção de experimentos no sistema Caso de Uso 2.3: Alteração de Experimento Descrição: Este caso de uso descreve o processo de alteração de experimentos no sistema Caso de Uso 2.4: Recuperação Caso de Uso 2.4.1: Recuperação de Experimento Descrição: Este caso de uso descreve o processo de obtenção de experimentos já cadastrados no sistema Caso de Uso 2.4.2: Recuperação de Resultado Descrição: Este caso de uso descreve o processo de obtenção de resultado de 29 / 68

15 experimento já cadastrado no sistema Descrição: Este caso de uso descreve o processo de obtenção de experimentos já cadastrados no sistema Caso de Uso 3: Consulta Experimento Descrição: Este caso de uso descreve o processo de consulta do acervo de experimentos Caso de uso 4: Login Descrição: Este caso de uso descreve o processo de login de usuários no sistema. Caso de uso 5: Logoff Descrição: Este caso de uso descreve o processo de logoff de usuários no sistema. 30 / 68

16 6.1 Descrição dos Casos de Uso Caso de uso 1: Manipulação de usuários Caso de uso 1.1: Cadastro de usuários Descrição: Este caso de uso descreve o processo de cadastro de usuários no sistema. Evento iniciador: Solicitação de cadastro do usuário. Atores: Usuário. Pré-condição: nenhuma. Seqüência de eventos: 1. Usuário seleciona, através do clique a opção de cadastro de usuário. 2. Sistema exibe os campos necessários para cadastro de usuário. 3. Usuário insere os dados do usuário. 4. Sistema cadastra o usuário e envia seu status e dados cadastrais para conferência via . Pós-condição: Usuário foi cadastrado no sistema. Exceções: 1. Usuário a ser cadastrado já existe: sistema apresenta mensagem de erro e retorna ao passo 2 (passo 4). 2. Dados fornecidos para o usuário não consistentes: sistema apresenta mensagem de erro e retorna ao passo 2 (passo 4). Inclusões: 1. Não se aplica. 31 / 68

17 Caso de uso 1.2: Remoção de um usuário Descrição: Este caso de uso descreve a remoção de um usuário existente Evento iniciador: Solicitação de remoção de usuário Atores: Usuário Pré-condição: Usuário autenticado. Seqüência de eventos: 1. Usuário solicita operação de remoção de usuário. 2. Sistema solicita a identificação do usuário a ser removido. 3. Usuário se identifica. 4. Sistema remove o usuário e exibe o resultado. Pós-condição: usuário e seus experimentos privativos são removidos. Exceção: 1. Falha de identificação: sistema bloqueia a exclusão por 24h.(passo 4). Inclusão: 1. Caso de uso de recuperação de usuário. Caso de uso 1.3: Alteração de um usuário. Descrição: Este caso de uso descreve a alteração dos dados de um usuário existente Evento iniciador: Solicitação de remoção de usuário Atores: Usuário Pré-condição: Usuário autenticado. Seqüência de eventos: 32 / 68

18 1. Usuário solicita operação de remoção de usuário. 2. Sistema solicita a identificação do usuário a ser removido. 3. Usuario se identifica. 4. Sistema remove o usuário e exibe resultado. Pós-condição: usuário e seus experimentos privativos são removidos. Exceção: 1. Falha de identificação: sistema bloqueia a exclusão por 24h.(passo 4). Inclusão: 1. Caso de uso de recuperação de usuário. Caso de uso 1.4: Recuperação de um usuário Descrição: Este caso de uso descreve a consulta aos dados de um usuário existente Evento iniciador: solicitação de consulta de usuário Pré-condição: usuário autenticado Seqüência de eventos: 1. Usuário solicita operação de consulta de usuário. 2. Sistema solicita a identificação do usuário a ser consultado. 3. Usuário se identifica. 4. Sistema apresenta os dados do usuário. 5. Usuário finaliza consulta. Pós-condição: dados do usuário são apresentados Exceção: 33 / 68

19 1. Falha de identificação: sistema volta ao passo 2. (passo 3). Inclusão: Não se aplica. Caso de Uso 2.1: Cadastro de Experimento Descrição: Este caso de uso descreve o processo de cadastro de novo experimento no sistema Evento iniciador: solicitação de cadastro de novo experimento no sistema Pré-condição: usuário autenticado Seqüência de eventos: 1. Usuário solicita o cadastro de experimento no sistema. 2. Sistema lista os experimentos ainda não cadastrados. 3. Usuário solicita o cadastro de um experimento. 4. Sistema solicita preenchimento de informações sobre o experimento a ser cadastrado. 5. Usuário preenche as informações do experimento. 6. Usuário confirma cadastro. 7. Sistema efetua cadastro do experimento. Pós-condição: Experimento está cadastrado no sitema. Exceção: 1. Falha no cadastro: não há conexão com a Internet (Passo 6). Sistema informa a falha na conexão e cancela a transação. 34 / 68

20 Inclusão: Não se aplica. Caso de Uso 2.2: Remoção de Experimento Descrição: Este caso de uso descreve o processo de remoção de experimentos no sistema Evento iniciador: solicitação de remoção de experimento do sistema Pré-condição: usuário autenticado Seqüência de eventos: 1. Usuário solicita remoção de experimento no sistema. 2. Sistema lista os experimentos cadastrados. 3. Usuário solicita a exclusão de um experimento. 4. Sistema exibe alerta de exclusão de experimento. 5. Usuário confirma exclusão. 6. Sistema exclui o experimento. Pós-condição: Experimento é excluido do sitema. Fluxo Alternativo: 5. Usuário cancela exclusão. 35 / 68

21 6. Retorna ao passo 2. Exceção: 1. Falha na exclusão: não há conexão com a Internet (Passo 5). Sistema informa a falha na conexão e cancela a exclusão. Inclusão: Não se aplica. Caso de Uso 2.3: Alteração de Experimento Descrição: Este caso de uso descreve o processo de alteração de experimentos no sistema Evento iniciador: solicitação de alteração de experimento do sistema Pré-condição: usuário autenticado Seqüência de eventos: 1. Usuário solicita alteração de experimento no sistema. 2. Sistema lista os experimentos cadastrados. 3. Usuário solicita a alteração de um experimento. 4. Sistema exibe as informações atuais do experimento. 5. Usuário altera as informações que desejar. 6. Usuário confirma alteração. 36 / 68

22 7. Sistema altera o experimento. Pós-condição: Experimento é alterado no sitema. Exceção: 1. Falha na alteração: não há conexão com a Internet (Passo 6). Sistema informa a falha na conexão e cancela a alteração. Inclusão: Não se aplica. Caso de Uso 2.4.1: Recuperação de Experimento Descrição: Este caso de uso descreve o processo de obtenção de experimentos já cadastrados no sistema Evento iniciador: solicitação de recuperação de experimento do sistema Pré-condição: usuário autenticado Seqüência de eventos: 1. Usuário solicita recuperação de experimento no sistema. 2. Sistema lista os experimentos cadastrados. 3. Usuário clica no experimento que deseja visualisar 4. Sistema exibe as informações do experimento. 5. Usuário confirma recuperação de experimento. 37 / 68

23 6. Sistema envia experimento para usuário. Pós-condição: As informações sobre o experimento selecionado foram exibidas. Exceção: 1. Falha na recuperação: não há conexão com a Internet (Passo 3). Sistema informa a falha na conexão. Inclusão: Não se aplica. Caso de Uso 2.4.2: Recuperação de Resultado de Experimento Descrição: Este caso de uso descreve o processo de obtenção de resultado de experimento já cadastrado no sistema Evento iniciador: solicitação de recuperação de experimento do sistema Pré-condição: usuário autenticado Seqüência de eventos: 1. Usuário solicita recuperação de resultado de experimento no sistema. 2. Sistema lista os experimentos cadastrados. 3. Usuário clica no experimento que deseja recuperar o resultado. 4. Sistema exibe as informações do experimento. 5. Usuário confirma recuperação de resultados do experimento. 38 / 68

24 6. Sistema envia resultado do experimento para usuário. Pós-condição: Os resultados sobre o experimento selecionado foram exibidas. Exceção: 1. Falha na recuperação: não há conexão com a Internet (Passo 3). Sistema informa a falha na conexão. Inclusão: Não se aplica. Caso de Uso 3: Consulta Experimento Descrição: Este caso de uso descreve o processo de consulta do acervo de experimentos Evento iniciador: solicitação de consulta de experimento do sistema Pré-condição: usuário autenticado Seqüência de eventos: 1. Usuário solicita consulta de experimentos no sistema. 2. Sistema apresenta os campos a serem preenchidos para a busca. 3. Usuário preenche um ou mais campos para a busca. 4. Usuário confirma busca. 5. Sistema apresenta os resultados. Pós-condição: Usuário realisou a busca de experimentos. 39 / 68

25 Exceção: 1. Falha na recuperação: não há conexão com a Internet (Passo 4). Sistema informa a falha na conexão. Inclusão: Pode-se seguir a este caso de uso os casos de uso 2.4 Recuperação de experimento e o caso de uso de Baixar experimento (Não foi descrito ainda). Caso de Uso 4: Login Descrição: Este caso de uso descreve o processo acesso ao sistema Evento iniciador: abertura do plugin do openmodeller Pré-condição: não há Seqüência de eventos: 1. Usuário solicita abertura do plugin do openmodeller 2. Sistema apresenta os campos a serem preenchidos para o login 3. Usuário preenche 4. Usuário confirma 5. Sistema abre a interface principal Pós-condição: Usuário está autenticado no sistema. 40 / 68

26 Exceção: 1. Falha na autenticação: usuário ou senha inválidos (Passo 5). Sistema informa a falha na autenticação. 2. Falha de conexão: não há conexão com a Internet (Passo 5). Sistema informa a falha na conexão. 3. Falha de comunicação: não há comunicação com o servidor (Passo 5). Sistema informa a falha na comunicação Inclusão: Caso de uso 1.4: Recuperação de usuário Caso de Uso 5: Logoff Descrição: Este caso de uso descreve o processo de saída do sistema Evento iniciador: fechamento da janela do plugin. Pré-condição: usuário autenticado Seqüência de eventos: 1. Usuário fecha a janela do plugin Pós-condição: Usuário está desautenticado no sistema. Exceção: 41 / 68

27 1. Caso ocorra algum erro de comunicação, o usuário terá sua sessão encerrada automaticamente após 5 minutos de inatividade. Inclusão: Caso de uso 1.4: Recuperação de usuário 42 / 68

28 7.1. Diagramas de Casos de Uso Foram descritos, acima, apenas os casos de uso que têm como ator o usuário do sistema. Porém, há uma comunicação entre sistemas (plugin do openmodeller e Servidor no Cluster). Para essa comunicação, mais um ator foi adicionado para se comunicar, via Web Services, com o Cluster. A este ator foi dado o nome de Service Dispatcher. Abaixo, os diagramas de Casos de Uso: 43 / 68

29 44 / 68

30 45 / 68

31 46 / 68

32 47 / 68