Processo de Engenharia de Software II

Transcrição

1 UNIOESTE Universidade Estadual do Oeste do Paraná CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS Colegiado de Ciência da Computação Curso de Bacharelado em Ciência da Computação Processo de Engenharia de Software II FitoDB Sistema para busca e classificação de Morfotipos de Fitólitos Cascavel 2012

2 2 Luiz Gustavo de Souza Juliano Richetti Definição do Problema, Especificação de Requisitos, Modelagem Orientada a Objetos e Modelagem do Banco de Dados Professor: Victor Francisco Araya Santander Cascavel 2012

3 3 Sumário 1. INTRODUÇÃO METODOLOGIA MODELAGEM ORGANIZACIONAL Diagrama SD Diagrama SR REQUISITOS FUNCIONAIS REQUISITOS NÃO FUNCIONAIS CASOS DE USO DIAGRAMA DE CLASSES CONSIDERAÇÕES FINAIS REFERÊNCIAS BIBLIOGRÁFICAS ANEXO: MODELO DE DADOS... 37

4 4 1. INTRODUÇÃO Estudos aprofundados sobre a evolução do Planalto Basáltico no oeste/sudoeste do Paraná e noroeste de Santa Catarina estão sendo realizados pelo grupo de pesquisa Gênese e Evolução de Superfícies Geomórficas e Formações Superficiais, formado na UNIOESTE, campus de Marechal Candido Rondon. Dentre os elementos levantados nestes estudos que compreendem a evolução da paisagem da área geográfica estão os corpúsculos de sílica amorfa, encontrados nas estruturas de plantas e árvores, mais especificamente, em folhas, raízes e casca de caules. Estes corpúsculos ou biomineralizações de Sílica amorfa são chamados de Morfotipos de Fitólitos, e vem sendo usados em estudos de reconstrução da estrutura vegetal das paisagens ao longo do tempo desde antes da ação humana. Com isso, outros dados como clima em escala local ou regional podem ser resgatados pela análise destas substâncias. Segundo [1], reconstruir a vegetação de uma área a partir dos Morfotipos de Fitólitos se baseia em uma fase de extração local da substância encontrada no solo. Ao mesmo tempo se faz a retirada e catalogação desta mesma substância a partir de plantas existentes, e por fim, vem uma fase de comparação dos dois tipos de substâncias, a partir de suas características mórficas, determinando aproximadamente a qual planta pertence a substância proveniente do solo. De acordo com [2], o processo de extração dos Morfotipos de Fitólitos do solo se dá inicialmente pela separação destes das outras substâncias presentes a partir de soluções ácidas ou sódicas. Desta extração, se mantém os Fitólitos, Diatomáceas e outros corpos silicosos, que são preparados em lâminas imersos em óleo para observações em 3D. Seguindo estes passos vem a análise e interpretação dos Morfotipos para obtenção de informações deste solo a cerca da umidade relativa, índice climático e índice de cobertura arbórea. Essas são características que mostram que há a necessidade da implantação de um novo tipo de sistema para o controle, classificação e análise destes processos. Com isto, é proposto neste trabalho um sistema informatizado para agilizar os processos referentes à classificação de Morfotipos de Fitólitos. E é neste contexto que se propõe o sistema em formato web para atender os discentes e docentes do grupo de pesquisa citado e a centralização dos dados no Sistema Gerenciador de Banco de Dados PostgreSQL[3], facilitando e otimizando o armazenamento dos dados para classificação e possibilitando o uso destas informações por toda a comunidade acadêmica. A Figura 1 da um exemplo de fotos dos Morfotipos de Fitólitos que serão inseridas no banco de dados, juntamente com as informações descritivas extraídas de [2].

5 5 Figura. Fotomicromia de morfotipos de fitólitos de Araucariaceae Fonte: [2] Foram realizadas três entrevistas com a professora Doutora Márcia Regina Calegari, que é professora da UNIOESTE campus de Marechal Cândido Rondon, e trabalha com extrações de Morfotipos de Fitólitos, bem como atua no grupo mencionado anteriormente. As entrevistas não foram documentadas, mas serviram de base para o levantamento dos requisitos e definição das tecnologias a serem utilizadas, de acordo com as necessidades de abrangência do sistema. O produto final deste trabalho será de uso então para os pesquisadores da área que atuam na UNIOESTE, bem como a disponibilização dos dados de forma livre na web. Em seguida, será apresentada a metodologia a ser utilizada no desenvolvimento do sistema, um estudo detalhado dos Requisitos Funcionais, Não-Funcionais e especificações e modelagens do banco de dados. 2. METODOLOGIA O método escolhido para o desenvolvimento do sistema foi baseada na escolha de uma metodologia ágil, para que o cliente participe do desenvolvimento do sistema. A maior preocupação é manter contato e participação do cliente ativa, permitindo adaptações nos requerimentos do projeto durante o desenvolvimento. Por se tratar de um sistema acadêmico que será desenvolvido por alunos, foi desenvolvida uma adaptação, baseado nos preceitos das metodologias ágeis [5], permitindo um desenvolvimento dinâmico, ainda que com apenas dois programadores. A metodologia usada neste trabalho será a SCRUM, esta metodologia pode ser usada em projetos pequenos e grandes. Foi criado para se adaptar a constante mudança de interesses e necessidades. Foca o trabalho em equipe, e melhora a comunicação e a cooperação. Não requer nem fornece qualquer método ou técnica específica para a fase de desenvolvimento. As fases de desenvolvimento são dividas em três: Planejamento, Desenvolvimento e Encerramento. O SCRUM divide o time em vários grupos de 6 a 9 pessoas, escolhendo um mestre dentre os 9 para poder resolver os problemas e presidir as reuniões diárias propostas pelo método. O método consiste nas bases do SCRUM que tem por objetivo definir um processo de desenvolvimento iterativo e incremental. Para se ajustar ao projeto da matéria de engenharia de software, o método vai ser feito por apenas uma equipe de dois integrantes, e não terá a participação do cliente tão frequentemente quando o requerido pelo método, reuniões serão feitas de semana em semana para respeitar as atividades de cada integrante.

6 6 3. MODELAGEM ORGANIZACIONAL Nesta seção são apresentados os diagramas de Dependências Estratégicas (SD) e de Razões Estratégicas (SR) do sistema web para busca e classificação de morfotipos de fitólitos, os atores representados nos diagramas serão controlados por um sistema de login e senha já implementado. 3.1 Diagrama SD A Figura abaixo apresenta o diagrama SD (Strategic Dependency).

7 7

8 8 O diagrama apresenta quatro atores, visitante, professor, aluno e administrador, além do ator representante do sistema e do banco de dados. Nenhum ator depende de outro que não o sistema para realizar suas operações. Em ordem inversamente hierárquica, o professor herda as funções do aluno, enquanto aluno herda as do visitante, que também acabam por ser funções do professor. O administrador se diferencia, com ações únicas de gerenciamento dos usuários e do sistema em si. O visitante tem a função principal de busca de Morfotipos de Fitólitos, deixando clara a intenção da disponibilidade do sistema ao público. O aluno, que responde ao respectivo professor orientador, tem funções de cadastros dos Morfotipos, bem como a comparação dos dados. Já o professor, que herda todas estas funções dos outros atores, faz o pedido de relatório de operações de cadastro e também realiza o gerenciamento do aluno ao qual efetuou o cadastro, tendo pelo sistema como um orientado. O ator administrador, que faz o gerenciamento do sistema como mencionado anteriormente, possui funções de gerenciamento de professor, de busca de usuários sem quaisquer restrições e pode realizar o pedido de relatório de atividade do usuário, gerando então um log dos cadastros de Morfotipos de Fitólitos realizados por este. 3.2 Diagrama SR A figura a seguir apresenta o diagrama SR (Strategic Rationale).

9 9

10 10 O diagrama SR notavelmente é uma evolução do diagrama SD apresentado anteriormente. Neste é apresentado de forma mais precisa em relação ao sistema, todas as funções que cada ator desempenha com este. A função de busca de dados do ator visitante esta agora decomposta em buscar dados e apresentar dados, melhorando a visão do que o sistema deve realizar para efetuar a ação desejada. No ator aluno a função de comparação é decomposta nas etapas de fornecimento de dados, analise, comparação com o banco de dados e geração da saída. Além desta, a gerência de Fitólitos é definida pelas funções de inserção, alteração e remoção, que realizam as ações de fornecimento, atualização em banco de dados e busca de dados, tudo de acordo com sua necessidade. O ator professor realiza a gerencia de aluno, que recebe a mesma decomposição que a gerencia de Fitólitos, enquanto a função de relatório de cadastro é decomposta em relatório de Fitólito de planta e de solo. Já o administrador realiza a gerencia de professor da mesma forma como é feita para aluno, e para o relatório de atividade, é feita a decomposição em busca de dados, formatação e apresentação dos dados. 4. REQUISITOS FUNCIONAIS Os requisitos funcionais de um sistema descrevem as diversas funções que os administradores e usuários do sistema almejam que o software ofereça. Nesta primeira parte, são exibidos os requisitos funcionais do sistema de forma geral, descrevendo dos mesmos, apresentando em seguida a Figura 4 com o diagrama dos requisitos funcionais. O sistema envolve os seguintes tipos de usuário: Administrador, Aluno e Professor comum, onde cada um terá um nível de acesso delimitado de acordo com as características que cada usuário necessita para trabalhar no sistema. Como o sistema é web, tal controle é feito utilizando login e senha, porem não é necessário um login, pois é possível entrar como visitante, impossibilitando a este usuário o uso de qualquer operação que mude dados no banco de dados do sistema. Os usuários são organizados hierarquicamente, na ordem crescente Aluno, Professor e Administrador, onde todas as funções de Aluno são realizadas pelo Professor e subsequentemente as funções realizadas pelo Professor são livres para Administrador, e as deste não são repassadas aos outros tipos. [RF-01] - Cadastra Filo O sistema deve permitir a inserção de um novo Filo no banco de dados. Prioridade: Alta. [RF-02] - Edita Filo O sistema deve permitir modificações de informações referentes a um filo no banco de dados. Neste caso o usuário pode apenas editar os filos cadastrados por ele, impedindo a alteração liberada de qualquer dado do banco de dados.

11 11 Prioridade: Média. [RF-03] - Remove Filo O sistema deve permitir a exclusão de um filo cadastrado no banco de dados. Prioridade: Baixa. [RF-04] - Cadastra Classe O sistema deve permitir a inserção de uma nova classe no banco de dados. Prioridade: Alta. [RF-05] - Edita Classe O sistema deve permitir modificações de informações referentes a uma classe no banco de dados. Neste caso o usuário pode apenas editar as classes cadastradas por ele, impedindo a alteração liberada de qualquer dado do banco de dados. Prioridade: Média [RF-06] - Remove Classe O sistema deve permitir excluir uma classe cadastrada no banco de dados. Prioridade: Baixa. [RF-07] - Cadastra Ordem O sistema deve permitir a inserção de uma nova ordem no banco de dados. Prioridade: Alta. [RF-08] - Edita Ordem O sistema deve permitir modificações de informações referentes a uma ordem no banco de dados. Neste caso o usuário pode apenas editar as ordens cadastradas por ele, impedindo a alteração liberada de qualquer dado do banco de dados. Prioridade: Média [RF-09] - Remove Ordem O sistema deve permitir a exclusão de uma ordem cadastrada no banco de dados. Prioridade: Baixa. [RF-10] - Cadastra Família

12 12 O sistema deve permitir a inserção de uma nova família no banco de dados Prioridade: Alta. [RF-11] - Edita Família O sistema deve permitir modificações de informações referentes a uma família no banco de dados. Neste caso o usuário pode apenas editar as famílias cadastradas por ele, impedindo a alteração liberada de qualquer dado do banco de dados. Prioridade: Média. [RF-12] - Remove Família O sistema deve permitir a exclusão de uma família cadastrada no banco de dados. Prioridade: Baixa. [RF-13] - Cadastra Gênero O sistema deve permitir a inserção de um novo gênero no banco de dados. Prioridade: Alta. [RF-14] - Edita Gênero O sistema deve permitir a modificação de informações referentes a um gênero no banco de dados. Neste caso o usuário pode apenas editar os gêneros cadastrados por ele, impedindo a alteração liberada de qualquer dado do banco de dados. Prioridade: Média. [RF-15] - Remove Gênero O sistema deve permitir exclusão de um gênero cadastrado no banco de dados. Prioridade: Baixa. [RF-16] - Cadastra Espécie O sistema deve permitir a inserção de uma nova espécie no banco de dados. Prioridade: Alta. [RF-17] - Edita Espécie O sistema deve permitir a modificação de informações referentes a uma espécie no banco de dados. Neste caso o usuário pode apenas editar as espécie cadastradas por ele, impedindo a alteração liberada de qualquer dado do banco de dados.

13 13 Prioridade: Média. [RF-18] - Remove Espécie O sistema deve permitir a exclusão de uma espécie cadastrada no banco de dados. Prioridade: Baixa. [RF-19] - Cadastra tipo de vegetação O sistema deve permitir a inserção de um novo tipo de vegetação no banco de dados. Prioridade: Alta. [RF-20] - Edita tipo de vegetação O sistema deve permitir modificações de informações referentes a um tipo de vegetação no banco de dados. Neste caso o usuário pode apenas editar os tipos de vegetação cadastrados por ele, impedindo a alteração liberada de qualquer dado do banco de dados. Prioridade: Média. [RF-21] - Remove tipo de vegetação O sistema deve permitir a exclusão de um tipo de vegetação cadastrada no banco de dados. Prioridade: Baixa. [RF-22] - Cadastra Planta O sistema deve permitir a inserção de uma nova planta no banco de dados. Prioridade: Alta. [RF-23] - Edita Planta O sistema deve permitir modificações de informações referentes a uma planta no banco de dados. Neste caso o usuário pode apenas editar as plantas cadastradas por ele, impedindo a alteração liberada de qualquer dado do banco de dados. Prioridade: Média. [RF-24] - Remove Planta O sistema deve permitir a exclusão de uma planta cadastrada no banco de dados. Prioridade: Baixa. [RF-25] - Adiciona foto de planta

14 14 O sistema deve permitir anexar fotos à planta no banco de dados, permitindo mais de uma foto por planta. Neste caso o usuário pode apenas adicionar as fotos de plantas cadastradas por ele, impedindo a alteração liberada de qualquer dado do banco de dados. Prioridade: Baixa. [RF-26] - Cadastra parte de planta O sistema deve permitir a inserção dos dados de uma parte de planta no banco de dados. Prioridade: Alta. [RF-27] - Edita parte de planta O sistema deve permitir edição dos dados de uma parte de planta já cadastrada. Neste caso o usuário pode apenas editar as partes de planta cadastradas por ele, impedindo a alteração liberada de qualquer dado do banco de dados. Prioridade: Média. [RF-28] Remove parte de planta O sistema deve permitir a exclusão de uma parte de planta qualquer cadastrada pelo usuário no banco de dados. Prioridade: Baixa. [RF-29] - Adiciona foto de parte de planta O sistema deve permitir a anexação da foto à parte de planta no banco de dados, permitindo mais de uma foto por parte de planta. Neste caso o usuário pode apenas adicionar as fotos de partes de planta cadastradas por ele, impedindo a alteração liberada de qualquer dado do banco de dados. Prioridade: Baixa. [RF-30] - Cadastra Fitólito de planta O sistema deve permitir a inserção dos dados de um Fitólito de planta no banco de dados. Prioridade: Alta. [RF-31] - Edita Fitólito de planta O sistema deve permitir a edição de dados de um Fitólito de planta já cadastrado. Neste caso o usuário pode apenas editar os Fitólitos de planta cadastrados por ele, impedindo a alteração liberada de qualquer dado do banco de dados. Prioridade: Média. [RF-32] - Remove Fitólito de planta

15 15 O sistema deve permitir a exclusão de um Fitólito de planta cadastrado no banco de dados. Neste caso o usuário pode apenas excluir os Fitólitos de planta cadastrados por ele, impedindo a alteração liberada de qualquer dado do banco de dados. Prioridade: Baixa. [RF-33] - Adiciona foto de Fitólito de planta O sistema deve permitir anexar fotos ao Fitólito de planta dentro do banco de dados, o que permite mais de uma foto para cada. Neste caso o usuário pode apenas adicionar as fotos de Fitólitos de planta cadastrados por ele, impedindo a alteração liberada de qualquer dado do banco de dados. Prioridade: Baixa. [RF-34] - Cadastra Fitólito de solo O sistema deve permitir a inserção dos dados de um fitólito de solo no banco de dados Prioridade: Alta. [RF-35] - Edita Fitólito de solo O sistema deve permitir a edição de dados de um Fitólito de solo no banco de dados. Neste caso o usuário pode apenas editar os Fitólitos de solo cadastrados por ele, impedindo a alteração liberada de qualquer dado do banco de dados. Prioridade: Média. [RF-36] - Remove Fitólito de solo O sistema deve permitir a exclusão de um Fitólito de solo cadastrado no banco de dados. Neste caso o usuário pode apenas excluir os Fitólitos de solo cadastrados por ele, impedindo a alteração liberada de qualquer dado do banco de dados. Prioridade: Baixa. [RF-37] - Adiciona fito de Fitólito de solo O sistema deve permitir anexar fotos ao Fitólito de solo dentro do banco de dados, o que permite mais de uma foto para cada. Neste caso o usuário pode apenas adicionar fotos dos Fitólitos de solo cadastrados por ele, impedindo a alteração liberada de qualquer dado do banco de dados. Prioridade: Baixa. [RF-38] - Cadastra Estado O sistema deve permitir a inserção de um estado ou unidade federativa no banco de dados, utilizado para mapeamento dos locais de extração de fitólitos, seja de planta ou de solo.

16 16 Prioridade: Média. [RF-39] - Edita Estado O sistema deve permitir a edição de um estado ou unidade federativa no banco de dados. Prioridade: Média. [RF-40] - Remove Estado O sistema deve permitir exclusão de um estado ou unidade federativa cadastrado no banco de dados. Prioridade: Baixa. [RF-41] - Cadastra Cidade O sistema deve permitir a inserção de uma cidade no banco de dados. Prioridade: Média. [RF-42] - Edita Cidade O sistema deve permitir a edição de uma cidade no banco de dados. Prioridade: Média. [RF-43] - Remove Cidade O sistema deve permitir uma cidade cadastrada no banco de dados. Prioridade: Baixa. [RF-44] - Cadastra Posição Geográfica O sistema deve permitir a inserção de uma posição geográfica, sendo estas Latitude e Longitude, no banco de dados. Prioridade: Média. [RF-45] - Edita Posição Geográfica O sistema deve permitir modificações e edição de uma posição geográfica, sendo estas Latitude e Longitude, no banco de dados. Prioridade: Média. [RF-46] - Remove Posição Geográfica O sistema deve permitir exclua uma posição geográfica, sendo estas Latitude e Longitude, cadastrada no banco de dados. Prioridade: Baixa. [RF-47] - Cadastra Classe de solo O sistema deve permitir a inserção de uma classe de solo no banco de dados.

17 17 Prioridade: Alta. [RF-48] - Edita Classe de solo O sistema deve permitir que o Aluno edite uma classe de solo no banco de dados. Prioridade: Média. [RF-49] - Remove Classe de solo O sistema deve permitir exclua uma classe de solo cadastrada no banco de dados. Prioridade: Baixa. [RF-50] - Consulta Fitólito de planta O sistema deve permitir a consulta dos dados de um Fitólito de planta no banco de dados, apresentando os dados cadastrados juntamente com as fotos anexadas em banco. Solicitante: Aluno Prioridade: Alta. [RF-51] - Consulta Fitólito de solo O sistema deve permitir a consulta dos dados de um Fitólito de solo no banco de dados, apresentando os dados cadastrados juntamente com as fotos anexadas em banco. Prioridade: Alta. [RF-52] - Cadastra Aluno O sistema deve permitir o cadastro de aluno orientado. Apenas professor pode cadastrar novos alunos. Solicitante: Professor. Prioridade: Alta. [RF-53] - Edita Aluno O sistema deve permitir a edição de cadastro de aluno, que pode apenas ser realizado pelo próprio aluno. Prioridade: Média. [RF-54] - Remove Aluno O sistema deve permitir a remoção de aluno cadastrado no sistema. Apenas o professor orientador pode remover o aluno. Solicitante: Professor. Prioridade: Baixa. [RF-55] - Busca Professor O sistema deve permitir a consulta de um professor cadastrado, a fim de saber os dados cadastrados por ele.

18 18 Solicitante: Professor. Prioridade: Baixa. [RF-56] - Cadastra Professor O sistema deve permitir a inserção de novo professor no banco de dados. Apenas o Administrador pode cadastrar professores. Solicitante: Administrador. Prioridade: Alta. [RF-57] - Edita Professor O sistema deve permitir a edição de cadastro de professor, que pode apenas ser realizado pelo próprio professor. Solicitante: Professor. Prioridade: Média. [RF-58] - Remove Professor O sistema deve permitir a remoção de professor no sistema. Esta operação não remove efetivamente do banco, pois seu registro é necessário para saber quais dados foram cadastrados por ele. Solicitante: Administrador. Prioridade: Baixa. *RF: Requisito Funcional. 5. REQUISITOS NÃO FUNCIONAIS Os requisitos não funcionais referem-se a aspectos não-funcionais do sistema, como restrições nas quais o sistema deve operar ou propriedades emergentes do sistema. O sistema está dividido nos seguintes requisitos nãofuncionais: utilidade, usabilidade, confiabilidade e segurança dos dados, segurança do sistema e manutenção. Segue abaixo a especificação de cada um deles e, posteriormente a figura do diagrama dos requisitos não funcionais. Quanto à Utilidade [RNF-01] Facilidade de uso O sistema deve ser fácil de usar, o cliente não pode encontrar dificuldades de uso para uma boa aceitação do sistema em futuros projetos. Para tanto, espera-se simplicidade e objetividade no sistema, principalmente com a junção dos requisitos funcionais para a visão do usuário. Quanto à Usabilidade [RNF-02] Interação Humano-computador

19 19 O sistema deve ser fácil de entender e usar, com isso algumas funcionalidades que contribuem são teclas de atalho, interface intuitiva e bem organizada, feedback informativo e manuais de utilização. [RNF-03] Acessibilidade Importante para o sistema é a possibilidade do uso do sistema por pessoas que possuam algum tipo de deficiência. Quanto à Confiabilidade e Segurança dos Dados [RNF-04] Confiabilidade dos dados O sistema deve realizar confirmações quando algum dado for inserido ou modificado. Tais alterações apenas poderão ser feitas por usuários administradores que recebem os direitos do administrador, designado ao coordenador do projeto. [RNF-05] Modelagem formalizada Para uma maior sustentação dos dados, é de suma importância a modelagem, tanto entidade-relacionamento quanto a relacional formalizada, garantindo que o banco de dados fique bem consistente, rápido e confiável. Quanto à Segurança do Sistema [RNF-06] Restrições de acesso O sistema será primariamente aberto à comunidade acadêmica para buscas e consultas gerais, que não afetarão nos dados já armazenados. Já para usuários que necessitam de acesso direto ao banco de dados para cadastro de novos morfotipos, é esperado uma interface diferenciada de acesso por senha para garantir uma boa manutenção dos dados. Quanto à Manutenção [RNF-07] Linguagem Java O uso da linguagem Java é bastante incentivada nos cursos de graduação. Sendo este um sistema de propósitos acadêmicos, a escolha de alunos que possam trabalhar para a melhoria deste fica bastante facilitada por estes fatores. [RNF-08] SGBD PostgreSQL O Sistema Gerenciador de Bancos de Dados PostgreSQL é um dos mais visados nas várias áreas de TI, inclusive acadêmicas, por se tratar de um Software Livre. Este é bastante robusto e aplica perfeitamente as restrições ACID (Atomicidade, Consistência, Isolamento e Durabilidade), e terá bastante facilidade de manutenção por qualquer acadêmico com os conhecimentos de Bancos de Dados.

20 20 [RNF-09] Web JSF O uso do Framework JSF para desenvolvimento Web permite a integração com a linguagem Java, sendo então complementadora da escolha principal da linguagem, mantendo a disponibilidade do sistema na web. [RNF-10] Documentação Completa Já faz parte do objetivo do trabalho a definição completa da documentação do Sistema, porém, aqui é reforçada a facilidade de manutenção tendo em mãos a documentação completa usada como base para o desenvolvimento para este sistema. [RNF-11] Manual do Usuário A criação de um manual para o usuário, além de ser vantagem para a usabilidade, também facilita no entendimento do que se esperava da execução das funções desenvolvidas para o sistema, facilitando também na manutenção. O manual será off-line. *RNF: Requisito não funcional.

21 21

22 6. CASOS DE USO O diagrama de casos de uso vem com o objetivo de apresentar o sistema na visão dos usuários, colocados ali como atores. É apresentado em seguida o diagrama, seguido da especificação de cada caso de uso. 22

23 23

24 24 Caso de Uso-01: Gerencia Aluno INFORMAÇÃO CARACTERÍSTICA: Oferece a opção das ações a serem realizadas com dados de Aluno. Objetivo no Contexto: Realiza a gerência dos dados de um Aluno no Banco de dados. Pré-Condições: Aluno ou Professor logado no sistema. Condição Final de Sucesso: É apresentada a tela relacionada à opção escolhida. Condição Final de Falha: Mensagem de erro. Ator Primário: Aluno e Professor. CENÁRIO PRINCIPAL(Primary Scenario): 1. Escolha entre as opções Altera, Cadastra e Remove. EXTENSÕES (Extends): 1.1. Com a escolha de Altera, leva ao caso de uso XXX Com a escolha de Cadastra, leva ao caso de uso XXX Com a escolha de Remove, leva ao caso de uso XXX. Requisitos Especiais (Special Requirements): NFR 1: Usabilidade. Caso de Uso-02: Insere Aluno INFORMAÇÃO CARACTERÍSTICA: Realiza o cadastro de alunos, que serão vinculados ao professor requisitante. Objetivo no Contexto: Cadastrar novo aluno no sistema. Pré-Condições: Professor logado no sistema. Condição Final de Sucesso: Dados do aluno são inseridos no banco de dados, retornando uma mensagem de sucesso. Condição Final de Falha: Mensagem de erro. Ator Primário: Professor. CENÁRIO PRINCIPAL(Primary Scenario): 1. O Professor faz requisição de cadastro de aluno. 2. O Professor informa os dados cadastrais do aluno. 3. O Professor confere os dados e confirma a inserção. Requisitos Especiais (Special Requirements): NFR 2: Usabilidade. Caso de Uso-03: Altera Aluno INFORMAÇÃO CARACTERÍSTICA: Realiza alteração de dados do aluno vinculado ao professor requisitante. Objetivo no Contexto: Alterar dados cadastrais do aluno. Pré-Condições: Professor logado no sistema. Condição Final de Sucesso: Dados do aluno requerido são alterados no banco de dados, retornando uma mensagem de sucesso. Condição Final de Falha: Mensagem de erro. Ator Primário: Professor. CENÁRIO PRINCIPAL(Primary Scenario): 1. O Professor faz requisição de alteração de aluno. 2. O Sistema realiza a busca do aluno vinculado. 3. O Professor altera os dados cadastrais. 4. O Professor confere os dados e confirma a alteração. EXTENSÕES (Extends): 2.1. O Sistema retorna a mensagem de erro caso não encontre o aluno. Requisitos Especiais (Special Requirements):

25 25 NFR 2: Usabilidade. Caso de Uso-04: Remove Aluno INFORMAÇÃO CARACTERÍSTICA: Realiza a retirada de direito de uso do sistema para o um Aluno. Objetivo no Contexto: Modifica o estado do cadastro do aluno. Pré-Condições: Professor logado no sistema. Condição Final de Sucesso: É invalidado o cadastro, não removendo-o do sistema, retornando uma mensagem de sucesso. Condição Final de Falha: Mensagem de erro. Ator Primário: Professor. CENÁRIO PRINCIPAL(Primary Scenario): 1. O Professor faz requisição de remoção de aluno. 2. O Sistema realiza a busca do aluno vinculado. 3. O Professor confere os dados e confirma a remoção. EXTENSÕES (Extends): 2.1. O Sistema retorna a mensagem de erro caso não encontre o aluno. Requisitos Especiais (Special Requirements): NFR 2: Usabilidade. Caso de Uso-05: Gerencia Fitólito de Solo INFORMAÇÃO CARACTERÍSTICA: Oferece a opção das ações a serem realizadas com dados de Fitólitos de Solo. Objetivo no Contexto: Realiza a gerência dos dados de um Fitólito de Solo no Banco de dados. Pré-Condições: Aluno ou Professor logado no sistema. Condição Final de Sucesso: É apresentada a tela relacionada à opção escolhida. Condição Final de Falha: Mensagem de erro. Ator Primário: Aluno e Professor. CENÁRIO PRINCIPAL(Primary Scenario): 1. Escolha entre as opções Altera, Cadastra e Remove. EXTENSÕES (Extends): 1.1. Com a escolha de Altera, leva ao caso de uso XXX Com a escolha de Cadastra, leva ao caso de uso XXX Com a escolha de Remove, leva ao caso de uso XXX. Requisitos Especiais (Special Requirements): NFR 1: Usabilidade. Caso de Uso-06: Insere Fitólito de Solo INFORMAÇÃO CARACTERÍSTICA: Realiza a inserção de um novo registro de Fitólito de Solo. Objetivo no Contexto: Realiza a inserção dos dados de um novo Fitólito no banco de dados. Pré-Condições: Aluno ou Professor logado no sistema. Condição Final de Sucesso: Dados são inseridos no banco de dados, retornando uma mensagem de sucesso. Condição Final de Falha: Mensagem de erro. Ator Primário: Aluno e Professor. CENÁRIO PRINCIPAL(Primary Scenario): 1. O Aluno ou Professor faz requisição de cadastro de Fitólito de solo. 2. O Aluno ou Professor fornece os dados. 3. O Aluno ou Professor confere os dados e confirma a inserção.

26 26 Requisitos Especiais (Special Requirements): NFR 1: Usabilidade. Caso de Uso-07: Altera Fitólito de Solo INFORMAÇÃO CARACTERÍSTICA: Realiza a alteração de registro de Fitólito de Solo Objetivo no Contexto: Realiza a alteração dos dados de um Fitólito já cadastrado no banco de dados. Pré-Condições: Aluno ou Professor logado no sistema Condição Final de Sucesso: Dados do registro é alterado no banco de dados, retornando uma mensagem de sucesso. Condição Final de Falha: Mensagem de erro. Ator Primário: Aluno e Professor. CENÁRIO PRINCIPAL(Primary Scenario): 1. O Aluno ou Professor faz requisição de alteração de Fitólito de solo. 2. O Sistema realiza a busca do Fitólito requerido. 3. O Aluno ou Professor altera os dados. 4. O Aluno ou Professor confere os dados alterados e confirma a alteração. EXTENSÕES (Extends): 2.1. O Sistema realiza a listagem completa de Fitólitos de Solo para selecionar manualmente O Sistema retorna mensagem de erro caso não encontre o Fitólito. Requisitos Especiais (Special Requirements): NFR 1: Usabilidade e Integridade dos dados. Caso de Uso-08: Remove Fitólito de Solo INFORMAÇÃO CARACTERÍSTICA: Realiza a remoção de registro de Fitólito de Solo. Objetivo no Contexto: Realiza a remoção dos dados de um Fitólito de Solo já cadastrado no banco de dados. Pré-Condições: Aluno ou Professor logado no sistema. Condição Final de Sucesso: Os dados são removidos do banco de dados, retornando uma mensagem de sucesso. Condição Final de Falha: Mensagem de erro. Ator Primário: Aluno e Professor. CENÁRIO PRINCIPAL(Primary Scenario): 1. O Aluno ou Professor faz requisição da remoção de Fitólito de solo. 2. O Sistema realiza a busca do Fitólito requerido. 3. O Aluno ou Professor confere o registro e confirma a remoção. EXTENSÕES (Extends): 2.1. O Sistema realiza a listagem completa de Fitólitos de Solo para selecionar manualmente O Sistema retorna mensagem de erro caso não encontre o Fitólito. Requisitos Especiais (Special Requirements): NFR 1: Usabilidade e Integridade dos dados. Caso de Uso-09: Gerencia Fitólito de Solo INFORMAÇÃO CARACTERÍSTICA: Oferece a opção das ações a serem realizadas com dados de Fitólitos de Planta. Objetivo no Contexto: Realiza a gerência dos dados de um Fitólito de Planta no Banco de dados. Pré-Condições: Aluno ou Professor logado no sistema.

27 27 Condição Final de Sucesso: É apresentada a tela relacionada à opção escolhida. Condição Final de Falha: Mensagem de erro. Ator Primário: Aluno e Professor. CENÁRIO PRINCIPAL(Primary Scenario): 1. Escolha entre as opções Altera, Cadastra e Remove. EXTENSÕES (Extends): 1.1. Com a escolha de Altera, leva ao caso de uso XXX Com a escolha de Cadastra, leva ao caso de uso XXX Com a escolha de Remove, leva ao caso de uso XXX. Requisitos Especiais (Special Requirements): NFR 1: Usabilidade. Caso de Uso-10: Insere Fitólito de Planta INFORMAÇÃO CARACTERÍSTICA: Realiza a inserção de um novo registro de Fitólito de Planta. Objetivo no Contexto: Realiza a inserção dos dados de um novo Fitólito no banco de dados. Pré-Condições: Aluno ou Professor logado no sistema. Condição Final de Sucesso: Dados são inseridos no banco de dados, retornando uma mensagem de sucesso. Condição Final de Falha: Mensagem de erro. Ator Primário: Aluno e Professor. CENÁRIO PRINCIPAL(Primary Scenario): 1. O Aluno ou Professor faz requisição de cadastro de Fitólito de Planta. 2. O Aluno ou Professor fornece os dados. 3. O Aluno ou Professor confere os dados e confirma a inserção. Requisitos Especiais (Special Requirements): NFR 1: Usabilidade. Caso de Uso-11: Altera Fitólito de Planta INFORMAÇÃO CARACTERÍSTICA: Realiza a alteração de registro de Fitólito de Planta. Objetivo no Contexto: Realiza a alteração dos dados de um Fitólito já cadastrado no banco de dados. Pré-Condições: Aluno ou Professor logado no sistema. Condição Final de Sucesso: Dados do registro é alterado no banco de dados, retornando uma mensagem de sucesso. Condição Final de Falha: Mensagem de erro. Ator Primário: Aluno e Professor. CENÁRIO PRINCIPAL(Primary Scenario): 1. O Aluno ou Professor faz requisição de alteração de Fitólito de Planta. 2. O Sistema realiza a busca do Fitólito requerido. 3. O Aluno ou Professor altera os dados. 4. O Aluno ou Professor confere os dados alterados e confirma a alteração. EXTENSÕES (Extends): 2.1. O Sistema realiza a listagem completa de Fitólitos de Planta para selecionar manualmente O Sistema retorna mensagem de erro caso não encontre o Fitólito. Requisitos Especiais (Special Requirements): NFR 1: Usabilidade e Integridade dos dados. Caso de Uso-12: Remove Fitólito de Planta

28 28 INFORMAÇÃO CARACTERÍSTICA: Realiza a remoção de registro de Fitólito de Planta. Objetivo no Contexto: Realiza a remoção dos dados de um Fitólito de Planta já cadastrado no banco de dados. Pré-Condições: Aluno ou Professor logado no sistema. Condição Final de Sucesso: Os dados são removidos do banco de dados, retornando uma mensagem de sucesso. Condição Final de Falha: Mensagem de erro. Ator Primário: Aluno e Professor. CENÁRIO PRINCIPAL(Primary Scenario): 1. O Aluno ou Professor faz requisição da remoção de Fitólito de Planta. 2. O Sistema realiza a busca do Fitólito requerido. 3. O Aluno ou Professor confere o registro e confirma a remoção. EXTENSÕES (Extends): 2.1. O Sistema realiza a listagem completa de Fitólitos de Planta para selecionar manualmente O Sistema retorna mensagem de erro caso não encontre o Fitólito. Requisitos Especiais (Special Requirements): NFR 1: Usabilidade e Integridade dos dados. Caso de Uso-13: Busca Usuários INFORMAÇÃO CARACTERÍSTICA: Realiza a busca de professor ou aluno, apresentando os dados e cadastros realizados. Objetivo no Contexto: Verificar dados, cadastros e atividades de um usuário. Pré-Condições: Administrador logado no sistema. Condição Final de Sucesso: Dados do usuário são apresentados na tela. Condição Final de Falha: Mensagem de erro. Ator Primário: Administrador. CENÁRIO PRINCIPAL(Primary Scenario): 1. O Administrador faz requisição de busca de usuário. 2. O Administrador informa o nome do usuário requerido. EXTENSÕES (Extends): 2.1. O Sistema realiza a listagem completa dos usuários, separados por tipo. Requisitos Especiais (Special Requirements): NFR 1: Usabilidade. Caso de Uso-14: Gerencia Professor INFORMAÇÃO CARACTERÍSTICA: Oferece a opção das ações a serem realizadas com dados de Professor. Objetivo no Contexto: Realiza a gerência dos dados de um Professor no Banco de dados. Pré-Condições: Administrador logado no sistema. Condição Final de Sucesso: É apresentada a tela relacionada à opção escolhida. Condição Final de Falha: Mensagem de erro. Ator Primário: Administrador. CENÁRIO PRINCIPAL(Primary Scenario): 1. Escolha entre as opções Altera, Cadastra e Remove. EXTENSÕES (Extends): 1.1. Com a escolha de Altera, leva ao caso de uso XXX Com a escolha de Cadastra, leva ao caso de uso XXX Com a escolha de Remove, leva ao caso de uso XXX.

29 29 Requisitos Especiais (Special Requirements): NFR 1: Usabilidade. Caso de Uso-15: Insere Professor INFORMAÇÃO CARACTERÍSTICA: Realiza o cadastro de Professor. Objetivo no Contexto: Cadastrar novo professor no sistema. Pré-Condições: Administrador logado no sistema. Condição Final de Sucesso: Dados do professor são inseridos no banco de dados, retornando uma mensagem de sucesso. Condição Final de Falha: Mensagem de erro. Ator Primário: Administrador CENÁRIO PRINCIPAL(Primary Scenario): 1. O Administrador faz requisição de cadastro do professor. 2. O Administrador informa os dados cadastrais do professor. 3. O Administrador confere os dados e confirma a inserção. Requisitos Especiais (Special Requirements): NFR 2: Usabilidade. Caso de Uso-16: Altera Professor INFORMAÇÃO CARACTERÍSTICA: Realiza alteração de dados de um professor. Objetivo no Contexto: Alterar dados cadastrais do professor. Pré-Condições: Administrador logado no sistema. Condição Final de Sucesso: Dados do professor requerido são alterados no banco de dados, retornando uma mensagem de sucesso. Condição Final de Falha: Mensagem de erro. Ator Primário: Administrador. CENÁRIO PRINCIPAL(Primary Scenario): 1. O Administrador faz requisição de alteração de professor. 2. O Sistema realiza a busca do professor. 3. O Administrador altera os dados cadastrais do professor. 4. O Administrador confere os dados e confirma a alteração. EXTENSÕES (Extends): 2.1. O Sistema retorna a mensagem de erro caso não consiga realizar a operação ou achar o usuário. Requisitos Especiais (Special Requirements): NFR 2: Usabilidade. Caso de Uso-17: Remove Professor INFORMAÇÃO CARACTERÍSTICA: Realiza a retirada de direito de uso do sistema para o um Professor. Objetivo no Contexto: Modifica o estado do cadastro do Professor. Pré-Condições: Administrador logado no sistema. Condição Final de Sucesso: É invalidado o cadastro, não removendo-o do sistema, retornando uma mensagem de sucesso. Condição Final de Falha: Mensagem de erro. Ator Primário: Professor. CENÁRIO PRINCIPAL(Primary Scenario): 1. O Professor faz requisição de remoção de Professor. 2. O Sistema realiza a busca do Professor vinculado. 3. O Professor confere os dados e confirma a remoção. EXTENSÕES (Extends): 2.1. O Sistema retorna a mensagem de erro caso não encontre o Professor.

30 30 Requisitos Especiais (Special Requirements): NFR 2: Usabilidade. Caso de Uso-18: Consulta Fitólito INFORMAÇÃO CARACTERÍSTICA: Permite a um usuário visitante consultar os Fitólitos cadastrados e permitidos. Objetivo no Contexto: Permitir a consulta e verificação dos dados por usuários visitantes. Condição Final de Sucesso: É apresentado os dados pesquisados. Condição Final de Falha: Mensagem de erro. Ator Primário: Visitante. CENÁRIO PRINCIPAL(Primary Scenario): 1. Usuário faz requisição de busca de Fitólito de Planta. EXTENSÕES (Extends): 1.1. O Sistema realiza a requisição de busca de Fitólito de Planta. Requisitos Especiais (Special Requirements): NFR 1: Usabilidade e Integridade dos dados. 7. DIAGRAMA DE CLASSES O Diagrama de classes representa a organização e estruturação básica das classes do sistema. Este facilita na visão do sistema pelo programador que fará sua implementação. É apresentado na figura abaixo o diagrama e em seguida uma breve definição de cada classe.

31 31

32 32 Usuário Classe base para usuários do sistema, com exceção de usuário visitante, que não necessita registro no sistema. É utilizada para definir os dados comuns dos tipos de usuários, seu identificador, senha, nome, sobrenome, e tipo, que é um identificador que indica que tipo de usuário ele é, dado de referencia para o banco de dados. Por ser uma classe privada, seus métodos se objetivam apenas em fornecer os dados destas variáveis. Administrador Esta classe é uma extensão ou herança da classe Usuário, por se tratar de um tipo de usuário, possuindo todos os seus atributos de tal. O Administrador do sistema possui apenas dois métodos de controle, para cadastrar e remover um professor orientador do banco de dados. A remoção não se dá totalmente, apenas fica invalidado o acesso deste usuário, pois qualquer ação deste enquanto ativo deve ser registrada, e no caso de perder estas informações, o banco de dados teria uma inconsistência por falta de informações. Orientador Este também é uma extensão da classe Aluno, que por sua vez é uma extensão da classe Usuário, que define o professor orientador. Este possui métodos para gerenciar cadastro e remoção de aluno, da mesma forma como o Administrador o faz com professor orientador, mantendo cadastro mesmo que removido para manter os dados. Além destes, o professor pode realizar busca de orientador, e verificar as suas ações no sistema, bem como a busca de alunos cadastrados por ele, para a mesma referência. Possui também todos os métodos da classe Aluno e Usuário, bem como seus atributos, por se tratar de uma herança. Para que não haja perdas de informação, é confiado ao professor editar as classes: Filo, Classe, Ordem, Familia, Genero, Especie, CSolo e TVege, pois estes dados serão comuns a muitos cadastros, e não pode ser liberado a qualquer usuário para ser editado. Aluno Esta classe é uma extensão da classe Usuário, possuindo seus atributos é métodos. Além disto, este possui métodos próprios para realizar o cadastro das informações referentes ao banco de dados, tendo em si os métodos de cadastro, edição e remoção de objetos das classes FitoP e FitoS, comparação entre fitólito de planta e de solo e sua remoção, edição de objetos da classe planta e pplanta e edição de seu próprio perfil. Para os métodos de edição re moção de informações, é necessário que estas tenham sido criadas por ele, para haver melhor controle de uso de informações do banco de dados, para que não haja inconsistências. Na ação de cadastrar um FitoP ou FitoS, caso se faça necessário pela falta de informações do banco de dados, é possível cadastrar qualquer uma das classes necessárias, tais quais: Filo, Classe, Ordem, Familia, Genero, Especie, TVege e CSolo, pois estes objetos estão instanciados dentro da classe para cadastro.

33 33 Filo Classe que representa um Filo cadastrado no banco de dados, com seus atributos privados referenciados do banco de dados, com métodos para repasse e modificação destas informações. Classe Classe que representa uma Classe cadastrada no banco de dados, com seus atributos privados referenciados do banco de dados, com métodos para repasse e modificação destas informações. Ordem Classe que representa uma Ordem cadastrada no banco de dados, com seus atributos privados referenciados do banco de dados, com métodos para repasse e modificação destas informações. Família Classe que representa uma Família cadastrada no banco de dados, com seus atributos privados referenciados do banco de dados, com métodos para repasse e modificação destas informações. Gênero Classe que representa um Gênero cadastrado no banco de dados, com seus atributos privados referenciados do banco de dados, com métodos para repasse e modificação destas informações. Espécie Classe que representa uma espécie cadastrada no banco de dados, com seus atributos privados referenciados do banco de dados, com métodos para repasse e modificação destas informações. Planta Esta classe representa a planta armazenada no banco de dados, para referência aos Fitólitos que são extraídos dela. Por ser uma classe modelo, possui apenas os atributos referentes ao banco de dados de forma privada, com métodos para repasse e modificação destas informações. PPlanta Esta classe define uma parte isolada de planta, para definição de qual tipo de Fitólito é extraído de uma parte específica. Por ser uma classe modelo, possui apenas os atributos referentes ao banco de dados de forma privada, com métodos para repasse e modificação destas informações. TVege Representa um tipo de vegetação na qual a planta extraída foi encontrada. Por ser uma classe modelo, possui apenas os atributos referentes ao banco de dados de forma privada, com métodos para repasse e modificação destas informações.

34 34 Pos Define-se por uma classe que representa uma posição geográfica, com valores de latitude e longitude. Por ser uma classe modelo, possui apenas os atributos referentes ao banco de dados de forma privada, com métodos para repasse e modificação destas informações. Cidade Esta Classe define a cidade ligada à classe Pos, indicado a cidade da referida posição geográfica. Por ser uma classe modelo, possui apenas os atributos referentes ao banco de dados de forma privada, com métodos para repasse e modificação destas informações. Estado Esta Classe define o estado ligado à classe Cidade, indicado o estado ao qual pertence a cidade. Por ser uma classe modelo, possui apenas os atributos referentes ao banco de dados de forma privada, com métodos para repasse e modificação destas informações. CSolo Classe que representa a classe do solo do local de extração de um fitólito de solo. Por ser uma classe modelo, possui apenas os atributos referentes ao banco de dados de forma privada, com métodos para repasse e modificação destas informações. FitoP Esta cria objetos que definem os Fitólitos que foram extraídos de plantas, com todas as suas propriedades e objetos necessário para representar suas informações completas. Por ser uma classe modelo, possui apenas os atributos referentes ao banco de dados de forma privada, com métodos para repasse e modificação destas informações. FitoS Um objeto desta classe é definido como o Fitólito que é extraído da terra, com todas as suas propriedades. Por ser uma classe modelo, possui apenas os atributos referentes ao banco de dados de forma privada, com métodos para repasse e modificação destas informações. CONSIDERAÇÕES FINAIS As informações apresentadas definem o FitoDB, Sistema de Classificação de Morfotipos de Fitólitos para referência de desenvolvimento. O sistema toma como base o banco de dados, já que se trata de uma ferramenta para classificação, e sendo assim, boa parte do desenvolvimento de interface segue com base na definição de elementos gráficos que auxiliem na manipulação desta base de dados. Apesar de aparentar possuir um escopo reduzido de desenvolvimento de sistema, ainda assim têm em sua complexidade as tecnologias de desenvolvimento, que além de serem relativamente recentes, há que levar em

35 conta a falta de experiência e o tamanho reduzido da equipe, que é formado por dois alunos. Para tanto, é visado no cronograma a ser construído a preparação e treinamento, tanto para a manipulação do SGBD, quanto para o desenvolvimento da interface web, que é a proposta do trabalho. O campo de ação do sistema é bastante amplo, e visando seu desenvolvimento para web, possibilita a toda à comunidade acadêmica a fazer uso para inúmeros fins, incluindo a tríade pesquisa, ensino e extensão. 35

36 36 REFERÊNCIAS BIBLIOGRÁFICAS [1] SENDULSKY, T.; LABOURIAU, L. G. Corpos Silicosos de Gramíneas dos Cerrados. In: Anais da Academia Brasileira de Ciências, São Paulo, v. 38, n. 1, p , [2] CALEGARI, M. R. Ocorrência e Significado Paleoambiental do Horizonte A húmico em Latossolos. Tese (Doutorado em Agronomia) Escola Superior de Agricultura Luiz Queiroz. São Paulo: Universidade de São Paulo, [3] POSTGRESQL. Documentação do PostgreSQL Manual de Referência do Sistema (Tradução). The PostgreSQL Global Development Group. Disponível na URL: Consultado em 14 de julho de [4] SILBERCHATZ, A; KORTH, H. F.; SUDARSHAN, S. Sistemas de Banco de Dados. 3 ed. Makron Books, [5] SOMMERVILLE, I. Engenharia de Software. 8ª Edição. Addison Wesley Bras, [6] BISSI, W. SCRUM - Metodologia de Desenvolvimento Ágil. Campo Digital, Campo Mourão. v.2, n.1, p.3-6, Disponível em: 12/146. Acessado em: 12/02012.

37 37 Anexo: Modelo de Dados 1. MODELO DE DADOS [4] A modelagem prévia para o banco de dados é de suma importância para o entendimento de como o Sistema Gerenciador de Banco de Dados se comportará com o tipo de normalização e o tipo de refinamento dos dados. O Sistema Gerenciador de Banco de Dados a ser utilizado é o PostgreSQL por ser de cógido aberto e bastante simples, descritos em [3] Modelagem E-R Em primeiro passo deve ser montado um modelo Entidade- Relacionamento para a visão de como os dados serão dispostos, garantindo que não haja inconsistência no banco de dados. A figura abaixo apresenta o modelo E-R normalizado Modelagem Relacional

38 38 Neste último passo na formalização do banco de dados é apresentado a especificação de cada tabela e seus respectivos atributos, apresentado figura abaixo que mostra visualmente o modelo relacional Dicionário de dados As tabelas apresentadas no modelo relacional representam a forma na qual os dados serão organizados e armazenados. Para melhorar o entendimento e organização é apresentado o dicionário de dados, onde é listado todas as tabelas e suas descrições na primeira tabela, seguido das descrições de cada tabela na segunda tabela.

39 39 Tabela: Lista de Tabelas do banco de dados. Tabelas Nome Descrição Filo Tabela com a lista dos filos armazenados Classe Tabela com a lista das classes armazenadas Ordem Tabela com a lista das ordens armazenados Familia Tabela com a lista das famílias armazenadas Genero Tabela com a lista dos gêneros armazenadas Especie Tabela com a lista das espécies armazenadas Planta Tabela que lista as plantas de onde foram extraídos os Fitólitos PlFoto Tabela que armazena as fotos referentes à planta armazenada na tabela Planta. TVege Tabela que armazena os tipos de vegetação de onde foram realizadas extrações de plantas. PPLanta Tabela que armazena as partes das plantas cujos Fitólitos foram extraídos. PPFoto Tabela que armazena as fotos referentes à parte da planta armazenada na tabela PPlanta. FitoP Tabela que lista os fitólitos armazenados que foram extraídos de uma parte de planta. FPFoto Tabela que armazena as fotos referentes aos Fitólitos armazenada da tabela FitoP. Compara Tabela que armazena a informação de que um Fitólito da tabela FitoS é equivalente a um da tabela FitoP. FitoS Tabela que lista os Fitólitos armazenados que foram extraídos de uma parte de planta. FSFoto Tabela que armazena as fotos referentes ao Fitólito armazenado na tabela FitoS. CSolo Tabela que lista as classes de solo de onde foram extraídos Fitólitos que estão armazenados na tabela FitoS. Pos Tabela que lista as posições geográficas exatas das referentes cidades de onde foram realizadas