TCCMARCOANTONIO

(1)

MARCO ANTÔNIO BARBOSA DE OLIVEIRA SEGUNDO

SISTEMA DE APOIO AO DIAGNÓSTICO CLÍNICO DE ANIMAIS

VILA VELHA 2010

(2)

CENTRO UNIVERSITÁRIO VILA VELHA CURSO DE SISTEMAS DE INFORMAÇÃO

SISTEMA DE APOIO AO DIAGNÓSTICO CLÍNICO DE ANIMAIS

Monografia do Trabalho de Conclusão de Curso de Graduação em Sistemas de Informação apresentada ao Centro Universitário Vila Velha, como requisito parcial para a obtenção do título de Bacharelado em Sistemas de Informação ao Centro Universitário Vila Velha.

Orientador: Prof. MSc. Cristiano Biancardi.

VILA VELHA 2010

(3)

SISTEMA DE APOIO AO DIAGNÓSTICO CLÍNICO DE ANIMAIS

Trabalho de Conclusão de Curso apresentado ao curso de Sistemas de Informação do Centro Universitário Vila Velha - UVV, como requisito parcial para a obtenção do título de Bacharel em Sistemas de Informação.

Aprovado em ____ de _________________ de 2010.

COMISSÃO EXAMINADORA

__________________________________________ Prof. Msc. Cristiano Biancardi

Centro Universitário Vila Velha Orientador

__________________________________________ Prof. Msc. Sandro Tonini da Silva

Centro Universitário Vila Velha

__________________________________________ Profª. Msc. Susiléia Abreu dos Santos Lima Centro Universitário Vila Velha

(4)

AGRADECIMENTOS

Agradeço em primeiro lugar a Deus, pois nele imponho a minha fé me tornando cada vez mais forte para as árduas batalhas da vida.

Em especial agradeço ao meu pai (Marco Antônio Barbosa de Oliveira) por ter me guiado e me ensinado a viver sempre com motivação e dedicação e a vencer todas as batalhas e dificuldades que me foram impostas.

Agradeço a minha mãe (Ana Barbosa Aguiar), por sua imensurável ternura e amor. Ao orientador Cristiano Biancardi pela paciência e disponibilidade de ter me ajudado sempre que precisei, contribuindo com a minha formação acadêmica e intelectual. E por último aos meus amigos (Átila, Arthur, Raphael, Leandro, Jovani e Rodrigo), dentre outros vários também aos meus familiares que viveram junto comigo momentos que se tornarão inesquecíveis na minha memória por toda minha vida.

(5)

RESUMO

Uma parte de suma importância na medicina veterinária é a elaboração de diagnósticos. A rapidez de um diagnóstico pode ser fundamental para a recuperação do paciente.

Este trabalho propõe o desenvolvimento de um módulo para suporte ao médico veterinário ao diagnóstico de espécies doentes utilizando como base o software de extrapolação alométrica, que faz parte do projeto de pesquisa “Alometria” que faz parte do projeto do curso de graduação em Ciência da Computação intitulado “Fábrica de Software”.

Tem como principal objetivo agilizar o diagnóstico e reduzir a possibilidade de erros na escolha de tratamento para a espécie doente. O veterinário poderá visualizar as diversas possibilidades de tratamento através do cruzamento dos dados de doenças e do conjunto de sinais apresentados pelo paciente.

O veterinário terá uma base de dados que o auxiliará na indicação do tratamento adequado para pacientes em diversas doenças, aumentando também a precisão do diagnóstico. Este sistema poderá ser muito útil nos casos em que médico desconhece a doença do animal, permitindo um diagnóstico mais rápido.

Para isso, todos os requisitos foram levantados, diagramados e especificados em casos de uso. Realizadas as etapas anteriores, partiu-se para a parte de análise e projeto de sistema e, posteriormente, construção do software. As ferramentas utilizadas foram: plataforma JAVA, JUDE e o MySQL (banco de dados).

(6)

LISTA DE FIGURAS

Figura 1 – Modelo cascata...18

Figura 2 – Diagrama de pacote alométrico ...22

Figura 3 – Diagrama de caso de uso alométrico ...23

Figura 4 – Diagrama de Pacote ...23

Figura 5 – Diagrama de caso de uso completo ...25

Figura 6 – Diagrama de Classes ...39

Figura 7 - Diagrama de seqüência Avaliar ...42

Figura 8 - Diagrama de seqüência Diagnosticar...43

Figura 9 - Diagrama de seqüência nova doença ...44

Figura 10 - Diagrama de seqüência alterar doença...45

Figura 11 - Diagrama de seqüência consultar doença...46

Figura 12 - Diagrama de seqüência excluir doença ...47

Figura 13 - Diagrama de seqüência novo tratamento ...48

Figura 14 - Diagrama de seqüência alterar tratamento ...49

Figura 15 - Diagrama de seqüência consultar tratamento...50

Figura 16 - Diagrama de seqüência excluir tratamento ...51

Figura 17 - Diagrama de seqüência novo sinal clinico ...52

Figura 18 - Diagrama de seqüência alterar sinal clinico ...53

Figura 19 - Diagrama de seqüência excluir tratamento ...54

Figura 20 - Diagrama de seqüência excluir sinal clinico ...55

Figura 21 – Visão geral do sistema, dividido em pacotes ...65

Figura 22 – Diagrama de Pacotes do Pacote Diagnóstico...67

Figura 23 – Diagrama de Classe do DP ...68

Figura 24 – Diagrama de Classe da GT ...69

Figura 25 – Diagrama de Classe do DAO ...70

Figura 26 – Diagrama de Classe da UI...71

Figura 27 – Diagrama de Navegabilidade...71

Figura 28 – Padronização das Interfaces (Seleção) ...72

Figura 29 – Padronização das Interfaces (Consultas) ...72

Figura 30 – Diagrama Relacional ...73

Figura 31 – Diagrama de Seqüência avaliação de projeto...74

Figura 32 – Diagrama de Seqüência Diagnóstico de projeto ...75

Figura 33 – Diagrama de Seqüência novo tratamento de projeto...76

(7)

(8)

LISTA DE TABELAS

Tabela 1 – Principais causas de erro no estabelecimento do diagnóstico ...11

Tabela 2 – Problemas, Causas e Soluções. ...21

Tabela 3 – Fonte de Informações X Levantamento de requisitos ...22

Tabela 4 – Dicionário de dados...40

Tabela 5 – Tipo de dado...57

Tabela 6 – Tipo de função...58

Tabela 7 – Equipe ...59

(9)

LISTA DE ABREVIATURAS E SIGLAS

AIE – Arquivo de Interface Externa ALI – Arquivo Lógico Interno

APF – Análise de Ponto de Função DAO – Data Access Objects

DCU – Diagrama de Caso de Uso DP – Domínio do Problema

GD – Gerência de Dados GT – Gerência de Tarefas IU – Interface com o Usuário

MVC – Model – View – Controller (Modelo – Visão – Controlador) OO – Orientado (a) a Objetos

(10)

SUMÁRIO

1 INTRODUÇÃO ...11 1.1 JUSTIFICATIVA ...13 1.2 OBJETIVOS ...13 1.2.1 Objetivo geral ...13 1.2.2 Objetivos específicos...14 1.3 METODOLOGIA DE TRABALHO...14

1.4 DESCRIÇÃODOSCAPÍTULOS ...14

2 CONCEITOS...16

2.1 ALOMETRIA ...16

2.2 SEMIOLOGIA ...16

2.3 PROCESSODEDESENVOLVIMENTODESOFTWARE...17

2.3.1 Modelo ciclo de vida cascata...17

2.4 PROGRAMAÇÃO OO (ORIENTADA A OBJETOS)...18

2.5 LINGUAGEMDEMODELAGEMUNIFICADA...19

3 LEVANTAMENTO DE REQUISITOS ...20

3.1 DESCRIÇÃO DO AMBIENTE ...20

3.2 ANÁLISEDEPROBLEMAS,CAUSASEPOSSÍVEISSOLUÇÕES. ...20

3.3 FONTE DE INFORMAÇÕES X LEVANTAMENTO DE DADOS ...21

3.4 DIAGRAMAS DE CASOS DE USO ...24

3.5 DESCRIÇÃO DO ATOR...26

3.5.1 Veterinário ...26

3.6 DESCRIÇÃO DOS CASOS DE USO...26

3.6.1 Identificar Paciente ...26

3.6.2 Diagnosticar ...27

3.6.3 Avaliar ...28

3.6.4 Manter Sinal Clínico ...30

3.6.5 Manter Doença ...32 3.6.6 Manter Tratamento ...35 4 ESPECIFICAÇÃO DE ANÁLISE ...38 4.1 MODELO DE CLASSES ...38 4.1.1 Diagrama de Classes ...39 4.2 DICIONÁRIO DE DADOS ...40 4.3 DIAGRAMA DE INTERAÇÃO...41 4.3.1 Diagrama de Seqüência ...41 4.3.1.1 Avaliar ...41 4.3.1.2 Diagnosticar ...42 4.3.1.3 Nova Doença...44 4.3.1.4 Alterar Doença ...45 4.3.1.5 Consultar Doença...46 4.3.1.6 Excluir Doença ...47 4.3.1.7 Novo Tratamento...48 4.3.1.8 Alterar Tratamento ...49 4.3.1.9 Consultar Tratamento...50 4.3.1.10 Excluir Tratamento ...51

(11)

4.3.1.11 Novo sinal clínico ...52

4.3.1.12 Alterar sinal clínico ...53

4.3.1.13 Consultar sinal clínico ...54

4.3.1.14 Excluir sinal clínico ...55

5 PROPOSTA DE SOLUÇÕES TECNOLÓGICAS ...56

5.1 ANÁLISEDEPONTODEFUNÇÃO(APF) ...56

5.1.1 Funções do tipo dados ...56

5.1.2 Funções do tipo transação ...57

5.2 CUSTO DO SISTEMA...58 5.2.1 Proposta Escolhida...63 6 ESPECIFICAÇÃO DE PROJETO...64 6.1 ESCOLHA DA TECNOLOGIA ...64 6.2 ARQUITETURADOSISTEMA...64 6.2.1 Diagrama de Pacotes ...64 6.3 DIVISÃO EM CAMADAS...65

6.3.1 Componente Domínio do problema (DP) ...67

6.3.2 Componente gerencia de tarefas (GT) ...69

6.3.3 Componente de Gerenciamento de Dados (GD) ...70

6.3.4 Componente de Interface com usuário (IU)...70

6.3.5 Diagrama de Navegabilidade...71

6.3.6 Padrões de Interface ...72

6.4 DIAGRAMA RELACIONAL ...73

6.5 REVISÃODODIAGRAMADESEQUÊNCIA ...73

6.5.1 Avaliação...74 6.5.2 Diagnóstico...75 6.5.3 Novo tratamento ...76 6.6 DIAGRAMA DE COMPONENTES ...77 6.7 DIAGRAMA DE IMPLANTAÇÃO...77 7 PROJETO SEGURANÇA ...78 7.1 AMEAÇAS ...79 7.2 CONTROLE DE SEGURANÇA. ...79

7.2.1 Descrição dos Controles ...79

8 CONCLUSÃO ...81

9 REFERÊNCIAS BIBLIOGRÁFICAS...82

ANEXO A – MANUAL DE USUÁRIO ...83

1.1. DIAGNÓSTICO...85

(12)

1 INTRODUÇÃO

Na Medicina Veterinária, uma parte de suma importância é a elaboração de diagnósticos, ou seja, reconhecer uma dada enfermidade por meio de suas manifestações. Este reconhecimento é realizado pelo clínico com base nos dados obtidos na anamnese (história do animal), no exame físico e/ou exames complementares. [10]

Em muitas ocasiões, nem sempre é possível estabelecer de imediato, o diagnóstico exato da enfermidade (diagnóstico provável, provisório ou presuntivo). Vários fatores podem interferir na elaboração de um diagnóstico preciso e rápido. Segundo Feitosa [10], estes fatores são os mostrados na tabela 1.

Etapa Principais Causas de Erros

Anamnese Incompleta ou preenchida erroneamente.

Exame físico Superficial ou feito às pressas.

Avaliação Precipitada ou falsa dos achados clínicos Exames Físicos Disponíveis Conhecimento ou domínio insuficiente Diagnóstico Impulso precipitado em tratar os pacientes

antes mesmo de estabelecer o diagnóstico. Tabela 1 – Principais causas de erro no estabelecimento do diagnóstico

Como se pode perceber pela tabela acima, a avaliação dos dados clínicos é uma tarefa difícil, sendo a maior responsável pelo erro de diagnóstico. Desta forma, visando auxiliar o veterinário, surgiu a proposta do desenvolvimento de um sistema de diagnóstico clínico animal.

No Centro Universitário de Vila Velha, através do projeto do curso de graduação em Ciência da Computação intitulado “Fábrica de Software”, vêm sido desenvolvido vários projetos em parceria com outros cursos, dentre eles o projeto “Alometria”. Este projeto, em parceria com os cursos de graduação em Sistema de Informação e o curso de mestrado em Medicina Veterinária, consiste em um software para extrapolação alométrica na posologia e cálculo de exigências energéticas para animais selvagens e serviu de base para o trabalho de conclusão

(13)

de curso (TCC) de Rodrigo Pim Silva, que desenvolveu uma proposta utilizando tecnologia móvel.

A extrapolação alométrica interespecífica é um método que permite, através das doses de medicamentos indicadas para uma espécie de vertebrado (animal modelo), extrapolar matematicamente para outro vertebrado diferente (animal alvo), através do conhecimento das taxas metabólicas de ambos.

A proposta deste projeto é aumentar ainda mais a funcionalidade deste software, por meio do acoplamento de um novo módulo abrangendo a parte de diagnóstico.

Deseja-se assim que os usuários possam selecionar, dentre as opções de sinais clínicos fornecidas pelo sistema, àquelas apresentadas pelo paciente, e depois optar por visualizar as diversas possibilidades de doenças sugeridas pelo sistema, ao optar pela opção diagnóstico, e/ou as diversas possibilidades de tratamento, ao optar pela opção tratamento, para aquele conjunto de sinais. De posse dessas possibilidades, o diagnóstico e tratamento podem ser mais precisos e ágeis.

As doenças exibidas para uma coleção de sinais clínicos são exibidas por ordem de relevância (da doença de maior relevância – com maior número de sinais clínicos abrangidos - até a de menor relevância). Além disso, para cada doença retornada para aquele grupo de sinais clínicos selecionados é possível também visualizar o tratamento sugerido pelo sistema.

Vale lembrar que este sistema servirá apenas como apoio para estabelecimento de um diagnóstico e tratamento, não fornecendo um diagnóstico e um tratamento definitivos. Também é importante observar que o sistema vai acumulando dados cadastrados pelos veterinários, como por exemplo, doenças e sinais clínicos, tornando-se cada vez mais confiável.

(14)

1.1 JUSTIFICATIVA

Em muitos casos, a rapidez de um diagnóstico pode ser fundamental para a recuperação do paciente. Mas não basta o diagnóstico ser rápido, é importante que ele seja preciso.

Vários fatores fazem com que precisão e rapidez no estabelecimento de um diagnóstico nem sempre andem juntos. Assim, desenvolver um sistema que auxilie o médico veterinário nesta tarefa é importante, pois além de ajudar a diminuir o tempo gasto no diagnóstico, irá auxiliá-lo nos possíveis tratamentos e medicamentos para a espécie doente, assim como reduzir a possibilidade de erro na aplicação dos tratamentos.

1.2 OBJETIVOS

Este trabalho tem como objetivo desenvolver um software, aplicando os conhecimentos adquiridos ao longo do curso de Sistemas de Informação, que ajude o veterinário a desenvolver um diagnóstico melhor possível (para o sistema), com base nos dados já armazenados no seu banco de dados.

Este sistema auxilia o veterinário a elaborar um diagnóstico com mais precisão e rapidez, visto que permite a identificação da doença mais provável do animal (com base nos sinais clínicos apresentados) e disponibiliza as formas tratamento (se já cadastradas no banco) para a mesma.

1.2.1 Objetivo geral

Estender o projeto de extrapolação alométrica com o módulo diagnóstico, auxiliando o veterinário na tarefa de elaboração de diagnósticos.

(15)

1.2.2 Objetivos específicos

Além da aplicação dos conhecimentos acadêmicos de gerência, qualidade e engenharia de software em um projeto real, este projeto também tem por objetivo, através do sistema proposto:

• Obter Tratamentos para Sinais Clínicos apresentados pela espécie

• Obter Doenças por sinais clínicos

• Obter Tratamentos para possível Doença

• Consultar características da espécie

• Consultar tratamento sugeridos pelo sistema

1.3 METODOLOGIA DE TRABALHO

Para a realização do trabalho proposto, foram seguidos os seguintes passos: a) Análise do processo de diagnóstico de doenças em animais através de entrevista

com veterinário;

b) Pesquisas relacionadas sobre diagnósticos de espécies de animais em sites e livros que abordam esse estudo.

c) Desenvolvimento do Protótipo adotando conhecimento adquirido através de estudo de novas tecnologias dentro da plataforma JAVA.

d) Estudo da base de dados e comportamento do sistema de alometria.

1.4 DESCRIÇÃO DOS CAPÍTULOS

O trabalho está estruturado em 9 capítulos.

O capítulo 2 possui uma descrição dos principais conceitos utilizados no desenvolvimento deste trabalho.

(16)

O capítulo 3 apresenta o levantamento de requisitos do sistema proposto, informando os problemas analisados, e suas respectivas soluções, bem como a diagramação e a descrição dos casos e uso e seus respectivos atores.

O capítulo 4 apresenta a especificação de análise do sistema proposto. Neste capítulo são apresentados os modelos de classe e comportamental.

O capítulo 5 apresenta duas propostas tecnológicas, dentre as quais foi escolhida uma, justificando o motivo da escolha.

O capítulo 6 apresenta a especificação de projeto do sistema. Este capítulo apresenta os componentes e pacotes, onde cada pacote é descrito detalhadamente.

O capítulo 7 apresenta o projeto de segurança do sistema, com práticas necessárias a fim de que as informações estejam disponíveis no local e no momento estabelecido e de forma confiável.

O capítulo 8 apresenta a conclusão do trabalho, bem como a citação de projetos futuros.

No capítulo 9 estão as referências bibliográficas utilizadas durante a realização deste trabalho de conclusão de curso.

(17)

2 CONCEITOS

Neste capítulo serão apresentados os principais conceitos que serão utilizados durante o desenvolvimento deste trabalho.

2.1 ALOMETRIA

Segundo Sedqwick, o princípio alométrico usa uma escala de parâmetros fisiológicos comparando animais de vários tamanhos, sendo esta mesma escala usada para parâmetros farmacocinéticos [11].

A alometria é o cálculo de dosagem por meio de taxa metabólica do animal, permitindo calcular, por extrapolação, as doses como também a freqüência de administração dos medicamentos.

A alometria interespecífica (de que trata o software alometria) é um método que permite, através das doses de medicamentos indicadas para uma espécie de vertebrado (animal modelo), extrapolar por meio de cálculos aritméticos para outro vertebrado diferente (animal alvo), através do conhecimento das taxas metabólicas de ambos.

2.2 SEMIOLOGIA

A semiologia é a parte da medicina que estuda os métodos de exame clínico, pesquisa os sintomas e os interpreta, reunindo, dessa forma, os elementos necessários para construir o diagnóstico e presumir a evolução da enfermidade.

O sintoma por definição, é todo o fenômeno anormal, orgânico ou funcional, pelo qual as doenças se revelam no animal (tosse, claudicação, dispnéia)[10].

(18)

2.3 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

Existem várias formas de se desenvolver um software. Cada tipo de desenvolvimento existe uma metodologia para o ciclo de vida do desenvolvimento.

O ciclo de vida do desenvolvimento de sistemas é o processo de compreensão de um sistema de informações que pode suprir as necessidades da empresa, projetar o sistema, construí-lo e entregá-lo aos usuários [06].

Entre os principais modelos estão o Modelo Cascata, o Modelo Incremental e Modelo Espiral.

Como houve participação ativa do cliente no projeto e ele sabia exatamente o que queria (ou seja, os requisitos foram bem compreendidos e não teriam mudanças posteriores), o modelo adotado no desenvolvimento do sistema de diagnóstico clínico foi o modelo cascata, que será apresentado a seguir.

2.3.1 Modelo ciclo de vida cascata.

O modelo cascata funciona da seguinte forma, a cada fase do projeto que for aprovado pelo responsável o sistema avança para a próxima etapa.

(19)

Figura 1 – Modelo cascata

Este modelo é o mais fácil de ser gerenciado, e o preferido para problemas bem definidos com requisitos estabelecidos claramente como é o caso.

2.4 PROGRAMAÇÃO OO (Orientada a Objetos)

O paradigma de programação escolhido para o projeto foi o orientado a objetos, que pressupõe que o mundo é composto por objetos e que o sistema é modelado como um número de objetos que interagem.

Alguns conceitos são de extrema importância neste tipo de programação, são eles [02]:

• Classe: é a definição de características e funcionalidades do objeto. As classes são declarações do objeto.

• Propriedades das Classes: As propriedades ou atributos são as características dos objetos. Quando definimos uma propriedade normalmente especificamos seu nome e seu tipo.

(20)

• Métodos das classes: São as funcionalidades associadas aos objetos.

• Objetos: São exemplares de uma classe qualquer.

• Herança: A herança serve para criar objetos que incorporem propriedades e métodos de outros objetos.

2.5 LINGUAGEM DE MODELAGEM UNIFICADA

Na parte de análise e projeto de sistema foi utilizada a Linguagem de Modelagem Unificada (Unified Modeling Language, UML) como padrão de modelagem.

A UML surgiu como resultado de uma década de trabalho de Grady Booch, James Rumbaugh e Ivar Jacobson para combinar (unificar) as melhores características de seus métodos de análise e projeto orientados a objetos. [08]

A UML é uma linguagem gráfica, para visualização, especificação, construção e documentação de artefatos de sistemas complexos de software. A UML proporciona uma forma-padrão para a preparação de planos de arquitetura de projetos de sistemas, incluindo aspectos conceituais tais como processos de negócios e funções do sistema, além de itens concretos como as classes escritas em determinada linguagem de programação, esquemas de bancos de dados e componentes de software reutilizáveis [04].

Depois de vistos os conceitos envolvidos no projeto, o próximo capítulo abordará o levantamento de requisitos, que consiste na segunda etapa do modelo cascata que foi utilizado neste trabalho.

(21)

3 LEVANTAMENTO DE REQUISITOS

A atividade de levantamento de requisitos corresponde à etapa de compreensão do problema aplicada ao desenvolvimento de software. O principal objetivo do levantamento de requisitos é que usuários e desenvolvedores, juntamente com os clientes, tentam levantar e definir as necessidades dos futuros usuários do sistema a ser desenvolvidos. Essas necessidades são geralmente denominadas requisitos [03].

3.1 DESCRIÇÃO DO AMBIENTE

No Hospital Veterinário do Centro Universitário de Vila Velha, os veterinários realizam tratamentos e cirurgias em espécie animais. Nos meios de apoio ao diagnóstico em pequenos e grandes animais, os acadêmicos aprendem o processo de diagnóstico e tratamento da doença ou sintomas apresentado pela espécie, objetivando curar o animal.

3.2 ANÁLISE DE PROBLEMAS, CAUSAS E POSSÍVEIS SOLUÇÕES.

Feita uma análise no Hospital da medicina veterinária da UVV, foram coletadas informações importantes sobre aplicação do método de diagnóstico por sinais clínicos. Foram coletados os principais problemas que dificultam o diagnóstico realizado em locais sem tecnologia.

A tabela 2 apresenta os problemas levantados, suas causas e suas possíveis soluções automatizadas.

(22)

Problemas Causa Solução

Lentidão na conclusão do diagnóstico

O veterinário perde muito tempo procurando informações de doenças

que se encaixa com os sinais clínicos.

Comparação automática dos sinais clínicos apresentados na espécie, retornando para o veterinário as possíveis doenças que se encaixam. Dificuldade em aplicação do tratamento na espécie

Não existe uma literatura completa com as informações dos tratamentos referente à doença da espécie. Fornecer todas as informações sobre os tratamentos existentes no mundo.

Pouca informação sobre a doença

Não existe uma literatura completa única com todas as informações de doença Guardar as informações das doenças de modo centralizado (em um único local).

Tabela 2 – Problemas, Causas e Soluções.

3.3 FONTE DE INFORMAÇÕES X LEVANTAMENTO DE DADOS

Antes de se iniciar as próximas fases do projeto, é necessário obter informações a respeito do mesmo com o cliente. Como o sistema atenderá a clientela da medicina veterinária, as fontes informações utilizadas foram funcionários do Hospital Veterinário da UVV para a elicitação dos requisitos.

Existem várias técnicas de levantamento de requisitos, tais como entrevistas, leitura de documentos, questionários, observação, análise de protocolos, brainstorming, workshop de requisitos e cenários.

Devido à facilidade de contato direto com o cliente e também por permitir validação imediata dos requisitos, foi utilizada inicialmente entrevista técnica. Para esclarecer dúvidas que surgiram após a entrevista, foram utilizados também questionários.

A Tabela 3 apresenta as pessoas utilizadas como fontes de informações e suas respectivas funções no Centro Universitário Vila Velha, assim como o tipo de levantamento de dados utilizados para o levantamento de requisitos do sistema.

(23)

Fonte de informação Função exercida Levantamento de dados Prof. Dr. João Luiz Rossi

Jr

Professor de Nível Superior na área de Medicina Veterinária.

Entrevista técnica.

Prof.ª Dr.ª Flaviana Lima Guião Leite

Professora de Nível Superior na área de Medicina Veterinária e Coordenadora do Comitê de Ética para Análise de Projetos e Protocolos de Pesquisa, Ensino e Extensão envolvendo Animais do Centro Universitário Vila Velha (CEP - Animais - UVV).

Entrevista técnica e Questionários.

Tabela 3 – Fonte de Informações X Levantamento de requisitos .

No projeto de extrapolação alométrica foram usados 2 pacotes incorporando as funcionalidades gerencia e alométrico, conforme pode ser visto na figura 2

Figura 2 – Diagrama de pacote alométrico

(24)

Figura 3 – Diagrama de caso de uso alométrico

Para o desenvolvimento deste trabalho foi incorporado um novo pacote responsável pela funcionalidade relativa ao protótipo.

Assim, o diagrama de pacote incluiu o pacote mostrado a figura a seguir.

(25)

Além dos novos casos de uso foi feito a alteração em alguns casos de uso, são eles: manter tratamento e manter doença

Para especificar os requisitos levantados deste trabalho, a seguir é apresentada a modelagem de caso de uso que consiste na geração do digrama de caso de uso e suas respectivas descrições.

3.4 DIAGRAMAS DE CASOS DE USO

O diagrama de caso de uso (DCU) corresponde a uma visão externa do sistema e representa graficamente os atores, caso de uso e relacionamento entre esses elementos. O diagrama de caso de uso tem o objetivo de ilustrar em um nível alto de abstração quais elementos externos interagem com que funcionalidades do sistema. Nesse sentido, a finalidade de um DCU é apresentar um tipo de “diagrama de contexto” que apresenta os elementos externos de um sistema e as maneiras segundo as quais eles as utilizam[03].

Conforme explicado, a figura 5 representa o diagrama de caso de uso e na seqüência seguem a descrição do ator e a descrição de casos de usos do sistema:

(26)

(27)

3.5 DESCRIÇÃO DO ATOR

A seguir, é descrito o ator representado no diagrama da Figura 5.

3.5.1 Veterinário

O veterinário é o ator responsável por realizar a interação com a funcionalidade do sistema, e fornece as informações necessárias para o diagnóstico ser mais eficaz.

3.6 DESCRIÇÃO DOS CASOS DE USO

Nesta seção será feita a descrição dos casos de uso da figura 5. Só serão mostrados os casos de uso do pacote diagnóstico e os casos Manter Sinal Clínico (que foi incluso no pacote alométrico), Manter Doença e Manter Tratamento (que foram alterados).

3.6.1 Identificar Paciente

Informações adicionais: Anexo I – Dados

Campo Regra / Descrição Tipo Editáveis Obrigatório Grupo O sistema gera uma lista de espécie de

grupo.

N N S

Espécie O sistema gera uma lista de espécie referente ao grupo

L S S

CSU01 - Identificar Paciente Sumário: Ator identifica o paciente. Ator Principal: Veterinário

Pré-Condições: O ator deverá estar logado no sistema. Fluxo Básico – Identificar Paciente

1. Este caso de uso inicia quando o ator opta pelo menu Diagnóstico no sistema; 2. O ator seleciona os dados (ver abaixo anexo I) do paciente;

3. Este caso de uso se encerra. Fluxos Alternativos: Não se aplica

Pós-Condições: Uma paciente foi identificada. Regras de negócio relacionadas: N/A

(28)

Sinais Clínicos

O sistema gera uma lista de Sinais Clínicos A S S Legenda de Tipos: Numérico: N Alfanumérico: A Letra: L Cenários 3.6.2 Diagnosticar Cenário <#>

Fluxo Básico Fluxo

Alternativo <#>

Fluxo Alternativo <#>

... outros fluxos

1 - Avaliar Fluxo Básico

CSU02 - Diagnosticar

Sumário: Ator realiza um diagnóstico no paciente. Ator Principal: Veterinário

Pré-Condições: ter passado pelo caso de uso Identificar Paciente. Fluxo Básico – Diagnosticar

1. Este caso de uso inicia quando o ator opta por Diagnóstico após ter feito a identificação do paciente; (#E1)

2. O Sistema exibe uma lista de doenças que satisfazem aos Critérios de Pesquisa; (#E2)

3. O ator seleciona uma doença da lista e opta por tratamento;

4. O Sistema exibe uma lista de tratamento referente à doença selecionada; (#E2)

5. O Este caso de uso se encerra. Fluxos Alternativos

Fluxos Exceções

(#E1) – Dados obrigatórios não são informados

1. Sistema retorna uma mensagem informando o erro. 2. Retorna ao ponto de chamada.

(#E2) – O Sistema não retorna os dados na lista mediante os critérios de pesquisa informados:

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

2. Retorna ao ponto de chamada.

Pós-Condições: Uma espécie foi diagnosticada. Regras de negócio relacionadas: N/A

(29)

Informações adicionais:

Anexo I – Critérios de pesquisa

Campo Regra / Descrição Tipo Editáveis Obrigatório Sintomas O sistema realiza a busca por doença

referente os sintomas apresentados

L S S Legenda de Tipos: Numérico: N Alfanumérico: A Letra: L Cenários

Cenário <#> Fluxo Básico Fluxo Alternativo <#> Fluxo Alternativo <#> ... outros fluxos

1 -

Diagnosticar

Fluxo Básico

3.6.3 Avaliar CSU03 - Avaliar

Sumário: Ator realiza uma avaliação do(s) sintoma(s) da espécie. Ator Principal: Veterinário

Pré-Condições: ter passado pelo caso de uso Paciente. Fluxo Básico – Avaliar

1. Este caso de uso inicia quando o ator opta por terapêutica após ter feito a identificação do paciente; (#E1)

2. O Sistema exibe uma lista de tratamentos que satisfazem aos Critérios de Pesquisa; (#E2)

3. O ator seleciona um tratamento da lista e opta por Exibir tratamento; (#A1) 4. Este caso de uso se encerra.

Fluxos Alternativos

(#A1) - Detalhar Dados do tratamento

1. O ator seleciona o tratamento desejado na lista;

2. O sistema retorna uma tela com os dados do tratamento selecionado; 3. O ator navega pelo detalhamento;

(30)

Campo Regra / Descrição Tipo Editáveis Obrigatório Sintomas O sistema realiza a busca por

nome de sintoma no(s) sintoma(s) inicial(is) do(s) tratamento(s)

L S S

Anexo II – Dados

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

Paciente L N S Doença L N S Evolução L N S Espécie L N S Veterinário L N S Data inicio N N S Data termino N N S Situação L N S RG N N S Sintoma(s) Inicial(is) L N S Remédio L N S Dosagem N N S Freqüência N N S Duração N N S Motivo A N S Fluxos Exceções

(#E1) – Dados obrigatórios não são informados

1. Sistema retorna uma mensagem informando o erro. 2. Retorna ao ponto de chamada.

Pós-Condições: Ator realizou uma avaliação de tratamento do(s) sintoma(s) da espécie.

Regras de negócio relacionadas: N/A

(31)

Legenda de Tipos: Numérico: N Alfanumérico: A Letra: L Cenários Cenário <#> Fluxo Básico Fluxo Alternativo <#> Fluxo Alternativo <#> ... outros fluxos 1 – Tratar Sintomas Fluxo Básico

3.6.4 Manter Sinal Clínico

CSU04 – Manter Sinal Clínico

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

Ator Principal: Veterinário

Pré-Condições: O ator deverá estar logado no sistema. Fluxo Básico – Incluir Sinal clinico

1. Este caso de uso inicia quando o ator opta por incluir um novo sinal clinico;

2. O ator insere o dado de sinal clinico; (#A1) 3. O sistema faz a validação dos dados; (#E1) 4. O ator salva os dados de Sintoma;

5. O sistema gera o código automaticamente; 6. O sistema retorna uma mensagem de sucesso; 7. O ator confirma a mensagem;

8. Este caso de uso se encerra. Fluxos Alternativos

(#A1) - Pesquisar Dado de Sinal Clinico

1. O ator informa os dados de Critérios de Pesquisa;

2. O sistema aplica os Critérios de Pesquisa e faz a busca; (#E2)

3. O sistema exibe uma lista dos sinais clínicos que satisfazem aos Critérios de Pesquisa;

4. O ator navega na lista exibida; (#A2) 5. Este caso de uso se encerra.

(#A2) - Detalhar Dados de Sinal clinico

1. O ator seleciona o código de Sinal clinico desejado na lista existente; 2. O sistema retorna uma tela com o dado de Sinal clinico selecionado; 3. O ator navega pelo detalhamento; (#A3) (#A4)

(32)

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

clínico

O sistema realiza a busca por qualquer parte do nome do Sintoma

L S S

Especialização O sistema realiza a busca pelo nome da especialização

L S S

Anexo I. I – Pesquisar sem informar Critérios de Pesquisa

Ao selecionar a opção Pesquisar sem informar qualquer critério de pesquisa, o sistema exibe uma lista com todas as Permutas Efetuadas para o Tipo de Permuta Selecionado.

Campo Regra / Descrição Tipo Editáveis Obrigatório Código O sistema gera automaticamente um

número de identificação. Último numero gerados mais 1. Começa a partir de 0001. N N S Nome do Sinal clínico L S S

(#A3) - Alterar Dados de Sinal clinico

1. O sistema retorna uma tela com o dado editável; 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 do dado. (#E1) 6. O sistema altera os dados de Sintoma;

7. O sistema retorna uma mensagem de sucesso; 8. Este caso de uso se encerra.

(#A4) - Excluir Sinal clinico

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

3. O ator confirma;

4. O sistema exclui o dado;

(33)

Legenda de Tipos: Numérico: N Alfanumérico: A Letra: L Cenários Cenário <#> Fluxo Básico Fluxo Alternativo <#> Fluxo Alternativo <#> ... outros fluxos 1 - Incluir Sinal clínico Fluxo Básico 2 – Pesquisar Dados de Sinal clínico Fluxo Básico Fluxo Alternativo 1 3 – Detalhar Dados de Sinal clínico Fluxo Básico Fluxo Alternativo 1 Fluxo Alternativo 2 4 – Alterar Dados de Sinal clínico Fluxo Básico Fluxo Alternativo 1

Fluxo Alternativo 2 Fluxo

Alternativo 3 5 – Excluir Sinal clínico Fluxo Básico Fluxo Alternativo 1

Fluxo Alternativo 2 Fluxo

Alternativo 4

3.6.5 Manter Doença CSU05 – Manter Doença

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

Pré-Condições: O ator deverá estar logado no sistema. Fluxo Básico – Incluir Doença

1. Este caso de uso inicia quando o ator opta por incluir uma nova doença; 2. O ator insere os dados da doença; ( #A1 )

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

(34)

Fluxos Alternativos

(#A1) - Pesquisar Dados da doença

3. O sistema exibe uma lista dos tratamentos que satisfazem aos Critérios de Pesquisa;

(#A2) - Detalhar Dados da doença

1. O ator seleciona o código da doença desejado na lista existente; 2. O sistema retorna uma tela com os dados da doença selecionada; 3. O ator navega pelo detalhamento; (#A3) (#A4)

4. Este caso de uso se encerra. (#A3) - Alterar Dados da doença

1. O sistema retorna uma tela com os dados editáveis dados; 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 da doença;

(#A4) - Excluir doença

3. O ator confirma;

4. O sistema exclui os dados;

5. O sistema retorna uma mensagem de sucesso; Este caso de uso se encerra.

Fluxos Exceções

(#E1) – Dados Obrigatórios

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

2. Retornar ao ponto de entrada de dados.

Retorna ao ponto de chamada.

Pós-Condições: Uma doença foi inserida, removida ou alterada. Regras de negócio relacionadas: N/A

(35)

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

doença

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

L S S

Campo Regra / Descrição Tipo Editáveis Obrigatório Código O sistema gera automaticamente

um número de identificação. Último numero gerados mais 1. Começa a partir de 0001. N N S Nome da doença L S S Descrição A S N Evolução A S S Legenda de Tipos: Numérico: N Alfanumérico: A Letra: L Cenários Cenário <#> Fluxo Básico Fluxo Alternativo <#> Fluxo Alternativo <#> ... outros fluxos 1 - Incluir doença Fluxo Básico 2 – Pesquisar Dados de doença Fluxo Básico Fluxo Alternativo 1 3 – Detalhar Dados de doença Fluxo Básico Fluxo Alternativo 1 Fluxo Alternativo 2

(36)

4 – Alterar Dados de doença Fluxo Básico Fluxo Alternativo 1 Fluxo Alternativo 2 Fluxo Alternativo 3 5 – Excluir doença Fluxo Básico Fluxo Alternativo 1 Fluxo Alternativo 2 Fluxo Alternativo 4 3.6.6 Manter Tratamento CSU06 – Manter Tratamento

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

Pré-Condições: Ator deverá estar logado no sistema. Fluxo Básico – Incluir Tratamento

1. Este caso de uso inicia quando o ator opta por incluir um novo tratamento 2. O ator insere os dados do tratamento; ( #A1 )

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

8. Este caso de uso se encerra. Fluxos Alternativos

(#A1) - Pesquisar Dados do tratamento

3. O sistema exibe uma lista dos tratamentos que satisfazem aos Critérios de Pesquisa;

(#A2) - Detalhar Dados do tratamento

1. O ator seleciona o código do tratamento desejado na lista existente; 2. O sistema retorna uma tela com os dados do tratamento selecionada; 3. O ator navega pelo detalhamento; (#A3) (#A4)

4. Este caso de uso se encerra. (#A3) - Alterar Dados do tratamento

1. O sistema retorna uma tela com os dados editáveis dados; 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 tratamento; 7. O sistema retorna uma mensagem de sucesso; 8. Este caso de uso se encerra.

(37)

(#A4) - Excluir Tratamento

3. O ator confirma;

4. O sistema exclui os dados;

Fluxos Exceções

(#E1) – Dados Obrigatórios

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

2. Retornar ao ponto de entrada de dados.

Informações adicionais: Anexo I - Critério de Pesquisa

Campo Regra / Descrição Obrigatório

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

N

Situação N

Paciente O sistema realiza a busca por qualquer parte do nome do paciente

N

Código N

Período N

Pós-Condições: Um tratamento foi inserido, removido ou alterado. Regras de negócio relacionadas: N/A

(38)

Campo Regra / Descrição Tipo Editáveis Obrigatório Código O sistema gera automaticamente um

número de identificação. Último numero gerados mais 1. Começa a partir de 0001. N N S Paciente A S S Doença L S S Evolucao L S S Espécie L S S

Veterinária Responsável pelo tratamento do animal L S S Sinal clínico inicial L S S RG Registro da espécie N S S

Data início Inicio do tratamento N S S

Data termino Final do tratamento N S N

Situação Com sucesso, sem sucesso e andamento.

L S S

Medicamento L S S

Motivo Motivo do uso do medicamento A S N

Duração Duração do medicamento N S S

Dosagem Dosagem do medicamento N S S

Freqüência Freqüência do medicamento N S S

Legenda de Tipos: Numérico: N Alfanumérico: A Letra: L Cenários Cenário <#> Fluxo Básico Fluxo Alternativo <#> Fluxo Alternativo <#> ... outros fluxos 1 - Incluir tratamento Fluxo Básico 2 – Pesquisar Dados de tratamento Fluxo Básico Fluxo Alternativo 1 3 – Detalhar Dados de tratamento Fluxo Básico Fluxo Alternativo 1 Fluxo Alternativo 2

(39)

4 – Alterar Dados de tratamento Fluxo Básico Fluxo Alternativo 1 Fluxo Alternativo 2 Fluxo Alternativo 3 5 – Excluir tratamento Fluxo Básico Fluxo Alternativo 1 Fluxo Alternativo 2 Fluxo Alternativo 4

Após a especificação dos requisitos, vem à segunda etapa do modelo cascata, a análise, que será desenvolvida no capítulo a seguir.

4 ESPECIFICAÇÃO DE ANÁLISE

Formalmente, o termo análise corresponde a “quebrar” um sistema em seus componentes e estudar como tais componentes interagem com o objetivo de entender como esse sistema funciona. No contexto dos sistemas de software, esta é a etapa na qual os analistas realizam um estudo detalhado dos requisitos levantados na atividade anterior. [03]

Como foi visto anteriormente no capítulo 2, neste trabalho foi utilizado o paradigma orientado a objetos. Como a UML foi uma tentativa de unificar os principais métodos orientados a objetos utilizados até a sua criação e pode ser utilizada em todos os processos de desenvolvimento orientados a objetos, ela foi utilizada como linguagem de modelagem padrão neste trabalho.

4.1 MODELO DE CLASSES

Com base na especificação dos requisitos e nos diagramas de caso de uso, é possível iniciar a modelagem do sistema. O primeiro passo é descobrir quais classes devem ser incluídas no modelo.

Uma classe é uma descrição de um conjunto de objetos que compartilham os mesmos atributos, operações, relacionamentos e semântica. Uma classe implementa uma ou mais interfaces [04].

A notação básica da UML para classes em um diagrama de classes é mostrada abaixo:

(40)

Classe Atributos da Classe Operações da Classe

Os atributos são as características que um objeto pode assumir e as operações (métodos) são as ações que um objeto pode realizar. Objetos com propriedades e comportamentos idênticos são descritos como instâncias de uma mesma classe.

Na próxima seção será visto o diagrama de classes do módulo diagnóstico.

4.1.1 Diagrama de Classes

O Diagrama de classes é o modelo fundamental de uma especificação orientada a objetos. Produz a descrição mais próxima da estrutura do código de um programa, isto é, mostram o conjunto de classes com seus atributos, métodos e os relacionamentos entre classes. Classes e relacionamentos constituem os elementos sintáticos básicos do digrama de classe [13].

Na figura 6 é apresentado o diagrama de classe do módulo proposto neste trabalho (diagnóstico), com suas classes e relacionamentos.

(41)

Para entender melhor as classes acima, na seção 4.2 será exibido o dicionário de dados das mesmas.

4.2 DICIONÁRIO DE DADOS

A tabela 4 apresenta o dicionário de dados das classes do sistema, exibidas na figura anterior.

Tratamento

ATRIBUTO TIPO DESCRIÇÃO

Situacao String Andamento da realização do tratamento

Paciente String Nome ou Apelido da espécie DataIni Date Data de entrada da espécie no

tratamento

RG String Registro da espécie

DataFim Date Data final do tratamento da

espécie

Veterinario String Nome do veterinário

responsável pelo tratamento Modificado Date Data de criação ou modificação

Doença

Nome String Nome da doença

Transmissao String Modo que a doença é

transmitida para a espécie. Modificado Date Data de criação ou modificação

Evolução

Nome String Nome da fase da evolução

Modificado Date Data de criação ou modificação SinalClinico

Nome Nome do sintoma

Modificado Date Data de criação ou modificação SinalTratamento

Modificado Date Data de criação ou modificação MedTratamento

motivo String Motivo do uso do medicamento

dosagem Int Dosagem do medicamento

frequencia Int Freqüência do uso do

medicamento

Duracao Int Duração do uso do

medicamento

Modificado Date Data de criação ou modificação Especializacao

Especializacao String Nome da área do Sinal Clínico Tabela 4 – Dicionário de dados

(42)

4.3 DIAGRAMA DE INTERAÇÃO

Os diagramas de interação representam o comportamento de realização de um caso de uso, do ponto de vista interno ao sistema, demonstrando como o ator atinge o seu objetivo. Estes diagramas auxiliam no entendimento e documentação dos aspectos dinâmicos do funcionamento do software, ou seja, eles descrevem a seqüência de mensagens enviadas e recebidas pelos objetos de um caso de uso. Existem dois tipos de diagramas de interação, o diagrama de seqüência e o de colaboração. Sendo estes equivalentes entre si [03].

4.3.1 Diagrama de Seqüência

O diagrama de seqüência é voltado a descrever objetos interagindo. Seus principais elementos sintáticos são objetos e mensagem (enviada de um objeto a outro). É voltado à modelagem dinâmica do sistema principal finalidade em uma modelagem orientada a objetos é o refinamento de casos de uso. O tempo decorre de cima para baixo – a primeira mensagem, enviada para invocar um método do objeto destinatário, é a que aparece mais acima no diagrama [13].

A seguir, são apresentados os diagramas de seqüência construídos para o sistema.

4.3.1.1 Avaliar

Ao executar este caso de uso, o veterinário entra com os sintomas iniciais do animal no sistema. A aplicação então retorna uma lista de tratamentos para os sintomas.

(43)

Figura 7 - Diagrama de seqüência Avaliar

4.3.1.2 Diagnosticar

Ao executar este caso de uso, o veterinário entra com os sintomas clínicos do animal no sistema. A aplicação busca todas as doenças que contém pelo menos um dos sinais assim como os tratamentos para cada uma dessas doenças. Após isso, a aplicação compara os sinais clínicos de cada doença com os apresentados pelo animal, ordenando as doenças por ordem de relevância (da que contém mais sintomas para a que contém menos).O sistema retorna a lista de doenças e o veterinário tem a opção de ver os tratamentos de cada doença retornada.

(44)

(45)

Ao executar este caso de uso, o veterinário entra com o nome da doença e o nome da evolução no sistema. A aplicação verifica se a doença não está já cadastrada. Se não estiver, cria um objeto doença e atribui o nome da doença e cria um objeto evolução e atribui o nome da evolução. As informações são salvas com a data do sistema e a aplicação exibe uma mensagem informando que a doença foi incluída com sucesso.

O diagrama de sequência é exibido na figura 9.

(46)

4.3.1.4 Alterar Doença

Ao executar este caso de uso, o veterinário entra com o nome da doença e o nome da evolução no sistema. O nome da doença é atribuído ao objeto doença e o nome da evolução ao objeto evolução. As informações são salvas com a data do sistema e a aplicação exibe uma mensagem informando que a doença foi alterada com sucesso.

O diagrama de sequência é exibido na figura 10.

(47)

4.3.1.5 Consultar Doença

(48)

(49)

4.3.1.7 Novo Tratamento

(50)

(51)

(52)

(53)

(54)

(55)

(56)

Figura 20 - Diagrama de seqüência excluir sinal clinico

Feita a análise do sistema, pode-se então fazer propostas de soluções com suas respectivas estimativas de custo. É o que será visto no capítulo a seguir.

(57)

5 PROPOSTA DE SOLUÇÕES TECNOLÓGICAS

A proposta de solução tecnológica tem como objetivo mostrar da solução proposta em termos de hardware, software e mão de obra aplicados na mesma.

Não pode-se propor preços sem estimativas. Por isso foi usada a análise de ponto de função, que será vista a seguir.

5.1 ANÁLISE DE PONTO DE FUNÇÃO (APF)

Antes de propor um orçamento, é necessário estimar o tamanho do software. Existem várias propostas de métricas, sendo um delas a ponto de função.

Ela é uma métrica com objetivo principal de medir a funcionalidade de um software ou aplicativo, baseando-se primeiramente no desenho lógico, de acordo com a perspectiva do usuário.[05] Permite medir as funcionalidades do sistema requisitadas e recebidas pelo usuário, de forma independente da tecnologia usada na implementação.

Para determinar o tamanho funcional do sistema a ser desenvolvido usando APF, é preciso determinar as funções do tipo dados e as funções do tipo transação, que serão apresentados nas duas seções a seguir.

5.1.1 Funções do tipo dados

Funções do tipo dados representam a funcionalidade provida ao usuário para atender requerimentos externos e internos referentes a dados. Funções do tipo dados pode ser arquivos lógicos internos ou arquivos de interface externa.

Um arquivo lógico interno (ALI) é um grupo de dados logicamente relacionados, ou informações de controle, identificado pelo usuário e que recebe manutenção dentro das fronteiras da aplicação que está sendo contada.

Um arquivo de interface externa (AIE) é um grupo de dados logicamente relacionados, ou informações de controle, utilizados no sistema que está sendo analisado, mas que não recebem manutenção dentro das fronteiras da aplicação

(58)

que está sendo contada. Conseqüentemente este AIE será mantido por outro sistema onde será contabilizado como ALI.

A tabela 5 apresenta os tipos de dados do módulo diagnóstico Tipo de dado Tipo Tipo de Dados Tipos de Registros Complexidade Peso

Doença AIE 3 2 Baixa 5

Sinais Clínicos AIE 2 1 Baixa 5

Tratamento AIE 19 3 Media 7

Total 17

Tabela 5 – Tipo de dado 5.1.2 Funções do tipo transação

Funções do tipo transação representam a funcionalidade provida ao usuário de processamento dos dados pela aplicação. Funções transacionais são definidas como entradas externas (EE), saídas externas (SE) e consultas externas (CE).

Listar espécies: nome da espécie.

Listar Grupo de espécies: nome do grupo espécie. Listar sinais clínicos: nome do sinal clínico.

Consultar doença: nome da doença e quantidades de sinais clínicos encontrados

Listar tratamento: código, veterinário, situação do tratamento, grupo, espécie, paciente.

Consultar tratamento: paciente, veterinário, grupo e quantidades de sinais clínicos encontrados.

Uma entrada externa(EE) processa dados ou informações de controle geradas por fonte externa à aplicações que está sendo contada. São transações que mantêm dados armazenados no sistema.

Uma saída externa(SE) fornece dados ou informação de controle para fora da aplicação que está sendo contada. São transações que extraem informações do sistema para outros aplicativos

(59)

Os cálculos de ponto de função de todas as funcionalidades são visualizados na tabela a seguir.

Tipo Função

Função Tipo TD AR Complexidade Peso Listar espécies CE 1 + 2 1 Baixa 3

Listar grupo de espécies CE 1 + 2 1 Baixa 3

Listar sinais clínicos CE 1 + 2 1 Baixa 3

Consultar doenças SE 2 + 2 2 Baixa 3

Listar tratamento CE 6 + 2 3 Media 4

Consultar tratamento SE 4 + 2 3 Media 4

Total 20

Tabela 6 – Tipo de função Legenda dos tipos apresentados na tabela 6:

CE: Consulta externa SE: saída externa

5.2 CUSTO DO SISTEMA

Antes de fechar um valor para o sistema, precisamos analisar alguns custos descritos a seguir:

A) Equipe de Desenvolvimento

(60)

Equipe

Profissional Quantidade Produtividade Forma de pagamento

Analista 1 8h/PF R$ 120,00/PF

Desenvolvedor 1 8h/PF R$ 90,00/PF

Tabela 7 – Equipe

A produtividade e o valor de pagamento são valores de mercado, pois não tem um padrão de salários dos funcionários.

B) Custo do Desenvolvimento Tempo gasto com Análise 70%

Tempo gasto com Desenvolvimento 30% ANALISE - 70% X 37 = 26 PF

ESFORÇO – 26 X 8h = 208 /4 = 52 horas, aproximadamente 1 mês CUSTOS - 26 x 120 = R$3.120,00

PROGRAMAÇÃO - 30% X 37

ESFORÇO – 11 X 8 = 88 horas, aproximadamente 1 mês CUSTOS = 88 X 90 = R$ 7.920,00

Custo Total de Desenvolvimento R$ 3.120,00+ R$ 7.920,00 = R$ 11.040,00 Prazo Total de Desenvolvimento 2 meses.

(61)

C) Propostas Tecnológicas

A tecnologia usada influencia no preço final do software. Assim, é sugerida duas propostas, uma usando Java e outra usando Delphi, como segue:

Proposta 1

• Sistema Operacional: Windows XP Professional – valor: R$ 539,00

• Plataforma de desenvolvimento Java: Netbeans IDE for java – valor: R$ 0,00

• Banco de dados: MySQL – valor: R$ 0,00

Fonte: http://www.livrariasaraiva.com.br/ visitado 06/07/2010 Custo total: R$ 539,00

Custo operacional (CO): Manuntenção R$ 1000,00 TOTAL = R$ 1000,00

Custo Investimento:

CI = Total mão de obra para desenvolvimento + Total Servidor + Total Hardware CI = R$11.040+ R$0,00 + R$0,00 CI = R$11.040 Custo Total: CT= CI + ( CO x Número de Meses) CT = R$11.040+ ( 1000 x 2) CT = R$13. 040,00 Benefícios Tangíveis :

Custo para elaborar orçamento: Número de funcionários = 2

(62)

Horas trabalhadas por mês de um funcionário = 160h Horas trabalhadas por mês na empresa = 320h

Valor médio por hora de um funcionário (em média) = 30,00/h Porcentagem media de tempo organizando atividades = 15%

Horas perdidas durante o mês na elaboração do orçamento = 320 x 15% = 48h Custo da elaboração do orçamento = 48 x 30 = R$ 1440,00

Custo de re-trabalho: Número de funcionários = 2

Horas trabalhadas por mês de um funcionário = 160h Horas trabalhadas por mês na empresa = 320

Horas perdidas durante o mês na elaboração do orçamento = 320 x 8% = 25,6h Custo da elaboração do orçamento = 25,6 x 30 = R$ 768,00

TOTAL = R$ 2208,00

Benefícios intangíveis Aumento de produtividade

Satisfação e rapidez na autuação

Prazo de Retorno

Para realizar o prazo de retorno, adota-se a fórmula PR =CI / (B-CO)

PR = 11.040 / (2208– 1000) PR = 9 meses

Proposta 2

• Sistema Operacional: Windows 7 Home Premium – valor: R$ 225,22

• Plataforma de desenvolvimento Delphi 6 profissional – valor: R$ 487,20

(63)

Custo operacional (CO): Manuntenção R$ 1000,00 TOTAL = R$ 1000,00

Custo Investimento:

CI = Total mão de obra para desenvolvimento + Total Servidor + Total Hardware CI = R$11.040+ R$225,22+ R$487,20 + R$10,195,00 CI = R$21.947 Custo Total: CT= CI + ( CO x Número de Meses) CT = R$21.947+ ( 1000 x 2) CT = R$23. 947,00 Benefícios Tangíveis :

Custo para elaborar orçamento: Número de funcionários = 2

Horas trabalhadas por mês de um funcionário = 160h Horas trabalhadas por mês na empresa = 320h

Horas perdidas durante o mês na elaboração do orçamento = 320 x 15% = 48h Custo da elaboração do orçamento = 48 x 30 = R$ 1440,00

Custo de re-trabalho: Número de funcionários = 2

Horas trabalhadas por mês de um funcionário = 160h Horas trabalhadas por mês na empresa = 320

(64)

Custo da elaboração do orçamento = 25,6 x 30 = R$ 768,00 TOTAL = R$ 2208,00

Benefícios intangíveis Aumento de produtividade

Satisfação e rapidez na autuação

Prazo de Retorno

Para realizar o prazo de retorno, adota-se a fórmula PR =CI / (B-CO)

PR = 23. 947,00/ (2208– 1000) PR = 19 meses

Fonte: http://www.amazon.com/ visitado em 06/07/2010 Fonte: http://www.microsoft.com/ visitado em 06/07/2010

Agora que foram definidos estes custos podemos então calcular o valor final das duas propostas e avaliar qual melhor atende, o que será feito na seção a seguir.

5.2.1 Proposta Escolhida

A proposta escolhida foi a primeira, não só pelo custo menor, mas também pela vantagem da utilização da linguagem Java que é multiplataforma, ou seja, se adéqua a diferentes tipos de sistemas operacionais.

(65)

6 ESPECIFICAÇÃO DE PROJETO

O objetivo da etapa de projeto é complementar ao da etapa de análise. Se na análise a questão é pensar no domínio do problema ignorando conceitos do mundo computacional, na etapa de projeto o foco é o domínio da solução computacional. Objetivo é selecionar as alternativas de solução que constituirão a solução computacional [13].

Neste capítulo serão apresentadas todas as especificações da fase de projeto.

6.1 ESCOLHA DA TECNOLOGIA

Para o desenvolvimento do modulo diagnóstico foi escolhido o ambiente netbeans 6.7.1 e o sistema para gerenciamento do banco de dados escolhido foi o MYSQL 5.1.37, a segundo a proposta 2 apresentado na seção 5.2.

6.2 ARQUITETURA DO SISTEMA

6.2.1 Diagrama de Pacotes

Para facilitar a visibilidade de um modelo de análise, tornando-o mais compreensível é útil agrupar classes que colaboram entre si em subsistemas. Esta identificação também ajuda a organizar o trabalho em projetos extensos.

A UML propõe o uso de um tipo especial de diagramas de classes, onde apenas subsistemas e suas relações são representados, os chamados diagramas de pacotes. [08]

(66)

Figura 21 – Visão geral do sistema, dividido em pacotes

Como pode ser visto , existem 4 pacotes:

O pacote utilitários, que é responsável pela solicitação de acesso ao banco de dados e pela estrutura do modelo da tabela da interface;

O pacote alométrico, que cuida da parte de extrapolação alométrica;

O pacote diagnóstico, que cuida da parte de diagnóstico;

O pacote gerencia, que permite o usuário acessar as funcionalidades dos pacotes alométrico e diagnóstico.

O pacote diagnóstico foi o proposto neste trabalho.

6.3 DIVISÃO EM CAMADAS

MVC (Modelo – Visão – Controlador (Model – View – Controller) foi a metáfora desenvolvida pela comunidade Smalltalk para uma arquitetura de projeto. Ela sugeretrês componentes principais: um grupo de classes que modela a aplicação em si; um grupo de classes que provê uma visão da interface com os usuários; um grupo de classes que controla, ou sincroniza, o comportamento dos demais. [09]

(67)

Como no Smalltalk todos os objetos são naturalmente persistentes, esta arquitetura acabou desconsiderando a gerência de dados. Assim, para o MVC suportar a persistência de dados optou-se por usar a abordagem de criar uma camada responsável pelo mapeamento entre objetos do domínio e tabelas do banco de dados. O padrão Objeto de Acesso a Dados (Data Access Object - DAO) (BAUER; KING, 2007) que adota esta filosofia foi a abordagem escolhida.

O sistema de diagnóstico adotará então o padrão de projeto de arquitetura MVC Estendido (MVC+DAO). Este é subdividido em quatro componentes, como mostra a Figura 9. Estas camadas são:

Componente de gerência tarefas (GT) - É responsável por implementar diretamente os requisitos dos usuários e as regras de negócios.

Componentes do domínio do problema (DP) - É responsável pela definição dos objetos que serão utilizados pelo sistema.

Componente gerência de dados (GD) - É responsável pelo acesso ao banco de dados.

Componente Interface com o Usuário (IU) - É responsável pela interface entre o sistema e o usuário.

O pacote diagnóstico foi decomposto no diagrama de pacotes da figura 22, agora tomando por base os estereótipos.

(68)

Figura 22 – Diagrama de Pacotes do Pacote Diagnóstico

Vale ressaltar que a dependência entre os pacotes CGD e CDP existe apenas para instanciar objetos recuperados do banco de dados. Nenhum outro serviço é utilizado e, portanto, esta é uma dependência fraca.

6.3.1 Componente Domínio do problema (DP)

A figura a seguir apresenta as alterações necessárias para a realização do módulo diagnóstico.

(69)