monografia-jovani

(1)

CURSO DE CIÊNCIA DA COMPUTAÇÃO

Jovani Mattiello Alves

Odontomap - Software de gerenciamento e

análise estatística

VILA VELHA 2010

(2)

Odontomap - Software de gerenciamento e

análise estatística

Trabalho de Conclusão de Curso apresen-tado ao Centro Univertário Vila Velha como requisito parcial para a obtenção do grau de Bacharel em Ciência da Computação. Orientador: Cristiano Biancardi

VILA VELHA 2010

(3)

Odontomap - Software de gerenciamento e

análise estatística

BANCA EXAMINADORA

Prof. Msc. Cristiano Biancardi

Centro Universitário Vila Velha

Orientador

Profa. Msc. Susilea Abreu dos

San-tos Lima

Centro Universitário Vila Velha

Prof. Msc. Sandro Tonini

Centro Universitário Vila Velha

Trabalho de Conclusão de Curso

aprovado em 21/10/2010.

(4)

Assinaturas

Prof. Msc. Cristiano Biancardi

Centro Universitário Vila Velha

Orientador

Jovani Mattiello Alves

Centro Universitário Vila Velha

(5)

Agradeço primeiramente a Deus por ser fonte inesgotável de luz que ilumina e guia todos os meus passos e por me dar a oportunidade de realizar uma faculdade.

A todos os professores que conheci na UVV por terem contribuído com a minha formação acadêmica e intelectual e em especial ao meu orientador Cristiano Biancardi pela disponibilidade e direcionamento para que esse projeto fosse concretizado.

Ao Fernando Padrão, Márcio Castelo Branco e Uriel Murillo por terem contribuído com o desenvolvimento deste trabalho e a todos os meus amigos por me ajudarem na hora em que precisei.

(6)

1 Características do exDenta e do ProDent [eXSoluções LTDA 2010]

[Pro-dent 2010]. . . 23

2 Critério de Pesquisa - Manter Cliente . . . 33

3 Dados - Manter Cliente . . . 34

4 Critério de Pesquisa - Manter Animal . . . 37

5 Dados - Manter Animal . . . 38

6 Critério de Pesquisa - Manter Doença . . . 41

7 Dados - Manter Doença . . . 42

8 Critério de Pesquisa - Manter Odontograma . . . 45

9 Dados - Odontograma . . . 46

10 Padrão de fontes do sistema . . . 55

11 Dicionário de métodos - Interface Dados . . . 65

(7)

1 Modelo incremental [Fábrica acadêmica de software da UVV] . . . 16

2 Exemplo de um Odontograma para Canídeos [Lab.Odontologia Com-parada LOC - FMVZ - USP] . . . 19

3 Exemplo de um Odontograma para Felídeos[Lab.Odontologia Comparada LOC - FMVZ - USP] . . . 21

4 Exemplo de um Odontograma para roedores e lagomorfos[Lab.Odontologia Comparada LOC - FMVZ - USP] . . . 22

5 Inteface do exDental [eXSoluções 2010]. . . 24

6 Visualização do dente do paciente com lesão de furca [eXSoluções LTDA 2010]. . . 25

7 Odontograma do ProDent [Prodent 2010]. . . 25

8 Interagindo com o odontograma no ProDent [Prodent 2010]. . . 26

9 Etapas do processo de levantamento de requisitos [Fábrica acadêmica de software da UVV] . . . 27

10 Diagrama de casos de uso . . . 29

11 Diagrama de casos de uso . . . 29

12 Primeira tela de preenchimento do ondontograma . . . 47

13 Etapas do processo de análise orientada a objetos [Fábrica acadêmica de software da UVV] . . . 48

14 Diagrama de classes . . . 49

15 Diagrama de estados . . . 50

16 Diagrama de sequência novo Odontograma . . . 50

(8)

19 Diagrama de pacotes dos subsistemas de Segurança, Cadastro e

Odon-tograma . . . 55

20 Interface do manter Animal . . . 56

21 Interface do manter Odontograma . . . 56

22 Interface de Pesquisa . . . 56

23 Mapa de Navegabilidade . . . 57

24 Diagrama de classes Módulo de cadastro e Odontograma pacote DP . 58 25 Diagrama de classes Módulo de cadastro e Odontograma pacote GT e GD . . . 58

26 Diagrama de sequência novo Odontograma . . . 59

27 Diagrama de sequência novo Cliente . . . 59

28 Diagrama de componentes do módulo de Cadastro . . . 60

29 Diagrama de componentes do módulo Odontograma . . . 60

30 Diagrama de pacotes do módulo de geração de relatórios . . . 61

31 Ambiente de desenvolvimento de relatórios do Ireport . . . 62

32 diagrama de classes dos Pacotes GT e GD do módulo de geração de relatórios . . . 62

33 Diagrama de sequência gerar Relatório . . . 63

34 Diagrama de componentes do módulo de geração de relatórios . . . 63

35 Diagrama de classes utilitárias para persistência . . . 64

36 Diagrama de classes utilitárias para a camada de apresentação. . . 65

37 Representação da classe Aplicação . . . 66

38 Diagrama de implantação do sistema . . . 66

39 Diagrama de casos de uso do módulo de segurança . . . 73

40 Diagrama de classes do módulo de segurança . . . 74

(9)

43 Diagrama de sequência pesquisar Perfil . . . 75

44 Diagrama de sequência inserir usuário . . . 76

45 Diagrama de sequência excluir usuário . . . 76

46 Tela de cadastro de usuários no sistema . . . 77

47 Tela de cadastro de um novo perfil no sistema . . . 78

48 Tela de seleção de permissões das funções do sistema. . . 78

49 Tela de login do sistema. . . 79

(10)

RESUMO 1 INTRODUÇÃO 13 1.1 OBJETIVOS . . . 14 1.1.1 Objetivos gerais . . . 14 1.1.2 Objetivos específicos . . . 14 1.2 METODOLOGIA . . . 15

2 CONCEITOS E TRABALHOS RELACIONADOS 17 2.1 Trabalhos Relacionados . . . 20

3 LEVANTAMENTO DE REQUISITOS 27 3.1 Descrição do mini-mundo . . . 28

3.2 Diagrama de casos de uso . . . 28

3.3 Descrição dos Atores . . . 30

3.4 Descrição dos Casos de Uso . . . 30

3.4.1 Manter Cliente . . . 30 3.4.2 Manter Animal . . . 34 3.4.3 Manter Doença . . . 38 3.4.4 Manter Odontograma . . . 42 3.5 Protótipo . . . 46 4 ESPECIFICAÇÃO DE ANÁLISE 48

(11)

4.2 Diagrama de estados . . . 49

4.3 Diagrama de sequência . . . 50

4.3.1 Diagrama de sequência novo Odontograma . . . 50

4.3.2 Diagrama de sequência novo Cliente . . . 51

5 ESPECIFICAÇÃO DO PROJETO 52 5.1 Tecnologias utilizadas . . . 52

5.2 Arquitetura do Sistema . . . 53

5.3 Divisão em camadas . . . 54

5.4 Interface com Usuário (IU) . . . 55

5.4.1 Padrões de Interface . . . 55

5.4.2 Mapa de Navegabilidade . . . 57

5.5 Módulos de Cadastro e Odontograma . . . 57

5.5.1 Camada Domínio do problema (DP) . . . 57

5.5.2 Camadas de Gerenciamento de dados e tarefas (GD) e (GT) . . 58

5.5.3 Diagramas de sequência . . . 59

5.5.4 Diagramas de Componentes . . . 60

5.6 Módulo de geração de Relatórios . . . 61

5.6.1 Camada Domínio do problema (DP) . . . 61

5.6.2 Camadas de Gerenciamento de dados e tarefas (GD) e (GT) . . 61

5.6.3 Diagrama de Sequência . . . 63 5.6.4 Diagramas de Componentes . . . 63 5.7 Pacote Utilitários . . . 63 5.7.1 Persistência . . . 64 5.7.2 Apresentação . . . 64 5.8 Pacote Aplicação . . . 66

(12)

5.10 Casos de Teste . . . 66

5.10.1 Casos de teste - Manter Animal . . . 67

6 Módulo de Segurança 73 6.1 Diagrama de casos de uso do módulo de segurança . . . 73

6.2 Diagrama de classes do módulo de segurança . . . 73

6.3 Diagramas de sequência do módulo de segurança . . . 74

6.4 Projeto de segurança . . . 77

6.4.1 Mecanismos para controles de segurança . . . 77

6.4.2 Controle de Usuário . . . 77

6.4.3 Controle de perfil . . . 78

6.4.4 Controle de Permissão de Acesso . . . 78

6.4.5 Autenticação . . . 78

7 CONCLUSÃO E TRABALHOS FUTUROS 80

(13)

A odontologia veterinária é uma área que vem apresentando um grande crescimento desde a década de 80 devido ao crescente contato da população dos grandes centros urbanos com animais de estimação, consequentemente há uma maior preocupação com a saúde oral dos animais de estimação, visto que determinados problemas de saúde do animal como tártaro e mau hálito causam incômodos ao proprietário. A perspectiva de crescimento desta área vem atraindo os olhares de várias empresas as quais vem desenvolvendo vários tipos de produto para higiene oral dos animais, porém está área ainda é carente de softwares. Tendo em vista a grande demanda de software da odontologia veterinária, este trabalho propõe o desenvolvimento de um software inédito em parceria técnico-científica entre professores e alunos de gradu-ação dos cursos de Ciência da Computgradu-ação e Medicina Veterinária do Centro Uni-versitário Vila Velha - UVV, para automatizar o processo de criação de odontogramas digitalizados (documento no qual são armazenadas informações coletadas durante o exame físico odontológico) para animais domésticos e selvagens e gerar relatórios estatísticos dinâmicos a partir das informações coletas que auxiliaram na tomada de decisões e na identificação de tendências. Para o desenvolvimento do software será utilizado a metodologia usada na Fábrica Acadêmica de Software do curso de Ciên-cia da Computação da UVV que utiliza o modelo de ciclo de vida incremental. Com a implantação deste software ocorrerá a padronização dos dados coletados durantes os exames físicos odontológicos em animais domésticos e selvagens e, além disso, espera-se que ocorra ganho de tempo, redução de espaço e gastos com impressões dos odongramas, rapidez no acesso as informações e sejam incorporadas qualidade e eficiência no atendimento realizado no Hospital Veterinário Ricardo Alexandre Hippler. Palavras-chave: Odontologia Veterinária. Exame físico odontológico. Animais domés-ticos e selvagens. Odontograma. Relatórios e Análise Estatística.

(14)

1 INTRODUÇÃO

Uma das áreas da medicina veterinária vem experimentando grande desenvolvi-mento desde 1980 é a Odontologia Veterinária. Pesquisas vêm relacionando conti-nuamente a saúde oral com a saúde geral, tornando a Odontologia Veterinária cada vez mais importante [Gioso 1998]. O desenvolvimento socioeconômico e cultural dos grandes centros urbanos revelou uma população em contato cada vez maior com os animais de estimação os quais estão sujeitos a diversos processos mórbidos primários ou secundários incluindo os traumatismos e as afecções bacterianas e virais na cavi-dade oral [Abdalla 2008] e, conseqüentemente, a população ficou mais atenta às afecções orais, principalmente no que tange ao incômodo do proprietário em relação ao animal, como mau hálito, o aspecto "sujo"devido à presença de cálculo dental ("tártaro"), fraturas dentais visíveis e ausência de dentes. Das afecções mais co-muns, estão as que acometem o periodonto, ou seja, estruturas que suportam e pro-tegem o dente: gengiva, osso alveolar, cemento e ligamento periodontal [Gioso 2007] e [Abdalla 2008].

Tendo em vista o crescimento da Odontologia Veterinária, inúmeras empresas de porte vêm desenvolvendo produtos, como creme dental, escovas de dente es-peciais, rações específicas, biscoitos que auxiliam o combate ao cálculo dental ("tár-taro"), aparelhos ortodônticos (correção da maloclusão) e implantação de próteses para correção estética [Gioso 2003]. A perspectiva de crescimento deste mercado tem chamado a atenção de empresas, laboratórios, indústrias farmacêuticas e alimen-tícias, porém, até o presente momento, nenhuma empresa nacional investiu esforços na busca de software que auxilie na padronização das informações clínicas obtidas após o exame físico odontológico de animais domésticos e selvagens. Baseado nes-tas informações, viu-se a necessidade de criar um software que forneça uma forma padronizada, rápida e direta de catalogar as informações obtidas durante o exame odontológico veterinário e de forma automatizada gere dados estatísticos precisos das informações catalogadas. Este software será parte do projeto de pesquisa

(15)

Odon-tomap da Fábrica Acadêmica de software da UVV que será desenvolvido em parceria técnico-científica entre professores e alunos de graduação dos cursos de Ciência da Computação e Medicina Veterinária do Centro Universitário Vila Velha. Os envolvidos no projeto de pesquisa irão trabalhar de forma cooperativa para levantar, organizar, analisar, projetar e desenvolver os requisitos de forma a garantir qualidade em todo o processo de desenvolvimento. Tal sistema será implantado no Hospital Veterinário Ricardo Alexandre Hippler.

1.1 OBJETIVOS

1.1.1 Objetivos gerais

Objetiva-se aproximar as áreas de Medicina Veterinária e Ciência da Computação, desenvolvendo em parceria um programa inédito, para automatizar o processo de criação de odontogramas digitalizados (documento no qual são armazenadas infor-mações coletadas durante o exame físico odontológico) para animais domésticos e selvagens atendidos no Hospital Veterinário Ricardo Alexandre Hippler do Centro Uni-versitário Vila Velha-ES e gerar relatórios estatísticos dinâmicos a partir das infor-mações coletas que auxiliaram na tomada de decisões e na identificação de tendên-cias.

1.1.2 Objetivos específicos

O software deverá fornecer as seguintes funcionalidades:

1. Gerenciar as informações pertinentes às fichas clínicas dos pacientes.

2. Gerenciar as informações específicas de uso durante exame físico odontológico veterinário.

3. Gerar estatísticas de atendimento por espécie, tipo e distribuição das lesões no sistema estomatognático dos seguintes animais: canídeos, felídeos, eqüinos, primatas, roedores e lagomorfos.

4. Analisar as informações armazenadas referentes aos exames realizados e de-terminar a prevalência das principais enfermidades que acometem os animais.

(16)

5. Possibilitar a criação de odontogramas para diferentes espécies de maneira au-tomatizada.

6. Possibilitar ao usuário a criação dinâmica de relatórios de acordo com suas ne-cessidades.

1.2 METODOLOGIA

Com relação ao desenvolvimento do software optou-se pela utilização da metodolo-gia usada na Fábrica Acadêmica de Software do curso de Ciência da Computação da UVV que utiliza o modelo de ciclo de vida incremental (figura 1) [Bezzera 2007]. No ciclo de vida incremental inicialmente é feito uma abordagem em cascata do levanta-mento de requisitos , da análise e do projeto arquitetural. Uma vez gerado os artefatos da fase do levantamento de requisitos inicia-se a fase da análise, feito isso inicia-se a fase do projeto arquitetural no qual determina-se "como"o sistema funcionara para atender aos requisitos, levando em consideração os aspectos tecnológicos (a fase de projeto considera os aspectos físicos e dependentes de implementação) e são regis-tradas as decisões iniciais em alto-nível acerca do sistema [Bezzera 2007]. Quando o projeto arquitetural é finalizado, o desenvolvimento do software passa a ser dividido em ciclos. Em cada ciclo de desenvolvimento, realiza-se o projeto detalho, a imple-mentação e os testes. Cada um dos ciclos considera um subconjunto de requisitos. Os requisitos são desenvolvidos uma vez que sejam alocados a um ciclo de desen-volvimento. No próximo ciclo outro subconjunto dos requisitos é considerado para ser desenvolvido, o que produz um novo incremento do sistema que contém extensões e refinamentos sobre o incremento anterior. Assim, o desenvolvimento evoluirá em versões, ao longo da construção incremental até que o sistema completo esteja con-struído. Convém dizer que esta metodologia incentiva a participação do usuário nas atividades de desenvolvimento do sistema, o que diminui em muito a probabilidade de interpretações erradas em relação aos requisitos levantados.

Serão realizados exames físicos odontológicos de cães, gatos, cavalos encam-inhados para atendimento no Hospital Veterinário Prof. Ricardo Alexandre Hippler (HOVET-UVV) e em sincrânios de animais selvagens (primatas, mão-pelada, cachorro-do-mato e boto-cinza) que já fazem parte de experimentos de mestrado na mesma in-stituição. Todas as informações serão catalogadas em fichas odontológicas impressas e posteriormente serão transferidas para o software que será desenvolvido.

(17)

Figura 1: Modelo incremental [Fábrica acadêmica de software da UVV]

Vale ressaltar que as versões do software serão também testadas por um aluno de Iniciação Científica na rotina de atendimento a animais domésticos e selvagens do Hospital Ricardo Alexandre Hippler, da UVV. Os erros identificados durante o processo de teste serão documentados e posteriormente corrigidos. Além disso, sugestões de melhorias serão feitas objetivando a criação de um software com características completas.

(18)

2 CONCEITOS E TRABALHOS

RELACIONADOS

Neste capitulo será apresentado o modo como os odontogramas são criados, seus vários modelos e os trabalhos relacionados a esse assunto. Como qualquer outro exame clínico, o exame para fins odontológicos deve ser precedido por anamnese (do grego recordação neste caso anamnese é o histórico do paciente) e exame físico ao final. Na anamnese específica odontológica veterinária são avaliados os seguintes fatores [Gioso 2003]:

• tipo de alimentação.

• vícios de roer/mordiscar objetos duros. • roer ossos ou biscoitos artificais. • higienização oral.

• tratamento periodontal/dental prévio.

• halitose, disfagia e preensão de alimentos e sua deglutição. • meneios e prurido de cabeça.

• hemorragia oral e epistaxe.

• movimentos de mandíbula e língua.

A seguir, o Médico Veterinário busca observar se o animal apresenta lesões na cavi-dade oral, em tecidos moles e nos dentes, sendo os principais achados para os dentes:

• bolsa periodontal • retração gengival

(19)

• fratura dental • cálculo dental • placa • apinhamento dental • desgaste • permanência de decíduo • supranumerário • mobilidade dental • exposição de furca • gengivite • giro-versão • hiperplasia gengival

Todas estas alterações devem ser anotadas em odontogramas, sendo que o odon-tograma pode ser feito de várias formas. Por isso é conveniente haver um ferramenta rápida e cômoda, reconhecida pela maioria dos profissionais para tornar mais simples a comunicação ou escrita e a transferência de históricos clínicos [San Román 1999]. Um dos modelos de odontograma que o Hospital Veterinário Ricardo Alexandre Hip-pler utiliza está apresentada na figura 2. O odontograma ou carta dental (figura 2) utiliza um diagrama de dentição que permite o registro de informação ao lado de sua localização. Desta forma, os achados são anotados de maneira rápida, fácil e pre-cisa. É a forma mais simples em que o clínico pode ditar suas observações para seu assistente, enquanto realiza um exame dental [San Román 1999].

(20)

Figura 2: Exemplo de um Odontograma para Canídeos [Lab.Odontologia Comparada LOC - FMVZ - USP]

(21)

O odontograma (figura 2) é composto por: • Informações do paciente e do seu proprietário

• Anamnese - É um histórico do paciente que possui três campos principais como a queixa principal , histórico dental e histórico médico.

• Exame Clinico - Informa os sinais clínicos apresentados pelo paciente. Esses sinais clínicos também são ilustrados na representação da arcada dentária e na representação individual dos dentes do cão, com o propósito de agilizar a leitura dos sinais clínicos que o paciente possui.

• Dignosticos - Registra a análise clínica do veterinário, após ser identificados os sinais clínicos. Nele são documentados o parecer clinico e o tratamento re-comendado.

Existem odontogramas específicos para cada família de animal, basicamente os odontogramas se diferem na representação da arcada dentária e nas doenças que o animal pode ter. Nas figuras 3 e 4 temos, por exemplo, o odontograma dos felídeos e o odontograma dos roedores e lagomorfos.

Com as varias informações coletadas dos odontogramas são feitos cálculos es-tatísticos manualmente como percentuais e médias, os quais demandam muito esforço e possibilitam a geração de erros.

2.1 Trabalhos Relacionados

Os procedimentos dentários tem sido realizado em animais, particularmente ca-valos, desde as épocas mais remotas da história da humanidade. Na ausência de anestesia e entendimento de fisiologia ou patologia, muitos tratamentos eram, às vezes, desnecessários, inapropriados ou realizados de forma brutal. Esta área da medicina veterinária apresentou sua evolução nas últimas décadas.

Por ser uma área recente ainda não existe uma ferramenta que padroniza e facilita o gerenciamento de informações referentes ao exame físico da cavidade oral de ani-mais. Entretanto ferramentas com tais funcionalidades são encontradas para geren-ciar exame físico somente da cavidade oral de humanos, sendo os mais populares: eXDental (figuras 5 e 6) e ProDente (figuras 7 e 8).

(22)

Figura 3: Exemplo de um Odontograma para Felídeos[Lab.Odontologia Comparada LOC - FMVZ - USP]

(23)

Figura 4: Exemplo de um Odontograma para roedores e lagomorfos[Lab.Odontologia Comparada LOC - FMVZ - USP]

(24)

A tabela 1 apresenta algumas das características do exDental e do ProDent.

exDental ProDente

Cadastros Nesse módulo "Cadas-tro do Paciente"foram reunidas ferramentas de criação de anamneses, receitas, atestados, req-uisições e controle de documentação radiológica incluindo impressão dos documentos

O ProDent possibilita vários tipos de cadas-tro de cliente, dentistas, fornecedores, tratamen-tos, usuários, custos, clinicas , Anamneses e outros.

Controle financeiro O controle financeiro do eXDental cobre tudo que um profissional quer so-bre gerenciamento, como: Despesas, Receitas, Con-vênios e Beneficiários.

O ProDent possui inúmera ferramentas para a criação de orçamentos, custos de manutenção ortodôn-tica, controle bancário, documentos de cobrança. Imagens do paciente Para catalogar e

ar-mazenar imagens e radiografias dos pacientes, o eXDental disponibiliza uma ferramenta robusta, com capacidade para armazenamento em seu banco de dados de 128 Gbytes por paciente, ou seja, na prática, ilimitada.

Permite capturar, trans-ferir e imprimir até 10000 imagens por cliente, po-dendo, por exemplo, reg-istrar as varias etapas do tratamento. Além de tudo isso é possível fazer si-mulações /manipulações , como por exemplo simular troca das restaurações de amálgama por resina Odontograma Apresenta uma ferramenta

única no mercado de apre-sentar o "Odontograma 3D". Com odontograma 3D, um implante pode ser mostrado em todos os seus ângulos e em todas as suas partes, inclusive dentro de um crânio também em 3D.

Possui um desenho da dentição do cliente que pode ser facilmente ma-nipulada e personalizada , sugerindo até a dentição aproximada do cliente a partir da data de nasci-mento. Há uma enorme variedade de símbolos, basta passar o mouse para saber seus nomes. Você pode criar novos desenhos, inclusive com letras.

Tabela 1: Características do exDenta e do ProDent [eXSoluções LTDA 2010] [Prodent 2010].

(25)

Esses sistemas não podem ser usados para animais, uma vez que os animais e humanos não possuem a mesma arcada dentária e não são afetados pelas mes-mas enfermidades, mes-mas mesmo assim algumes-mas das características desses sistemes-mas podem ser incorporadas no desenvolvimento de um software que atenda os animais, como:

• Criação de anmneses do paciente.

• Gerenciamento de informações sobre o paciente.

• Permitir que o usuário represente as enfermidades do paciente graficamente.

(26)

Figura 6: Visualização do dente do paciente com lesão de furca [eXSoluções LTDA 2010].

(27)

(28)

3 LEVANTAMENTO DE

REQUISITOS

Este capitulo irá falar sobre a etapa de levantamento de requisitos das funcionali-dades do sistema.

O levantamento de requisitos consiste em investigar quais as necessidades do cliente, para assim saber quais serão as funcionalidades da solução a ser desen-volvida. Isso torna a fase de levantamento de requisitos umas das partes mais impor-tantes do processo de desenvolvimento de software. Existem varias técnicas para se levantar requisitos, as utilizadas neste projeto foram:

• Entrevista • Prototipagem • Questionário

As etapas do processo de levantamento de requisitos são apresentadas na figura 9. Nesta figura podem-se observar as atividades, a ordem de execução e os artefatos gerados. Nem todos os artefatos gerados no levantamento de requisitos serão apre-sentados.

Figura 9: Etapas do processo de levantamento de requisitos [Fábrica acadêmica de software da UVV]

(29)

3.1 Descrição do mini-mundo

O Hospital Veterinário Ricardo Alexandre Hippler do Centro Universitário Vila Velha-ES realiza tratamentos odontológicos em animais doméstico e selvagens diariamente, para se realizar esse tipo de tratamento o veterinário precisa primeiramente realizar o exame físicos odontológicos que será registrado no odontograma ou carta dental (des-crito na seção 2) que por sua vez precisa ser armazenado para se criar um histórico do paciente. Com os históricos dos pacientes são feitos cálculos estatísticos manual-mente como. Por exemplo, qual o porcentual de cachorros que tiveram tártaro. Neste contexto são identificados alguns incômodos como, por exemplo, a falta de padroniza-ção dos odontogramas, há um custo de material e espaço para se fazer a impressão do odontograma, os cálculos estáticos demandam muito tempo e esforço para serem feitos e ainda estão sujeitos a erros humanos. Desta maneira identificou-se a ne-cessidade de desenvolver um software que seja responsável pelo gerenciamento dos odontogramas e pelas gerações dos dados estatísticos. Uma vez que o software seja desenvolvido, haverá uma normatização dos exames físicos realizados em animais domésticos e selvagens, acesso mais rápido às fichas, possibilidade de levantamento estatístico rápido e confiável e diminuição no uso de fichas impressas, reduzindo es-paço e custo de impressão das mesmas.

3.2 Diagrama de casos de uso

Um caso de uso é a especificação de uma seqüência de interações entre um sistema e os agentes externos que utilizam esse sistema. Um caso de uso defini uma funcionalidade de um sistema, sem revelar a estrutura e o comportamento internos desse sistema. Um caso de uso representa quem faz o que (interage) com o sistema, sem considerar o comportamento interno do sistema [Bezzera 2007]. No diagrama de casos de usos também são representados quem aciona determinado caso de uso. Na terminologia da UML, qualquer elemento externo que interage como sistema é denominado ator. O termo "externo"significa que um ator troca (envia /ou recebe) informações com o sistema [Bezzera 2007]. A figura 10 mostra o diagrama de casos de uso do sistema odontomap.

(30)

Figura 10: Diagrama de casos de uso

(31)

3.3 Descrição dos Atores

• Administrador: Professor responsável por cadastrar novos usuários e perfis de usuários, gerar BackUp das informações do sistema e validar odontogramas além de poder usufruir de todas as funcionalidades do sistema.

• Estagiário: Aluno com permissão para inserir novos registros no sistema, no caso especifico de inserção de um novo odontograma é necessário a validação do mesmo por um veterinário.

3.4 Descrição dos Casos de Uso

A descrição do caso de uso pode descrever em uma sequência, razoavelmente completa, de passos todas as atividades que ocorrem em reação a um evento acionador ao sistema e como o mesmo reagiria ao evento [ALLAN DENNIS, BARBARA HALEY WIXON, 2005].

3.4.1 Manter Cliente

Sumário: Ator realiza a manutenção (inclusão, remoção, alteração e consulta) dos

dados sobre Clientes.

Ator Principal: Administrador ou estagiário.

Pré-Condições: Funcionário deverá estar logado no sistema. Fluxo Básico - Manter Cliente

1. Este caso de uso inicia quando o ator opta por manter um cliente; 2. O sistema apresenta uma lista em branco ao usuário;

3. O sistema habilita as opções de manutenção de cliente; ( E4 ) 4. O ator navega pela lista apresentada; ( A1 ) ( A2 ) ( A3 ) ( A4 ) ( E4 ) 5. O ator opta por encerrar o caso de uso;

(32)

Fluxos Alternativos: ( A1 ) - Incluir Cliente

1. O sistema disponibiliza os campos de dados; 2. O ator insere os dados do cliente;

3. O sistema faz a validação dos dados; ( E1 ) 4. O sistema salva os dados do cliente;

5. O sistema retorna uma mensagem de sucesso; 6. O ator confirma a mensagem;

7. O sistema inclui na lista apresentada ao usuário os dados do novo cliente cadastrado; 8. O sistema habilita as opções de alteração e exclusão de cliente;

9. O sistema retorna ao ponto de chamada; 10. Este caso de uso se encerra;

( A2 ) - Alterar Dados de Cliente

1. O sistema habilita os campos de dados editáveis; 2. O ator informa os novos dados e opta por salvar; 3. O sistema solicita a confirmação para alteração; 4. O ator confirma;

5. O sistema faz a validação dos dados. ( E1 ) 6. O sistema altera os dados do cliente;

(33)

( A3 ) - Excluir Cliente

1. O sistema solicita a confirmação da exclusão; 2. O ator confirma;

3. O sistema valida a exclusão; 4. O sistema exclui os dados;

7. O sistema exclui da lista apresentada ao usuário os dados do cliente excluido e retorna ao ponto de chamada;

8. Este caso de uso se encerra;

( A4 ) Pesquisar Cliente

1. O sistema habilita os campos de dados permutáveis; 2. O ator informa os dados e opta por iniciar pesquisa; 3. O sistema faz a validação dos dados; ( E2 )

4. O sistema apresenta uma lista com os dados dos clientes cadastrados que sa-tisfazem os critérios de pesquisa; ( E3 )

5. O sistema habilita as opções de alteração e exclusão de cliente; 6. O sistema retorna ao ponto de chamada;

Fluxos Exceções:

( E1 ) - Dados Obrigatórios

1. Casos os dados obrigatórios não sejam fornecidos, é emitida uma mensagem de erro informando;

(34)

( E2 ) - Nenhum dado fornecido

1. Casos os dados não sejam fornecidos, o sistema faz todas as permutações pos-síveis;

2. Retornar ao ponto de apresentação de dados;

( E3 ) - O Sistema não retorna os dados mediante os critérios de pesquisa informados

1. Sistema retorna uma mensagem informando que nenhum registro atendeu aos critérios de pesquisa;

2. O sistema retorna ao inicio do fluxo de chamada;

( E4 ) - Lista de clientes vazia

1. O sistema desabilita as opções de alteração e exclusão de cliente. 2. O sistema retorna ao ponto de chamada;

A tabela 2 mostra o(s) critério(s) utilizado(s) na pesquisa de Cliente(s). A tabela 3

Campo Regra / Descrição Obrigatório

Nome O sistema realiza a busca por qualquer parte do nome do cliente

N Tabela 2: Critério de Pesquisa - Manter Cliente mostra os dados referentes ao Cliente.

(35)

Campo Regra / Descrição Tipo Editáveis Obrigatório

Código O sistema gera auto-maticamente um número de identificação. Último número gerado mais um. Começa a partir de 000001.

N N S

Nome Pode ser colocado o nome de uma Instituição ou uma pessoa física. A S S Logradouro A S S Número A S N Complemento A S N Bairro A S N Cidade A S N UF A S N País A S N Telefone Contato N S S

Tabela 3: Dados - Manter Cliente

Legenda de Tipos:

Numérico: N Alfanumérico: A

3.4.2 Manter Animal

dados sobre Animais.

Pré-Condições: Funcionário deverá estar logado no sistema. Fluxo Básico - Manter Animal

1. Este caso de uso inicia quando o ator opta por manter um animal; 2. O sistema apresenta uma lista em branco ao usuário;

3. O sistema habilita as opções de manutenção de animal;

(36)

5. O ator opta por encerrar o caso de uso; 6. Este caso de uso se encerra;

Fluxos Alternativos ( A1 ) - Incluir Animal

1. O sistema disponibiliza os campos de dados; 2. O ator insere os dados do animal;

3. O sistema faz a validação dos dados; ( E1 ) 4. O sistema salva os dados do animal;

7. O sistema inclui na lista apresentada ao usuário os dados do novo animal cadastrado; 8. O sistema habilita as opções de alteração e exclusão de animal;

( A2 ) - Alterar Dados de Animal

5. O sistema faz a validação dos dados. ( E1 ) 6. O sistema altera os dados do animal;

(37)

( A3 ) - Excluir Animal

7. O sistema exclui da lista apresentada ao usuário os dados do animal excluido e retorna ao ponto de chamada;

( A4 ) Pesquisar Animal

4. O sistema apresenta uma lista com os dados dos animais cadastrados que sa-tisfazem os critérios de pesquisa; ( E3 )

5. O sistema habilita as opções de alteração e exclusão de animal 6. O sistema retorna ao ponto de chamada;

7. O sistema retorna ao ponto de chamada;

Fluxos Exceções

(38)

2. Retornar ao ponto de entrada de dados;

( E4 ) - Lista de animais vazia

1. O sistema desabilita as opções de alteração e exclusão de animal. 2. O sistema retorna ao ponto de chamada;

A tabela 4 mostra o(s) critério(s) utilizado(s) na pesquisa de Animais.

Campo Regra / Descrição Obrigatório

Nome O sistema realiza a busca por qualquer parte do nome do animal

N Tabela 4: Critério de Pesquisa - Manter Animal A tabela 5 mostra os dados referentes ao Animal.

(39)

Código O sistema gera auto-maticamente um número de identificação. Último número gerado mais um. Começa a partir de 000001. N N S Nome do animal A S S Proprietário do animal A S N Raça A S N Peso A S N Idade A S N Bairro A S N Cidade A S N UF A S N

Tabela 5: Dados - Manter Animal

3.4.3 Manter Doença

dados sobre doenças.

Ator Principal: Administrador

Pré-Condições: Administrador deverá estar logado no sistema. Fluxo Básico - Manter Doença

1. Este caso de uso inicia quando o ator opta por manter uma doença; 2. O sistema apresenta uma lista em branco ao usuário;

3. O sistema habilita as opções de manutenção de doenças;

4. O ator navega pela lista apresentada; ( A1 ) ( A2 ) ( A3 ) ( A4 ) ( E4 ) 5. O ator opta por encerrar o caso de uso;

Fluxos Alternativos ( A1 ) - Incluir doença

(40)

1. O sistema disponibiliza os campos de dados; 2. O ator insere os dados da doença;

3. O sistema faz a validação dos dados; ( E1 ) 4. O sistema salva os dados da doença;

7. O sistema inclui na lista apresentada ao usuário os dados da nova doença cadastrada;

8. O sistema habilita as opções de alteração e exclusão de doença; 9. O sistema retorna ao ponto de chamada;

( A2 ) - Alterar Dados de Doença

5. O sistema faz a validação dos dados. ( E1 ) 6. O sistema altera os dados da doença;

( A3 ) - Excluir Doença

(41)

2. O ator confirma;

7. O sistema exclui da lista apresentada ao usuário os dados da doença excluida e retorna ao ponto de chamada;

( A4 ) Pesquisar Doença

1. O sistema habilita os campos de dados permutáveis;

2. O ator informa os dados de critério de pesquisa e opta por iniciar pesquisa; 3. O sistema faz a validação dos dados; ( E2 )

4. O sistema apresenta uma lista com os dados das doenças cadastradas que sa-tisfazem os critérios de pesquisa; ( E3 )

5. O sistema habilita as opções de alteração e exclusão de doença. 6. O sistema retorna ao ponto de chamada

(42)

( E4 ) - Lista de doenças vazia

1. O sistema desabilita as opções de alteração e exclusão de doença. 2. O sistema retorna ao ponto de chamada;

A tabela 6 mostra o(s) critério(s) utilizado(s) na pesquisa de Doença(s).

Campo Regra / Descrição Obrigatório

Nome O sistema realiza a busca por qualquer parte do nome da doença

N Espécie O sistema realiza a busca pelo nome da

Espécie

N Dente O sistema realiza a busca pela

nomen-clatura do Dente

N Tabela 6: Critério de Pesquisa - Manter Doença A tabela 7 mostra os dados da Doença.

(43)

Código O sistema gera auto-maticamente um número de identificação. Último número gerado mais um. Começa a partir de 000001.

N N S

Nome A S S

Descrição A S N

Espécie O sistema fornecerá as opções numéricas rela-cionadas a cada espécie

N S s

Tabela 7: Dados - Manter Doença

3.4.4 Manter Odontograma

Sumário: Realiza o cadastro (inclusão, remoção, alteração, consulta) dos dados

dos Odontograma.

Pré-Condições: Ambos deverão estar logado no sistema. Fluxo Básico - Manter Odontograma

1. Este caso de uso inicia quando o ator opta por manter um Odontograma; 2. O sistema apresenta uma lista em branco ao usuário;

3. O sistema habilita as opções de novo e pesquisar Odontograma; ( E4 ) 4. O ator navega pela lista apresentada; ( A1 ) ( A2 ) ( A3 ) ( A4 ) ( E4 ) 5. O ator opta por encerrar o caso de uso;

Fluxos Alternativos

( A1 ) - Incluir Odontograma

1. O sistema apresenta um formulário com os campos de dados; 2. O ator insere os dados do Odontograma;

(44)

3. O sistema faz a validação dos dados; ( E1 ) 4. O sistema salva os dados do Odontograma; 5. O sistema retorna uma mensagem de sucesso; 6. O ator confirma a mensagem;

7. O sistema inclui na lista apresentada ao usuário os dados do novo Odontograma cadastrado;

8. O sistema habilita as opções de alteração e exclusão de Odontograma; 9. O sistema retorna ao ponto de chamada;

( A2 ) - Alterar Dados de Odontograma

5. O sistema faz a validação dos dados. ( E1 ) 6. O sistema altera os dados do Odontograma; 7. O sistema retorna uma mensagem de sucesso; 8. O ator confirma a mensagem;

( A3 ) - Excluir Odontograma

(45)

7. O sistema exclui da lista apresentada ao usuário os dados do Odontograma ex-cluido e retorna ao ponto de chamada;

( A4 ) Pesquisar Odontograma

4. O sistema apresenta uma lista com os dados dos Odontogramas cadastrados que satisfazem os critérios de pesquisa; ( E3 )

5. O sistema habilita as opções de alteração e exclusão de Odontograma; 6. O sistema retorna ao ponto de chamada;

(46)

( E4 ) - Lista de Odontogramas vazia

1. O sistema desabilita as opções de alteração e exclusão de Odontograma. 2. O sistema retorna ao ponto de chamada;

A tabela 8 mostra o(s) critério(s) utilizado(s) na pesquisa de Odontograma(s).

Campo Regra / Descrição Obrigatório

Nome do Cliente O sistema realiza a busca por qual-quer parte do nome

N Nome do animal O sistema realiza a busca por

qual-quer parte do nome

N Nome do veterinario O sistema realiza a busca por

qual-quer parte do nome.

N Usuario O sistema realiza a busca por

qual-quer parte do nome.

N Periodo de criação

do Odontograma

O período consiste em duas datas caso a data de fim não seja informada o sistema irá assumir que a data de fim do período é a data atual, se a data de inicio não for informada o sis-tema adotará como sendo a data do registro mais antigo.

N

Tabela 8: Critério de Pesquisa - Manter Odontograma A tabela 9 mostra os dados que compõe o odontograma

(47)

Código O sistema gera auto-maticamente um número de identificação. Último numero gerados mais 1. Começa a partir de 000001.

N N S

Nome do Cliente

Pode ser colocado o nome de uma Instituição ou uma pessoa física

A S S

Nome do animal

Poder ser um nome ou um número de identificação

A S S

Data O sistema realiza a busca por qualquer parte do nome.

N S S

Nome do Usuário

O sistema realiza a busca por qualquer parte do nome. A S S Médico Veter-inário A S S

Anamnese Grupo de informações re-ferentes ao anamnese

A S N

Exames Clínicos

Todas as Informações co-letadas a partir do exame físico odontológico

A S N

DiagnósticosTodas as informações so-bre o diagnostico

A S N

Tabela 9: Dados - Odontograma

3.5 Protótipo

Com base nos requisitos e na análise orientada a objeto foi desenvolvido um pro-tótipo funcional. A figura 12 apresenta onde serão feito os cadastros das informações referentes ao proprietário do animal, paciente, anamnese e exame clínico.

(48)

(49)

4 ESPECIFICAÇÃO DE ANÁLISE

Como base nas informações e nos artefatos gerados na etapa de levantamento de requisitos é iniciada a análise orientada a objetos a qual têm como meta identificar o melhor conjunto de objetos para descrever um sistema de software [Bezzera 2007]. Nesta etapa será gerada uma série de modelos que descrevem como o software irá trabalhar para satisfazer os requisitos identificados na fase de levantamento de requi-sitos [Roger 2002]. O funcionamento deste sistema se dá através do relacionamento e troca de mensagens entre estes objetos. As etapas da analise orientada a objetos são apresentadas na figura 13. Nesta figura podem-se observar as atividades, a or-dem de execução e os artefatos gerados. Nem todos os artefatos gerados na Análise orientada a objetos serão apresentados.

Figura 13: Etapas do processo de análise orientada a objetos [Fábrica acadêmica de software da UVV]

4.1 Diagrama de classes

O diagrama de classes mostra o aspecto estrutural estático de uma cooperação para assim poder compreender como o sistema está estruturado internamente. Esse aspecto é dito estático porque não apresenta informações sobre como os objetos do

(50)

sistema interagem no decorrer do tempo.Também é dito estrutural porque a estrutura das classes de objetos e as relações entre elas são representadas [Bezzera 2007]. A figura 14 mostra o diagrama de classes do sistema odontomap.

Figura 14: Diagrama de classes

4.2 Diagrama de estados

O diagrama de estado mostra aspectos dinâmicos de uma determinada ação que o software venha desempenhar. Cada objeto participante do software se encontra em um estado particular. Quando um objeto muda de um estado para outro, diz-se que ele realizou um transação entre estados. Os estados e as transações entre es-tados constituem um ciclo de vida [Bezzera 2007]. O diagrama de eses-tados apresenta os estados e as transações possíveis que um determinado objeto do sistema venha ter. A figura 15 mostra o diagrama de estados para a classe que contém os estados possíveis de um odontograma.

(51)

Figura 15: Diagrama de estados

4.3 Diagrama de sequência

O diagrama de sequência mostra aspectos dinâmicos de uma determinada ação que o software venha desempenhar. O objetivo do diagrama de sequência é apre-sentar as interações entre os objetos na ordem temporal em que elas acontecem [Bezzera 2007].

4.3.1 Diagrama de sequência novo Odontograma

(52)

4.3.2 Diagrama de sequência novo Cliente

(53)

5 ESPECIFICAÇÃO DO PROJETO

Neste capítulo será apresentado o projeto do sistema. Na fase de projeto, determina-se "como"o sistema funcionará para atender aos requisitos, de acordo com os re-cursos tecnológicos existentes e considerando os aspectos físicos e dependentes de implementação. Aos modelos da fase de análise são adicionadas as denominadas "restrições tecnológicas".

5.1 Tecnologias utilizadas

Tecnologias usadas para o desenvolvimento deste sistema.

• Plataforma de desenvolvimento Java SE 6 - Java é Orientado a objetos, portável Independência de plataforma, "escreva uma vez, execute em qualquer lugar", possui facilidades para criação de programas distribuídos e multitarefa, desaloca memória automáticamente pelo processo do coletor de lixo, a tecnologia Java permite criar aplicações altamente escaláveis e Java é FREE;

• Ambiente de desenvolvimento NetBeans IDE 6.9.1 - É um editor de código fonte integrado, rico em recursos para aplicações Web (Servlets e JSP, JSTL, EJBs) e aplicações visuais com Swing que é uma API (Interface de Programação de Aplicativos) Java para interfaces gráficas, possui auto completar avançado e permite a geração automática de arquivos javadoc em HTML a partir dos mentários inseridos no código, além de recursos que facilitam a inclusão de co-mentários no código;

• Sistema de Gerenciamento de Banco de Dados: MySQL Server 5.1 - O MySQL possui as seguintes característica: compatibilidade (existem drivers ODBC, JDBC e .NET e módulos de interface para diversas linguagens de programação, como

(54)

Delphi, Java, C/C++, Visual Basic, Python, Perl, PHP, ASP e Ruby), excelente desempenho e estabilidade, pouco exigente quanto a recursos de hardware; • Framework de persistência de dados Hibernate 3.2.5 - é um framework para

ma-peamento objeto-relacional. O mama-peamento objeto-relacional consiste basica-mente em transformar objetos em registros e salvá-los em um banco de dados, alem de transformar os registros em objetos ao recuperá-los de um banco de dados. O principal objetivo da sua utilização será a abstração dos detalhes de persistência de dados, a maior independência do SGBD, a extinção de SQL em classes Java e a facilidade de uso, pelo fato de não ser necessário pensar em tabelas e sim em objetos e seus relacionamentos, reduzindo assim o esforço de desenvolvimento e manutenção;

• Jasper Report 3.7.6 - é uma ferramenta open source para o desenvolvimento de relatórios com conteúdos dinâmicos;

• IReport 3.7.4 - é um ambiente para a criação de relatórios com o Jasper Report;

5.2 Arquitetura do Sistema

O sistema será composto de seis pacotes, quatro deles referentes aos módulos de Segurança, Cadastro, geração de relatórios e Odontograma. A decomposição em pacotes ocorreu de acordo com o acoplamento existente entre as classes. Buscando a máxima coesão entre as classes pertencentes a um mesmo pacote e o mínimo acoplamento com outros pacotes. Com esta decomposição, cada pacote poderá ser desenvolvido quase que de uma maneira independente [Bezzera 2007]. A organiza-ção de classes em pacotes é útil também para permitir a produorganiza-ção de componentes para reuso. Neste trabalho, foram utilizadas duas formas complementares de agrupa-mento de classes em pacotes: primeiramente pelo domínio do problema, aproveitando os subsistemas definidos na fase de análise, e depois por estereótipos, tendo sido uti-lizados os estereótipos propostos por Coad e Yourdon [Coad 1993]. A figura 18 mostra o diagrama de pacotes do sistema.

(55)

Figura 18: Diagrama de pacotes do sistema

5.3 Divisão em camadas

Os pacotes Odontograma, Cadastro, Relatório e Segurança foram decompostos em outros pacotes segundo os estereótipos, dando origem a um novo diagrama de pacote figura 19 , sendo que o pacote relatório possui algumas diferenças em relação aos demais pacotes essas diferenças serão abordadas na seção 5.6, o diagrama da figura 19 é composto pelos seguintes pacotes:

• Componente Domínio do Problema (DP): Tem por função agrupar as classes que modelam os objetos do mundo real no mundo computacional.

• Componente Gerência de Dados (GD): Possui acesso aos repositórios de dados, fazendo o encapsulamento dos mecanismos de persistência, procurando assim isolar os impactos da tecnologia de gerenciamento de dados sobre a arquitetura de software.

• Componente Gerência de Tarefas (GT): Tem como objetivo agrupar as classes que executam os casos de uso descrito na fase de especificação de requisitos, ou seja, as funcionalidades do sistema.

• Componente Interface com Usuário (IU): É composta por classes que realizam a interface do sistema com o usuário, como formulários, janelas e caixas de diálogo.

• Pacote Utilitário: Trata-se de classes reutilizáveis que auxiliam principalmente na comunicação da interface com o modelo e também na conexão com o banco de dados.

(56)

Figura 19: Diagrama de pacotes dos subsistemas de Segurança, Cadastro e Odon-tograma

5.4 Interface com Usuário (IU)

Um dos principais aspectos importantes no desenvolvimento de um software é a qualidade da interface gráfica do sistema, visto que está é a parte visível do software. Este ponto é crítico para o sistema e pode determinar o sucesso ou fracasso do pro-duto de software.

5.4.1 Padrões de Interface

Visando a qualidade da interface gráfica do sistema foi estabelecido padrões de cores, fontes e tamanhos das interfaces. As interfaces seguem o padrão das telas apresentadas nas figuras 20, 21 e 22. A tabela 10 mostra o padrão de fonte utilizado. As interfaces de manter quando seus formulários de cadastro tiverem poucos compos de preechimento deverão seguir o mesmo formato de interface da figura 20, ou seja, o formulário de cadastro é integrado a tela do manter e quando tiverem muitos campos deverão seguir o formato apresentado na figura 21 , onde o formulário de cadastro é exibido em uma nova janela.

Cor da Fonte Fonte Tamanho Plano de Fundo Alinhamento do Texto JLabel Preto Tahoma 11 ou 14 RGB [240,240,240] Leading JButton Preto Tahoma 11 RGB [240,240,240] Trailing JTable Preto Tahoma 11 RGB [255,255,255] Left JCombobox Preto Tahoma 11 RGB [255,255,255] Left JTextField Preto Tahoma 11 RGB [255,255,255] Left JList Preto Tahoma 11 RGB [255,255,255] Left

(57)

Figura 20: Interface do manter Animal

Figura 21: Interface do manter Odontograma

(58)

5.4.2 Mapa de Navegabilidade

No diagrama de navegabilidade é definido a estrutura de navegação propriamente dita. A figura 23 apresenta o diagrama de navegabilidade do sistema.

Figura 23: Mapa de Navegabilidade

5.5 Módulos de Cadastro e Odontograma

Esses módulos são responsáveis por realizar a inserção e gerenciamento dos da-dos referentes aos clientes, animais, enfermidades e odontogramas. Devido a forte dependência entre o módulo de cadastro e o módulo odotograma eles serão tados juntos a fim de facilitar o entendimento dos mesmos. A seguir serão apresen-tadas algumas das camadas que constituem esses módulos.

5.5.1 Camada Domínio do problema (DP)

O diagrama de classes na fase de projeto assim como na fase de analise tem o objetivo de mostra o aspecto estrutural estático de uma cooperação entre as classes do sistema, contudo no diagrama de classes da fase de projeto são adicionados novos elementos que não são considerados no modelo da análise e que são necessários para a construção do modelo do projeto, esse elementos permitem adicionar mais rigor ao diagrama de classe do sistema. Como por exemplo podemos definir o tipo de cada atributo, a assinatura de cada operação, a navegabilidade de cada associação

(59)

[Bezzera 2007]. A figura 24 apresenta o diagrama de classe contendo as classes da camada DP.

Figura 24: Diagrama de classes Módulo de cadastro e Odontograma pacote DP

5.5.2 Camadas de Gerenciamento de dados e tarefas (GD) e (GT)

A figura 25 mostra o diagrama de classes referentes aos pacotes GD e GT dos módulos de cadastro e odontograma.

(60)

5.5.3 Diagramas de sequência

Assim como na fase de análise o diagrama de sequência da fase de projeto tem o objetivo de apresentar as interações entre os objetos na ordem temporal em que elas acontecem, levando em consideração vários novos aspectos como a divisão em camadas do sistema, o papel que cada classe desempenha e os tipos de mensagem que são trocadas.

As figuras 26 e 27 apresentam os diagramas de sequência para a inserção de um novo odontograma e um novo cliente.

Figura 26: Diagrama de sequência novo Odontograma

(61)

5.5.4 Diagramas de Componentes

O objetivo principal do diagrama de componentes é mostrar as relações estrutu-rais entre os componentes de um sistema. Componentes são unidades encapsuladas dentro de um sistema ou subsistema que fornece um ou mais interfaces de comuni-cação. Muitos componentes são considerados autônomos.

As figuras 28 e 29 apresentam os diagramas de componentes dos módulos de Cadastro e Odontograma.

Figura 28: Diagrama de componentes do módulo de Cadastro

(62)

5.6 Módulo de geração de Relatórios

Este módulo é responsável pela geração dos relatórios do sistema. A figura 30 apresenta o diagrama de pacotes deste módulo, que se diferencia do diagrama de pacote dos demais módulos pelo fato dos pacotes DP e UI não serem dependentes do pacote Utilitários.

Figura 30: Diagrama de pacotes do módulo de geração de relatórios

5.6.1 Camada Domínio do problema (DP)

O pacote DP neste caso especifico não contém classes e sim as definições dos relatórios, essa definições são arquivos jrxml os quais contém as características dos relatórios, formato, tamanho e cores, esses arquivos são construídos com a ferra-menta IReport [IReport 2010]. Uma vez que o arquivo jrxml esteja pronto o mesmo é compilado, gerando o arquivo jasper o qual é utilizado para a geração do relatório.

A figura 31 mostra o jrxml no ambiente do Ireport.

5.6.2 Camadas de Gerenciamento de dados e tarefas (GD) e (GT)

O pacote GD do módulo de geração de relatórios se difere um pouco do pacote GD dos demais módulos, neste caso as classes do pacote GD são encarregadas de gerar o relatório por meio do arquivo jasper e das informações do banco de dados. As classes do pacote GD tem acesso ao banco de dados através da Classe Conexao como mostra a figura 32. A figura 32 mostra o diagrama de classes dos Pacotes GT e GD do módulo de geração de relatórios.

(63)

Figura 31: Ambiente de desenvolvimento de relatórios do Ireport

Figura 32: diagrama de classes dos Pacotes GT e GD do módulo de geração de relatórios

(64)

5.6.3 Diagrama de Sequência

E a figura 33 apresenta o diagrama de sequência para a geração de relatórios.

Figura 33: Diagrama de sequência gerar Relatório

5.6.4 Diagramas de Componentes

A figura 34 apresenta o diagrama de componentes do módulo de geração de re-latórios.

Figura 34: Diagrama de componentes do módulo de geração de relatórios

5.7 Pacote Utilitários

Este pacote contém classes reutilizáveis para as camadas de persistência e apre-sentação, contudo somente as classes com maior relevância serão abordadas.

(65)

5.7.1 Persistência

Todos os outros módulos para conseguirem fazer a utilização do framework de persistência Hibernate [Hibernate 2010] herdam da classe Sombra apresentada no diagrama de classe da figura 35. A classe HibernateUtil possui o método getSession-Factory que fornece a classe sombra a conexão com o banco de dados e os serviços de persistência do hibernate.

Figura 35: Diagrama de classes utilitárias para persistência

5.7.2 Apresentação

Todas as classes do modelo implementam a interface Dados, isso possibilita que a interface gráfica através da classe TableManage trabalhe da mesma forma, indepen-dentemente da classe do modelo, agilizando assim o processo de desenvolvimento das interfaces gráficas. A classe TableManage tem a função de carregar uma lista de objetos do domínio do problema e apresenta-los na forma de um tabela e fazer o processo inverso, ou seja, transformar os dados apresentados na TableManage em objetos do domínio do problema novamente.

A figura 36 apresenta o diagrama de classe dos utilitários para a camada de apre-sentação

A tabela 11 apresenta o dicionário de métodos da interface Dados.

(66)

Figura 36: Diagrama de classes utilitárias para a camada de apresentação.

Interface Dados

Método Descrição Retorno

toArray Esse método transforma os atributos da classe em um vetor de objetos.

Object[ ] setAttribute Tem como função atualizar os atributos

da classe com o vetor de Object passado como parâmetro.

Void

tableAttribute Retorna um vetor de objects contendo so-mente os atributos que serão apresentados na JTable da interface gráfica.

Object[ ]

getClassId Retorno o id da classe. Long

Tabela 11: Dicionário de métodos - Interface Dados

TableManage

Método Descrição Retorno

mountTable Recebe um List do tipo Da-dos e através do método tableAttribute a JTable é construída.

Void

getSelectedtEntity Retorna a entidade sele-cionada.

Dados getSelectedFullObject Retorna um vetor de

ob-jects contendo somente os atributos que serão apre-sentados na JTable da in-terface gráfica.

Object[ ]

(67)

5.8 Pacote Aplicação

Este pacote será dividido em duas partes, são elas:

• Pacote UI que contém a interface principal do sistema a qual irá chamar as inter-faces gráficas dos outros módulos.

• Pacote GT contém a classe Aplicação representada na figura 37, que fornece um ponto de acesso centralizado para o tratamento das requisições.

Figura 37: Representação da classe Aplicação

5.9 Diagrama de Implantação

O diagrama de implantação mostra a configuração dos nós de processamento em tempo de execução e os componentes neles existentes. Abrangem a visão estática de implementação de uma arquitetura [BOOCH, 2005]. Este diagrama enfoca a questão da organização da arquitetura física sobre a qual o software irá ser implantado e exe-cutado.

A figura 38 mostra o diagrama de implantação do sistema no qual o sistema realiza acesso local ao banco de dados.

Figura 38: Diagrama de implantação do sistema

5.10 Casos de Teste

Caso de teste é um conjunto específico de entradas de teste, condições de exe-cução e resultados esperados, identificados com a finalidade de avaliar um

(68)

determi-nado aspecto de uma funcionalidade. A finalidade do Caso de Teste é identificar e comunicar formalmente as condições específicas e detalhadas que serão validadas para permitir a avaliação de determinados aspectos da funcionalidade testada. Os Casos de Teste podem ser motivados por vários fatores e normalmente incluem um subconjunto dos Requisitos (Casos de Uso, características de desempenho etc.) e dos riscos envolvidos no projeto. A seguir serão apresentados exemplos de casos de teste do manter animal que vão ser aplicados quando o desenvolvimento deste caso de uso estiver totalmente finalizado.

5.10.1 Casos de teste - Manter Animal

[CT001] - INCLUIR ANIMAL

Sumário: Ator realiza a inclusão dos dados de um animal. Ator Principal: Administrador ou estagiário.

Pré-Condições: Funcionário deverá estar logado no sistema. Risco: baixo

Prioridade: baixa

FB - Fluxo Básico - Manter Animal

1. Este caso de uso inicia quando o ator opta por manter um animal; 2. O sistema apresenta uma lista em branco ao usuário

3. O sistema habilita as opções de manutenção de animal; 4. O ator navega pela lista apresentada(FA1);

FA1 - Fluxo Alternativo 1 - Incluir Animal

1. O sistema disponibiliza os campos de dados; 2. O ator insere os dados do animal;

(69)

3. O sistema faz a validação dos dados; ( FE1 ) 4. O sistema salva os dados do animal;

7. O sistema inclui na lista apresentada ao usuário os dados do novo animal cadastrado; 8. O sistema habilita as opções de alteração e exclusão de animal;

FE1 - Fluxo de Exceção 1 - Dados Obrigatórios

[CT002] - ALTERAR DADOS DE ANIMAL

Sumário: Ator realiza a alteração dos dados de um animal. Ator Principal: Administrador ou estagiário.

FB - Fluxo Básico - Manter Animal

3. O sistema habilita as opções de manutenção de animal; 4. O ator navega pela lista apresentada(FA2);

(70)

FA 2 - Fluxo Alternativo 2 - Alterar Dados de Animal

5. O sistema faz a validação dos dados. ( FE1 ) 6. O sistema altera os dados do animal;

FE1 - Fluxo de Exceção 1 - Dados Obrigatórios

[CT003] - EXCLUIR ANIMAL

Sumário: Ator realiza a exclusão dos dados de um animal Ator Principal: Administrador ou estagiário.

(71)

3. O sistema habilita as opções de manutenção de animal; 4. O ator navega pela lista apresentada; (FA3)

FA3 - Fluxo Alternativo 3 - Excluir Animal

7. O sistema exclui da lista apresentada ao usuário os dados do animal excluído e retorna ao ponto de chamada;(FE4)

FE4 - Fluxo de Exceção 4 - Lista de animais vazia

1. O sistema desabilita as opções de alteração e exclusão de animal. 2. O sistema retorna ao ponto de chamada;