SISTEMA DE GESTÃO DE HÍPICA - sistemas24horas.com.br · empresa em estudo não possui um software...

FACULDADES INTEGRADAS “CAMPOS SALLES”

SISTEMA DE GESTÃO DE HÍPICA

São Paulo 2014

ALBERTO OLIVEIRA BARBOSA

LUCIANO DE SOUZA COELHO

MATHEUS DA ROCHA FERREIRA


Trabalho de Conclusão de Curso apresentado nas Faculdades Integradas “Campos Salles”, como pré-requisito para grau de Bacharel em Sistemas de Informação.

Orientador: Prof. Ms. Galvez Gonçalves

São Paulo 2014

ALBERTO OLIVEIRA BARBOSA

LUCIANO DE SOUZA COELHO

MATHEUS DA ROCHA FERREIRA


Trabalho de Conclusão de Curso apresentado nas Faculdades Integradas “Campos Salles”, como pré-requisito para grau de Bacharel em Sistemas de Informação.

Orientador: Prof. Ms. Galvez Gonçalves

Aprovado em ___/____/_____ BANCA EXAMINADORA ____________________________________________________ Prof. MS. xxxxxxxxxxxxxxxxxxxxxxxxxxxx ____________________________________________________ Prof. MS. xxxxxxxxxxxxxxxxxxxxxxxxxxxx ___________________________________________________ Prof. MS. xxxxxxxxxxxxxxxxxxxxxxxxxxxi

DEDICATÓRIA

A minha esposa, Simone da Silva Sousa Barbosa, que sempre me apoiou e

incentivou a buscar os meus sonhos, e aos meus pais, Alberto Rodrigues Barbosa e

Adália Cândida de Oliveira Barbosa, que sempre me incentivaram e apoiaram

minhas decisões.

ALBERTO

DEDICATÓRIA

A minha maravilhosa esposa, Giane Cássia Decêncio Coelho, que sempre me

incentivou para a realização dos meus ideais, encorajando-me a enfrentar todos os

momentos difíceis da vida.

Com muito carinho, dedico a minha mãe Eunice de Souza Coelho, pela

compreensão, apoio e contribuição para a minha formação acadêmica.

LUCIANO

DEDICATÓRIA

A minha mãe, que sempre me apoiou e incentivou a buscar os meus sonhos, e

minhas decisões.

MATHEUS

AGRADECIMENTOS

Agradeço primeiramente a Deus, que sempre iluminou e colocou pessoas

maravilhosas em minha vida, sem as quais não conseguiria chegar onde estou.

Agradeço também a minha esposa Simone, que sempre esteve comigo nas

horas difíceis, que me apoiou e sempre me incentivou a buscar o melhor e não

desistir dos meus sonhos.

Agradeço aos meus pais, Alberto e Adália, que com muito trabalho e

sacrifícios, nunca deixaram faltar nada em nossa casa e com seu exemplo

maravilhoso me ensinaram a nunca desistir e continuar a buscar minhas realizações.

E não poderia deixar de agradecer a todos aqueles que diretamente e

indiretamente contribuíram para a realização deste trabalho e a conclusão de mais

esta etapa.

ALBERTO

AGRADECIMENTOS

Agradeço em primeiro lugar a Deus que iluminou o meu caminho durante esta

caminhada.

Agradeço também a minha esposa, GIANE, que de forma especial e

carinhosa me deu força e coragem, me apoiando nos momentos de dificuldades,

Obrigado pela paciência, pelo incentivo, pela força e principalmente pelo carinho.

Valeu a pena toda a distância, todo o sofrimento, todas as renúncias... Valeu a pena

esperar... Hoje estamos colhendo, juntos, os frutos do nosso empenho! Esta

VITÓRIA é muito mais sua do que minha !!!

Quero agradecer também os meus filhos, DANILO e GLAUCO, que embora

não tivessem conhecimento disto, mas iluminaram de maneira especial os meus

pensamentos me levando a buscar mais conhecimentos. E não deixando de

agradecer de forma grata e grandiosa meus pais, JOSÉ COELHO, que infelizmente

não pode assistir esta grandiosa realização pessoal de seu filho e EUNICE

COELHO, a quem eu rogo todas as noites a minha existência.

Agradeço também a todos os Mestres que me acompanharam durante a

graduação, e os Mestres responsáveis pela realização deste trabalho.

Aos amigos e colegas, pelo incentivo e pelo apoio constantes.

LUCIANO

AGRADECIMENTOS

Agradeço primeiramente a Deus, que sempre iluminou e colocou pessoas

maravilhosas em minha vida, sem as quais não conseguiria chegar onde estou.

Agradeço também aos meus amigos, que sempre estiveram comigo nas

horas difíceis, que me apoiaram e sempre me incentivaram a buscar o melhor e não

desistir dos meus sonhos.

Agradeço a minha mãe, que com muito trabalho e sacrifício, me ensinou a

nunca desistir e continuar a buscar minhas realizações.

E não poderia deixar de agradecer a todos aqueles que diretamente e

indiretamente contribuíram para a realização deste trabalho e a conclusão de mais

esta etapa.

MATHEUS

RESUMO

O presente trabalho a ser apresentado nas Faculdades Integradas Campos Salles, propõe-se a implementar um projeto de desenvolvimento para informatizar o gerenciamento administrativo e o controle de aulas para Hípica. Verificou-se que a empresa em estudo não possui um software integrado capaz de fornecer informações precisas de seus clientes e alunos, sendo de fundamental importância a disponibilidade de um sistema que ofereça não somente um melhor controle administrativo, como também maior confiabilidade nas tomadas de decisões, proporcionando com isso, um equilíbrio entre os setores da empresa. O Sistema de Gestão de Hípica (SGH) tem como objetivo auxiliar na administração e efetuar previsões de maneira eficiente por meio de rotinas informatizadas. O SGH foi desenhado de forma a proporcionar uma experiência de navegação simples e intuitiva aos usuários.

Palavras-Chaves: GED. Gerenciamento. ECM. Documentos.

ABSTRACT

The current research to be presented at Faculdades Integradas "Campos Salles", propose to implement a development project to automate the administrative management and control Riding School's classes. It was found that the company over study does not have an integrated software capable to provide detailed information of its customers and students, which would be of essential importance to have a system that could offer not only a better administrative management, but also a better confiability making important decisions providing stability between the company sectors. The Riding School Management System (RSMS) has as purpose to help administrating and prevent through informatizated routines. The RSMS was developed to provide a simple and intuitive experience to its users, independent of the screen that the user is accessing, there will always have a possibility to the user go back and navigate between the screens. The RSMS was developed to serve every kind of user willing to automate his business about the system management.

Key Words: GED. Management. ECM. Document.

LISTA DE FIGURAS

Figura 01 – Diagrama de Casos de Uso (Sistema de Gerenciamento de Hípicas)

Figura 02 – Seções do Sistema (Manter Cliente)

Figura 03 – Seções do Sistema (Manter Professor)

Figura 04 – Seções do Sistema (Manter Animal)

Figura 05 – Seções do Sistema (Manter Alimentação)

Figura 06 – Seções do Sistema (Manter Ferradura)

Figura 07 – Seções do Sistema (Manter Medicação)

Figura 08 – Seções do Sistema (Manter Aulas)

Figura 09 – Seções do Sistema (Manter Relatórios)

Figura 10 – Diagrama de Classes Parcial

Figura 11 – Diagrama de Classes Total

Figura 12 – Diagrama de Sequência (Seção Cadastrar Cliente)

Figura 13 – Diagrama de Sequência (Seção Alterar Cliente)

Figura 14 – Diagrama de Sequência (Seção Apagar Cliente)

Figura 15 – Diagrama de Sequência (Seção Pesquisar Cliente)

Figura 16 – Diagrama de Sequência (Seção Cadastrar Professor)

Figura 17 – Diagrama de Sequência (Seção Alterar Professor)

Figura 18 – Diagrama de Sequência (Seção Apagar Professor)

Figura 19 – Diagrama de Sequência (Seção Pesquisar Professor)

Figura 20 – Diagrama de Sequência (Seção Cadastrar Animal)

Figura 21 – Diagrama de Sequência (Seção Alterar Animal)

Figura 22 – Diagrama de Sequência (Seção Apagar Animal)

Figura 23 – Diagrama de Sequência (Seção Pesquisar Animal)

Figura 24 – Diagrama de Sequência (Seção Cadastrar Alimentação)

Figura 25 – Diagrama de Sequência (Seção Alterar Alimentação)

Figura 26 – Diagrama de Sequência (Seção Apagar Alimentação)

Figura 27 – Diagrama de Sequência (Seção Pesquisar Alimentação)

Figura 28 – Diagrama de Sequência (Seção Cadastrar Ferradura)

Figura 29 – Diagrama de Sequência (Seção Alterar Ferradura)

Figura 30 – Diagrama de Sequência (Seção Apagar Ferradura)

Figura 31 – Diagrama de Sequência (Seção Pesquisar Ferradura)

Figura 32 – Diagrama de Sequência (Seção Cadastrar Medicação)

Figura 33 – Diagrama de Sequência (Seção Alterar Medicação)

Figura 34 – Diagrama de Sequência (Seção Apagar Medicação)

Figura 35 – Diagrama de Sequência (Seção Pesquisar Medicação)

Figura 36 – Diagrama de Sequência (Seção Marcar Aulas)

Figura 37 – Diagrama de Sequência (Seção Desmarcar Aulas)

Figura 38 – Diagrama de Sequência (Seção Relatório de Cliente)

Figura 39 – Diagrama de Sequência (Seção Relatório de Estoque)

Figura 40 – Diagrama de Sequência (Seção Relatório de Aulas por Cliente)

Figura 41 – Diagrama de Sequência (Seção Relatório de Aulas Geral)

Figura 42 – Diagrama de Sequência (Seção Relatório Boleto de Todos os Clientes)

Figura 43 – Diagrama de Sequência (Seção Relatório Boletos Individuais)

Figura 44 – Diagrama de Sequência (Seção Relatório Acompanhar Faturamento)

Figura 45 – Diagrama de Sequência (Seção Relatório Fechar Faturamento)

Figura 46 – Modelo Entidade de Relacionamento

LISTA DE TABELAS

Tabela 01 – Cliente

Tabela 02 – Cidade

Tabela 03 – Estado

Tabela 04 – Professor

Tabela 05 – Animal

Tabela 06 – Ligação Animal x Alimentação

Tabela 07 – Alimentação

Tabela 08 – Ferradura

Tabela 09 – Ligação Animal x Ferradura

Tabela 10 – Medicação

Tabela 11 – Ligação Animal x Medicação

Tabela 12 – Aulas

Tabela 13 – Tipo de Aulas

Tabela 14 – Histórico

LISTA DE SIGLAS

ANSI American National Standards Institute

DBMS Database Management System

FN Formas Normais

IBM International Business Machines

ISO International Standards Organization

IU Interface com o Usuário

LIBSYS Interface Única com uma série de Banco de Dados de Artigos

OO Orientação a Objeto

PU Processo Unificado

SGDB Sistema de Gerenciamento de Banco de Dados

SGH Sistema de Gestão de Hípica

SQL Structured Query Language

T-SQL Transact-SQL

UML Unified Modeling Language

SUMÁRIO

INTRODUÇÃO .......................................................................................................... 18

1. MOTIVAÇÃO E JUSTIFICATIVA ................................................................................. 18

1.1. Motivação ................................................................................................ 18

1.2. Justificativa .............................................................................................. 18

1.3. Objetivo ................................................................................................... 18

1.4. Abrangências e Restrições ...................................................................... 19

1.4.1. Abrangências .......................................................................................... 19

1.4.2. Restrições ............................................................................................... 19

1.5. Metodologia ............................................................................................. 19

1.6. Ambiente de Uso ..................................................................................... 20

1.7. Ferramentas Utilizadas ............................................................................ 21

REFERENCIAL TEÓRICO ............................... ........................................................ 22

2. CONTROLE ADMINISTRATIVO .............................................................................. 22

2.1. Controle de Aulas .................................................................................... 22

2.2. Controle de Estoque e de Animais .......................................................... 22

2.3. Ciclo de Vida Incremental e Interativo ..................................................... 23

2.4. UML ......................................................................................................... 23

2.5. Processo Unificado .................................................................................. 24

2.6. Casos de Uso .......................................................................................... 25

2.7. Diagrama de Classe ................................................................................ 25

2.8. Diagrama de Sequência .......................................................................... 26

2.9. Ferramentas Case ................................................................................... 26

2.9.1. Astah Professional ................................................................................... 27

2.10. Requisitos ................................................................................................ 27

2.10.1. Requisitos Funcionais ............................................................................ 28

2.10.2. Requisitos Não Funcionais ..................................................................... 28

2.10.3. Especificação de Requisitos .................................................................. 29

2.11. Arquitetura de Sistemas .......................................................................... 29

2.11.1. Arquiteturas Orientadas a Objetos ......................................................... 30

2.11.2. Arquitetura em camadas ........................................................................ 31

2.12. Arquitetura de Software ........................................................................... 31

2.13. Banco de Dados ...................................................................................... 32

2.14. Modelagem de Dados ............................................................................. 32

2.14.1. Modelo Conceitual .................................................................................. 33

2.14.2. Modelo Lógico ........................................................................................ 34

2.15. Normalização de Dados .......................................................................... 34

Primeira Forma Normal (1FN) ........................................................................ 35

Segunda Forma Normal (2FN) ....................................................................... 36

Terceira Forma Normal (3FN) ........................................................................ 37

DESENVOLVIMENTO DO SISTEMA ........................ ............................................... 39

3. REQUISITOS...................................................................................................... 39

3.1. Levantamento de Requisitos ................................................................... 39

3.2. Análise de Requisitos .............................................................................. 40

3.3. Especificação de Requisitos .................................................................... 40

3.4. Regras de Negócio .................................................................................. 41

3.4.1. Regras de Negócio para Cadastros ........................................................ 41

3.4.2. Regras de Negócio para Relatórios ........................................................ 42

3.5. Modelagem do Sistema ........................................................................... 43

3.5.1. Diagrama de Casos de Uso .................................................................... 43

3.5.2. Descrição de Casos de Uso .................................................................... 52

3.6. Diagramas de Classe .............................................................................. 84

3.6.1. Diagramas de Classes Parcial................................................................. 84

3.6.2. Diagramas de Classes Total ................................................................... 86

3.7. Diagramas de Sequência ........................................................................ 87

3.8. Arquitetura de Sistema .......................................................................... 122

3.8.1. Arquitetura Orientada a Objeto .............................................................. 122

3.8.2. Arquitetura em Camadas ....................................................................... 123

3.9. Dificuldades e Soluções Encontradas ................................................... 124

3.10. Arquitetura de Software ......................................................................... 124

3.11. Tabelas .................................................................................................. 126

CONSIDERAÇÕES FINAIS .............................. ...................................................... 133

REFERÊNCIAS ................................................................................................ 135

INTRODUÇÃO

As informações a seguir constituem uma apresentação geral das motivações

e justificativas para realização do desenvolvimento do Sistema de Gestão de Hípica,

identificando ainda, alguns dos principais objetivos que são essenciais para a

administração total deste tipo de empresa.

1. Motivação e Justificativa

1.1. Motivação

A princípio foi identificado que a empresa objeto deste estudo, não dispõe de

nenhum tipo de ferramenta capaz de auxiliar no planejamento do controle

administrativo, gerenciamento de aulas, controle de estoque e geração de relatórios,

áreas que seriam de fundamental importância a serem interligadas para um melhor

controle.

1.2. Justificativa

Devido a fatores como falta de competitividade, falta de estrutura

administrativa e, não haver no mercado softwares disponíveis para esta finalidade,

torna-se viável o desenvolvimento deste projeto do ponto de vista comercial.

1.3. Objetivo

Esse trabalho tem por objetivo desenvolver um sistema para gerenciamento

administrativo no tocante a aulas, estoque, auxiliando na tomada coerente de

decisões para a empresa.

1.4. Abrangências e Restrições

1.4.1. Abrangências

O SGH limita-se à área administrativa, gerencial, departamento de pessoal e

estoque, executando as seguintes funções:

• Controlar receitas e despesas;

• Controlar aulas e outros tipos de serviços disponibilizados pela hípica;

• Controlar cadastro de clientes;

• Controlar cadastros de animais;

• Controlar estoque;

• Controle e gerenciamento de acesso de usuários;

• Emissão de relatórios gerenciais;

• Emissão de Faturas.

1.4.2. Restrições

A princípio, nesta primeira versão, o sistema não irá atender as funções

inerentes à área de recursos humanos e controle de custos e financeiros, as quais

poderão ser incorporadas em futuras versões.

1.5. Metodologia

Para o desenvolvimento do sistema foi utilizado o modelo de desenvolvimento

de software conhecido como Processo Unificado (PU), que possui como principais

características o fato de ser um modelo direcionado a casos de uso, ser um

processo incremental e interativo e ser centrado na arquitetura do sistema.

Para apoiar o desenvolvimento desse sistema utilizou-se os conceitos de

modelagem baseados na orientação a objeto (OO), o que possibilitou uma melhor

abstração do problema abordado e do código desenvolvido. Os diagramas foram

criados seguindo padrões de UML 2.0 (Unified Modeling Language), como

linguagem de modelagem, a qual se tem tornado um padrão internacional, e que

auxiliou na definição das características do sistema.

A arquitetura do sistema foi desenvolvida em 3 camadas:

• Camada de acesso a dados; • Camada de regra de negócios; • Camada de interface;

1.6. Ambiente de Uso

A empresa poderá definir se a operação do sistema será dividida por

departamentos, ou se apenas um dos funcionários ficará a cargo do seu

gerenciamento, pois a estrutura do sistema foi projetada para funcionar como um

todo ou dividida em módulos de operações separadas.

Com a utilização do sistema dividido em módulos e por departamentos, os

dados utilizados são atualizados em tempo real, e como as principais áreas da

empresa são gerenciadas pelo sistema, o controle como um todo se torna mais fácil

e eficiente.

O sistema operacional escolhido para a utilização do sistema foi o Windows

em sua versão 7, pelo fato desse sistema operacional ser encontrado na maioria dos

computadores, bem como ser uma versão estável e com atualizações de correções

oferecidos pelo fabricante.

Com relação às configurações de hardware e software necessários para a

utilização do sistema, o equipamento aonde será instalado o sistema, não necessita

de requisitos acima da média da utilização rotineira em uma empresa, ficando

apenas a obrigatoriedade de uma impressora conectada a ela ou em rede para a

impressão dos relatórios gerados. Ficará a cargo da empresa optar pelo uso do

sistema em uma máquina isolada ou em rede.

1.7. Ferramentas Utilizadas

Para a criação dos diagramas foi utilizado o Astah, pois sua versão

Professional fornece ferramentas para a criação de diagramas com os padrões UML,

linguagem visual para especificar, construir e documentar os artefatos do sistema.

REFERENCIAL TEÓRICO

Este capítulo apresenta o referencial teórico dos principais temas estudados

no trabalho, tanto sobre o negócio, quanto das metodologias e ferramentas

utilizadas, servindo de base para os demais capítulos.

2. Controle Administrativo

Controle Administrativo é uma das funções que compõem o processo

administrativo, pois conforme destaca Oliveira (2005), controlar é comparar o

resultado das ações, com padrões previamente estabelecidos, com a finalidade de

corrigi-las, se necessário.

2.1. Controle de Aulas

O conceito de controle de aulas foi utilizado para aperfeiçoar o gerenciamento

de aulas de equitação oferecidas pela empresa objeto deste estudo, facilitando o

controle da quantidade de aulas praticadas pelos alunos, possibilitando um melhor

controle desse serviço.

2.2. Controle de Estoque e de Animais

A empresa oferece o serviço de estabulagem de animais para que o cliente

possa utilizar seu próprio animal nas aulas de equitação, e para isso, é necessário

um controle de animais e gerenciamento dos itens pertencentes a eles, itens

imprescindíveis para o bom funcionamento da empresa.

De acordo com Dias (2010), o controle de estoque é uma área muito

importante de uma empresa, seja ela de grande ou pequeno porte, pois é através

dele que ela terá a capacidade de prever compras futuras, além de fornecer

informações úteis sobre as vendas, já que muitas vezes os relatórios do setor de

vendas não são muito claros e não condizem com a realidade, afinal, o setor de

vendas quer comissões. O principal objetivo do controle de estoque é otimizar o

investimento em estoques, aumentando o uso eficiente dos meios internos de uma

empresa, e minimizar as necessidades de capital investido em estoque.

2.3. Ciclo de Vida Incremental e Interativo

De acordo com o PMBOK (2013), um projeto em negócio e ciência é

normalmente definido como um empreendimento colaborativo, frequentemente

envolvendo pesquisa ou desenho, que é cuidadosamente planejado para alcançar

um objetivo particular. Projetos podem ainda ser definidos como sistemas

sociais temporários, em vez de permanentes, que são constituídos

por equipes dentro ou entre as organizações para realizar tarefas específicas sob

restrições de tempo.

Para Bezerra (2007), o ciclo de vida incremental divide o desenvolvimento de

um projeto em ciclos. Cada ciclo de desenvolvimento pode ser identificado as fases

de análise, projeto, implementação e testes.

O sistema foi baseado neste modelo de desenvolvimento, possibilitando a

divisão do projeto em pedaços menores e incrementado de forma sequencial,

possibilitando a alteração de uma etapa anterior, caso necessário.

2.4. UML

Para o apoio no desenvolvimento do sistema foi utilizado a Linguagem de

Modelagem Unificada (UML) em sua versão 2.0, sendo a versão mais atualizada da

época do desenvolvimento deste trabalho.

Para Larman (2008), a UML é uma linguagem visual para especificar,

construir e documentar os artefatos do sistema.

A palavra visual, na sua definição, quer dizer que é um ponto chave, a UML é

a notação diagramática padrão, de fato, para desenhar ou apresentar figuras (com

algum texto) relacionadas a software.

Bezerra (2007) também define a UML como uma linguagem visual para

modelar sistemas orientados a objetos, definindo objetos gráficos que podem ser

utilizados na modelagem do sistema.

Conforme Góes (2014) a UML é a norma da indústria da informática para

descrever graficamente o software. Trata-se de uma linguagem ou notação visual

para especificação (modelagem) de sistemas de informação orientados a objetos.

Há três modos pelos quais se aplica a UML:

• Como rascunho – diagramas incompletos e informais (frequentemente

rascunhados a mão) criados para explorar partes difíceis do problema,

explorando os poderes das linguagens visuais;

• Como planta de software – diagramas de projeto relativamente

detalhados usados para engenharia reversa, para visualizar e melhor

atender o código existente em diagramas UML ou para geração de

código;

• Como linguagem de programação – especificação executável completa

de um software em UML. Código executável será automaticamente

gerado, mas não é normalmente visto ou modificado por

desenvolvedores, trabalha-se apenas na “linguagem de programação”

UML.

2.5. Processo Unificado

Processo Unificado (PU) é um processo de desenvolvimento de software que

descreve uma abordagem para a construção, implantação e, possivelmente, a

manutenção de software.

Segundo Larman (2008), o Processo Unificado surgiu como um processo

interativo popular para o desenvolvimento de software visando à construção de

sistemas orientados a objetos.

Ele define um conjunto de atividades necessárias para transformar os

requisitos do usuário em um sistema, fazendo uso da notação UML para representar

os artefatos produzidos no processo. Está centrado nos seguintes princípios:

• Dirigido por casos de uso;

• Centrado em arquitetura;

• Iterativo e incremental;

2.6. Casos de Uso

Geralmente, as aplicações incluem elementos de Interface com o Usuário

(IU), lógica central da aplicação, acesso ao banco de dados e colaboração com

componentes externos de software ou hardware.

Um caso de uso é uma coleção de cenários relacionados de sucesso e

fracasso, que descrevem um ator usando um sistema como meio para atingir um

objetivo.

A utilização de casos de uso se dá ao fato da facilidade que ele nos possibilita

de abstrair o problema e descrever as interações entre usuários e sistema, de modo

mais completo, facilitando todo o desenvolvimento do sistema.

De acordo com Larman (2008), casos de uso são narrativas em texto,

amplamente utilizadas para descobrir e registrar requisitos.

2.7. Diagrama de Classe

A partir das informações levantadas durante a obtenção de dados e

documentação de requisitos utilizando casos de uso, esta proposta sugere que seja

elaborada uma versão inicial do diagrama de classes de forma a visualizar melhor as

informações. O diagrama de classes deve ser elaborado de acordo com o padrão da

UML, realizando a modelagem estática de objetos.

Larman (2008) destaca que a UML inclui diagramas de classes para ilustrar

classes, interfaces e suas associações, representando os diferentes tipos de objetos

presentes em um sistema, bem como suas interações e métodos, facilitando a

visualização e o entendimento das classes mapeadas.

2.8. Diagrama de Sequência

O objetivo do diagrama de sequência é determinar a sequência de eventos

que ocorrem em um determinado processo, ou seja, quais condições devem ser

satisfeitas e quais métodos devem ser disparados entre os objetos envolvidos e em

que ordem durante um processo específico

A UML contém notação na forma de diagramas de sequência para ilustrar os

eventos vindos de atores externos ao sistema.

Um diagrama de sequência do sistema é um artefato criado de forma rápida e

fácil que ilustra os eventos de entrada e saída relacionados com o sistema

(LARMAN, 2008).

2.9. Ferramentas Case

Ferramentas CASE é uma classificação que abrange todas ferramentas

baseadas em computadores que auxiliam atividades de engenharia de software,

desde análise de requisitos e modelagem até programação e testes. Podem ser

consideradas como ferramentas automatizadas que tem como objetivo auxiliar o

desenvolvedor de sistemas em uma ou várias etapas do ciclo de desenvolvimento.

Para Larman (2008), muitos desenvolvedores utilizando as ferramentas CASE

que melhor se adaptem ao seu conceito de trabalho ou mesmo aquela definida

como padrão na organização em que trabalham.

2.9.1. Astah Professional

Astah, anteriormente denominado JUDE, é um software para modelagem

padrão UML. Ele é desenvolvido na plataforma Java, o que garante sua

portabilidade para qualquer plataforma que possui uma máquina virtual Java.

JUDE desenvolvimento foi iniciado por Kenji Hiranabe, CEO of Change

Vision, Inc., em 1996, na época em que UML, Java, e alguns padrões de projeto

começaram a aparecer. Ele sentiu que uma ferramenta UML radical para

desenvolvimento OO estava indo para a demanda no futuro e essa ideia o estimulou

a começar a criar JUDE. Ele reuniu engenheiros voluntários em Eiwa Management

System Inc., a empresa onde estava trabalhando no momento e desenvolveram o

sistema em seu tempo livre, JUDE foi originalmente chamado de JOMT.

JUDE foi fornecido como um software livre em 1999, cinco anos depois JUDE

começou a ser vendido no mercado japonês. Esta decisão surgiu porque algumas

ferramentas de modelagem UML existiam no exterior, porém com alto preço e, o

feedback dos usuários japoneses poderia levar a uma evolução mais rápida da

ferramenta.

O número de usuários de JUDE era de 120.000 em 30 de outubro de 2006,

Em setembro de 2009, JUDE foi renomeado para Astah, depois de receber várias

solicitações de preocupações de usuários alemães que apontaram o nome do

produto semelhante à palavra alemã Jude, que se refere a um homem judeu.

2.10. Requisitos

Requisitos são objetivos ou restrições estabelecidas por clientes e usuários

que definem as suas diversas propriedades do sistema. Os requisitos de software

são, obviamente, aqueles dentre os requisitos de sistema que dizem respeito a

propriedades do software.

Um conjunto de requisitos pode ser definido como uma condição ou

capacidade necessária que o software deve possuir para que o usuário possa

resolver um problema, atingir um objetivo, para atender as necessidades ou

restrições da organização ou dos outros componentes do sistema.

Larman (2008) afirma que requisitos são capacidades e condições às quais o

sistema e em termos mais amplos, o projeto deve atender. Tradicionalmente, os

requisitos de software são separados em requisitos funcionais e não-funcionais.

Para Sommerville (2007), os requisitos de um sistema são descrições dos

serviços fornecidos pelo sistema e suas restrições operacionais. Esses requisitos

refletem as necessidades dos clientes de um sistema que ajuda a resolver algum

problema, por exemplo, controlar um dispositivo, enviar um pedido ou encontrar

informações.

2.10.1. Requisitos Funcionais

A especificação de um requisito funcional deve determinar o que se espera

que o software faça, sem a preocupação de como ele faz. É importante diferenciar a

atividade de especificar requisitos da atividade de especificação que ocorre durante

o design do software. No design do software deve-se tomar a decisão de quais

funções o sistema efetivamente terá para satisfazer àquilo que os usuários querem.

Requisitos Funcionais possuem características, capacidade e segurança.

(LARMAN,2008).

Sommerville (2007) ressalta que requisitos funcionais são declarações de

serviços que o sistema deve fornecer, como o sistema deve reagir a entradas

específicas e como o sistema deve se comportar em determinadas situações. Em

alguns casos, os requisitos funcionais podem também estabelecer o que o sistema

não deve fazer.

2.10.2. Requisitos Não Funcionais

Requisitos não-funcionais são as qualidades globais de um software, como

manutenibilidade, usabilidade, desempenho, custos e várias outras. Normalmente,

estes requisitos são descritos de maneira informal, de maneira controversa (por

exemplo, o gerente quer segurança, mas os usuários querem facilidade de uso) e

são difíceis de validar.

Requisitos não funcionais são restrições sobre os serviços ou as funções

oferecidas pelo sistema. Eles incluem restrições de timing, restrições sobre o

processo de desenvolvimento e padrões (SOMMERVILLE, 2007).

2.10.3. Especificação de Requisitos

A especificação é a descrição sistemática e abstrata do que o software deve

fazer, a partir daquilo que foi analisado. Ela apresenta a solução de como os

problemas levantados na análise serão resolvidos pelo software do sistema

computacional. Visa descrever de maneira sistemática, quais as propriedades

funcionais são necessárias para resolver o problema do domínio. A especificação é

também a forma de comunicação sistemática com os arquitetos, programadores e

testadores do software.

A especificação dos requisitos, complementa Sommerville (2007), deve

solicitar um documento a Interface Única com uma série de Banco de Dados de

Artigos (LIBSYS), que deve ser apresentado ao solicitante um formulário que

registra os detalhes do usuário e da solicitação feita.

2.11. Arquitetura de Sistemas

A Arquitetura de sistemas de informação tem como foco principal a análise

das necessidades dos usuários dentro de um possível sistema a ser desenvolvido.

Para isto, a mesma procura não se aprofundar em detalhes tecnológicos, mas sim

se concentrar em que o cliente realmente precisa, levando em conta ainda as

características do negócio em que o mesmo está inserido.

Além disso, a Arquitetura de sistemas de informação visa a facilitar a

comunicação entre os envolvidos na concepção do sistema sem que, contudo, tenha

sido iniciada a construção do mesmo.

Em termos gerais, a Arquitetura de sistemas de informação pode ser um

instrumento de grande valia aos profissionais de TI, uma vez que fornece a estas

bases para um real entendimento das necessidades de um cliente. A fim de cumprir

este objetivo, parte-se de um enfoque em que é priorizada compreensão do modelo

de negócio em que a organização em questão está inserida e, consequentemente,

às necessidades que surgem decorrentes desta representação e que serão

ressaltadas pelos diversos usuários.

2.11.1. Arquiteturas Orientadas a Objetos

A arquitetura orientada a objetos é uma nova maneira de pensar nos

problemas através de modelos organizados em torno de conceitos do mundo real. O

funcionamento do raciocínio humano, que estrutura e classifica o mundo ao seu

redor de forma hierárquica e compartimentada, é mais "orientado a objetos" que a

relações matemáticas ou a módulos estruturados. Não há dúvida que, modelar e

projetar com orientação a objetos é fundamentalmente diferente do que com o

enfoque tradicional: requer uma maneira diferente de idealizar a decomposição, e

produz arquiteturas de software grandemente à parte da cultura de modelagem e

projeto estruturados. Os modelos e projetos orientados a objetos são mais próximos

do mundo real do que os tradicionais. Os modelos de negócio orientados a objetos

são mais facilmente construídos e compreendidos pelos profissionais das áreas de

negócio.

Arquitetura de Informação pode ser definida como o conjunto de

representações gráficas (diagramas, gráficos, modelos, matrizes, etc.) das

informações de interesse de uma organização. Objetos de negócio (processos e

procedimentos, formulários, arquivos em papel, etc.), da Arquitetura de Negócio,

serão objetos de software (programas, telas, tabelas de bases de dados, etc.).

A unidade fundamental é o objeto. Além de estrutura de dados, a construção

do objeto agrega comportamento. Podem ser ainda acrescidos regras,

conhecimento, responsabilidades, ciclo de vida. Estes elementos, apenas

fracamente conectados no enfoque tradicional, são fortemente acoplados uma vez

que são partes integrantes do objeto. Uma vez modelado, o objeto é utilizado como

uma peça que se pega na prateleira e se encaixa em um sistema, sem sofrer

modificações.

Na arquitetura de informação orientada a objetos, a OO provê embasamento

desde a fase de planejamento até a fase de construção, tanto de softwares quanto

de bases de dados.

A arquitetura orientada a objetos é baseada em várias camadas arquiteturais,

com uma camada de Interface (IU), uma camada de aplicação lógica (ou domínio),

entre outras (LARMAN, 2008)

2.11.2. Arquitetura em camadas

Estimula a organização da arquitetura do sistema em um conjunto de

camadas coesas com fraco acoplamento entre elas. Cada camada possui um

propósito bem definido.

A camada superior conhece apenas a camada imediatamente inferior (que

fornece seus serviços através de uma interface).

Cada camada é formada por um conjunto de classes com um determinado

propósito.

• Interface: agrega as classes do sistema com as quais os usuários

interagem.

• Negócio: mantém as classes do sistema responsáveis pelos serviços e

regras do negócio.

• Dados: camada responsável pelo armazenamento e recuperação dos

dados persistentes do sistema.

2.12. Arquitetura de Software

Antigamente, os projetos de sistemas alocavam pequena parcela ao software.

Os componentes de hardware, por outro lado, eram analisados e testados quase

exaustivamente, o que permitia a produção rápida de grandes quantidades de

subsistemas e implicava em raros erros de projetos. Entretanto, a facilidade de

modificar o software, comparativamente ao hardware, tem servido como motivador

para seu uso. Além disso, a intensificação do uso do software numa larga variedade

de aplicações o fez crescer em tamanho e complexidade, tornando proibitivo

analisá-lo e testá-lo exaustivamente, além de impactar no custo de manutenção.

Um reflexo dessa situação é que as técnicas de abstração utilizadas até o

final da década de 1980 (como decomposição modular, linguagens de programação

de alto nível e tipos de dados abstratos) já não são mais suficientes para lidar com

essa necessidade.

Para Larman (2008), a arquitetura de software é um conjunto de decisões

significativas sobre a organização de um sistema de software, que faz a seleção dos

elementos estruturais e suas interfaces, pelo qual o sistema é composto.

2.13. Banco de Dados

Um banco de dados (sua abreviatura é BD, em inglês DB, database) é uma

entidade na qual é possível armazenar dados de maneira estruturada e com a

menor redundância possível. Estes dados podem ser utilizados por programas e por

diferentes usuários. Assim, a noção básica de dados é acoplada geralmente a

uma rede, a fim de poder agrupar estas informações, daí o nome banco. Denota-se

de sistema de informação o termo para designar toda a estrutura que reúne os

meios organizados para compartilhamento de dados.

Banco de dados, define Oliveira (2002), é um conjunto coerente e lógico de

dados relacionados que possuem significância única. Esses dados representam

aspectos do mundo real e devem ser mantidos para atender aos requisitos da

empresa.

2.14. Modelagem de Dados

Modelagem de dados é o ato de explorar estruturas orientadas a dados.

Como outros artefatos de modelagem, modelos de dados podem ser usados para

uma variedade de propósitos, desde modelos conceituais de alto nível até modelos

físicos de dados. Do ponto de vista de um desenvolvedor atuando no paradigma

OO, modelagem de dados é conceitualmente similar à modelagem de classes.

Com a modelagem de dados, identificamos tipos de entidades da mesma

forma que na modelagem de classes são identificadas as classes. Atributos de

dados são associados a tipos de entidades exatamente como associados atributos e

operações às classes. Existem associações entre entidades, similar às associações

entre classes, relacionamento, herança, composição e agregação são todos

conceitos aplicáveis em modelagem de dados.

Atualmente, conforme destaca Oliveira (2002), a linguagem SQL (Structured

Query Language) pode ser considerada o padrão para manipulação de dados em

banco de dados. Duas entidades, ANSI (American National Standards Institute) e

ISO (International Standards Organization) vêm ao longo do tempo padronizando a

linguagem SQL. O primeiro padrão foi (SQL-86) que foi definido pela ANSI e

consistia basicamente na SQL da IBM (International Business Machines), com

poucas modificações, e em 1987, a ISO adotou o mesmo padrão. Em 1989 surgiu

uma nova versão (SQL-89) com significativas modificações, sendo a versão utilizada

pelos bancos de dados atuais, Oliveira (2002).

2.14.1. Modelo Conceitual

É uma descrição de BD de forma independente de implementação num

sistema de gerenciamento, registra que dados podem aparecer no BD, mas não

registra como estes dados estão armazenados.

Exemplo de um modelo conceitual textual:

1) Cadastro de Clientes

Dados necessários: nome completo, tipo de pessoa (física ou jurídica),

endereço, bairro, cidade, estado, telefone, e-mail, nome de contato.

2) Pedido

Dados necessários: código do produto, quantidade, código do cliente, código

do vendedor.

2.14.2. Modelo Lógico

Compreende uma descrição das estruturas que serão armazenadas no BD e

que resulta numa representação gráfica dos dados de uma maneira lógica, inclusive

nomeando os componentes e ações que exercem uns sobre os outros.

O modelo lógico também pode ser assim representado:

TipoDeProduto (CodTipoProd, DescrTipoProd)

Produto (CodProd, DescrProd, PrecoProd, CodTipoProd)

CodTipoProd referencia TipoDeProduto

2.15. Normalização de Dados

A normalização de dados consiste em definir o formato lógico adequado para

estruturas de dados identificados no projeto lógico do sistema, com o objetivo de

minimizar o espaço utilizado pelos dados e garantir a integridade e confiabilidade

das informações.

A normalização é feita através da análise dos dados que compõem as

estruturas utilizando o conceito chamado "Formas Normais (FN)". As FN são

conjuntos de restrições nos quais os dados devem satisfazê-las. Por exemplo,

pode-se dizer que a estrutura está na primeira forma normal (1FN), se os dados que

a compõem satisfizerem as restrições definidas para esta etapa.

A normalização completa dos dados é feita, seguindo as restrições das três

formas normais existentes, sendo que a passagem de uma FN para outra é feita

tendo como base o resultado obtido na etapa anterior, ou seja, na FN anterior.

Para realizar a normalização dos dados, é primordial que seja definido um

campo chave para a estrutura, campo este que permite irá identificar os demais

campos da estrutura.

A normalização de dados é uma sequência de etapas sucessivas que, ao

final, apresentará um modelo de dados estável com um mínimo de redundância,

destaca Oliveira (2002)

A seguir, descreve-se as Formas Normais existentes:

Primeira Forma Normal (1FN) - Consiste em retirar da estrutura os

elementos repetitivos, ou seja, aqueles dados que podem compor uma estrutura de

vetor. Podemos afirmar que uma estrutura está normalizada na 1FN, se não possuir

elementos repetitivos. Exemplo:

Estrutura original:

Arquivo de Notas Fiscais (Num. NF, Série, Data emissão, Cód. do Cliente,

Nome do cliente, Endereço do cliente, CGC do cliente, Relação das mercadorias

vendidas (onde para cada mercadoria temos: Código da Mercadoria, Descrição da

Mercadoria, Quantidade vendida, Preço de venda e Total da venda desta

mercadoria) e Total Geral da Nota)

Analisando a estrutura acima, observa-se a existência de várias mercadorias

em uma única Nota Fiscal, sendo, portanto elementos repetitivos que deverão ser

retirados, resultando na normalização listada a seguir:

Estrutura na primeira forma normal (1FN):

Arquivo de Notas Fiscais (Num. NF, Série, Data emissão, Código do Cliente,

Nome Cliente, Endereço do cliente, CGC do cliente e Total Geral da Nota)

Arquivo de Vendas (Num. NF, Código da Mercadoria, Descrição da

Mercadoria, Quantidade vendida, Preço de venda e Total da venda desta

mercadoria)

Obs. Os campos sublinhados identificam as chaves das estruturas.

Como resultado desta etapa ocorre um desdobramento dos dados em duas

estruturas, a saber:

- Primeira estrutura (Arquivo de Notas Fiscais): Dados que compõem a

estrutura original, excluindo os elementos repetitivos.

- Segunda estrutura (Arquivo de Vendas): Dados que compõem os

elementos repetitivos da estrutura original, tendo como chave o

campo chave da estrutura original (Num. NF) e o campo chave da

estrutura de repetição (Código da Mercadoria).

Uma entidade está na primeira forma normal quando, nenhum de seus

atributos na estrutura possuir repetições, isso significa que os atributos são

indivisíveis ou que possuem apenas um valor por célula (OLIVEIRA, 2002).

Segunda Forma Normal (2FN) - consiste em retirar das estruturas que

possuem chaves compostas (campo chave sendo formado por mais de um campo),

os elementos que são funcionalmente dependente de parte da chave. Podemos

afirmar que uma estrutura está na 2FN, se ela estiver na 1FN e não possuir campos

que são funcionalmente dependentes de parte da chave. Exemplo:

Estrutura na primeira forma normal (1FN):

Arquivo de Notas Fiscais (Num. NF, Série, Data emissão, Código do

Cliente, Nome do cliente, Endereço do cliente, CGC do cliente e Total

Geral da Nota)

Arquivo de Vendas (Num. NF, Código da Mercadoria, Descrição da

Mercadoria, Quantidade vendida, Preço de venda e Total da venda

desta mercadoria)

Estrutura na segunda forma normal (2FN):

Arquivo de Notas Fiscais (Num. NF, Série, Data emissão, Código do

Cliente, Nome do cliente, Endereço do cliente, CGC do cliente e Total

Geral da Nota)

Arquivo de Vendas (Num. NF, Código da Mercadoria, Quantidade vendida e

Total da venda desta mercadoria)

Arquivo de Mercadorias (Código da Mercadoria, Descrição da Mercadoria,

Preço de venda)

Como resultado desta etapa, houve um desdobramento do arquivo de Vendas

(o arquivo de Notas Fiscais, não foi alterado, por não possuir chave composta) em

duas estruturas, a saber:

- Primeira estrutura (Arquivo de Vendas): Contém os elementos originais,

sendo excluídos os dados que são dependentes apenas do campo

Código da Mercadoria.

- Segunda estrutura (Arquivo de Mercadorias): Contém os elementos que são

identificados apenas pelo Código da Mercadoria, ou seja,

independentemente da Nota Fiscal, a descrição e o preço de venda serão

constantes.

Uma entidade está na segunda forma normal quando todos os seus atributos

não chave, dependem unicamente da chave, assim deve-se perguntar a cada

atributo, que não seja a chave da entidade, se ele depende apenas da chave da

entidade, isso serve para medir o grau de dependência entre os atributos

(OLIVEIRA, 2002).

Terceira Forma Normal (3FN) - consiste em retirar das estruturas os campos

que são funcionalmente dependentes de outros campos que não são chaves.

Podemos afirmar que uma estrutura está na 3FN, se ela estiver na 2FN e não

possuir campos dependentes de outros campos não chaves. Exemplo:

Estrutura na segunda forma normal (2FN):

Arquivo de Notas Fiscais (Num. NF, Série, Data emissão, Código do Cliente,

Nome do cliente, Endereço do cliente, CGC do cliente e Total Geral da

Nota)




Preço de venda)

Estrutura na terceira forma normal (3FN):

Arquivo de Notas Fiscais (Num. NF, Série, Data emissão, Código do Cliente

e Total Geral da Nota)




Preço de venda)

Arquivo de Clientes (Código do Cliente, Nome do cliente, Endereço do cliente

e CGC do cliente)

Como resultado desta etapa, houve um desdobramento do arquivo de Notas

Fiscais, por ser o único que possuía campos que não eram dependentes da chave

principal (Num. NF), uma vez que independente da Nota Fiscal, o Nome, Endereço e

CGC do cliente são inalterados. Este procedimento permite evitar inconsistência nos

dados dos arquivos e economizar espaço por eliminar o armazenamento frequente e

repetidas vezes destes dados. A cada nota fiscal comprada pelo cliente, haverá o

armazenamento destes dados e poderá ocorrer divergência entre eles.

As estruturas alteradas foram pelos motivos, a saber:

- Primeira estrutura (Arquivo de Notas Fiscais): Contém os elementos

originais, sendo excluído os dados que são dependentes apenas

do campo Código do Cliente (informações referentes ao cliente).

- Segunda estrutura (Arquivo de Clientes): Contém os elementos que

são identificados apenas pelo Código do Cliente, ou seja,

independente da Nota Fiscal, o Nome, Endereço e CGC dos

clientes serão constantes.

Após a normalização, as estruturas dos dados estão projetadas para eliminar

as inconsistências e redundâncias dos dados, eliminando desta forma qualquer

problema de atualização e operacionalização do sistema. A versão final dos dados

poderá sofrer alguma alteração, para atender as necessidades específicas do

sistema, a critério do analista de desenvolvimento durante o projeto físico do

sistema.

Uma entidade está na terceira forma normal quando todos os seus atributos

não chave, não dependem de nenhum outro atributo não chave, isso quer dizer que

um atributo não deve depender de outro atributo (OLIVEIRA, 2002).

DESENVOLVIMENTO DO SISTEMA

Esse capítulo visa apresentar de forma detalhada o desenvolvimento de um sistema,

apontando os problemas e soluções encontradas, e os diagramas de UML utilizados

conforme citações.

A fundamentação teórica relativa aos tópicos relacionados a seguir foi abordada de

maneira detalhada no Referencial Teórico.

3. Requisitos

Os requisitos formam a base para o planejamento e acompanhamento de

desenvolvimento de qualquer projeto de desenvolvimento de sistema.

O processo de determinar os requisitos serve para auxiliar o entendimento das

funcionalidades necessárias para se desenvolver ou atualizar qualquer sistema ou

componente, além de proporcionar um melhor planejamento. Com este processo bem

definido pode-se obter, entender e validar as necessidades e expectativas do cliente, para

posteriormente documenta-las.

3.1. Levantamento de Requisitos

O levantamento de requisitos é a primeira providencia para o desenvolvimento de

um sistema. Entender o que o cliente deseja ou o que precisa, saber as regras e processos do

negócio, é uma importante função que faz parte da engenharia de requisitos.

Após a definição inicial do projeto, foram levantados os seguintes requisitos:

• Controle de Clientes;

• Controle de Aulas;

• Controle de Estoque;

• Emissão de Boletos;

• Relatórios Administrativos;

• Faturamento.

3.2. Análise de Requisitos

A análise de requisitos é o estudo das características que o sistema deverá possuir

para atender as expectativas e necessidades do cliente.

Cada funcionalidade solicitada pelo cliente deve ser analisada, para verificar os

possíveis impactos no desenvolvimento das demais funcionalidades do sistema. Esses

requisitos também devem ser verificados em conjunto com a equipe de desenvolvimento,

quanto as necessidades tecnológicas para a implementação e suas disponibilidades.

3.3. Especificação de Requisitos

A especificação de requisitos tem como objetivo obter produtos de software de

melhor qualidade que satisfaçam às reais necessidades dos clientes dentro de prazo e

orçamento adequados.

Podemos entender requisito como uma função, restrição ou propriedade que deve

ser fornecida, encontrada ou atendida para satisfazer às necessidades do usuário do

sistema.

Está comprovado: a maior parte dos problemas, os de maior impacto negativo e os

mais onerosos tem origem nas etapas iniciais do desenvolvimento de software. Justamente

nas etapas de especificação dos requisitos é onde as principais atividades são definidas e

onde os requisitos do produto devem ser identificados e mapeados com objetividade e

clareza.

Podemos dizer que as principais causas para o fracasso dos projetos de software são:

especificação de requisitos mal formulada e alterações constantes nos requisitos.

Por serem atividades bases do processo de desenvolvimento de software as falhas

cometidas nas atividades de definição e validação de requisitos irão originar documentos de

requisitos inconsistentes afetando as etapas seguintes de projeto, implementação e testes e

gerando produtos de softwares de baixa qualidade.

3.4. Regras de Negócio

Regras de Negócio representam o alicerce sobre o qual serão definidos os processos

de negócio, elas podem ser transformadas em requisitos, que por sua vez, podem ser

implementadas em sistemas de informação que apoiam atividades da organização. Uma

abordagem integrada entre políticas, regras, processos, requisitos e sistemas de informação

garantem uma atuação eficaz, alinhada com compromissos éticos e sociais, obrigações

contratuais, decisões estratégicas, leis e regulamentações, entre outros.

3.4.1. Regras de Negócio para Cadastros

Cadastro de Clientes – O sistema deve exibir um formulário onde o atendente

informará o nome do cliente, endereço, RG, CPF e outros dados pessoais, até o

preenchimento total para a inclusão dos dados do cliente. O formulário também deve

conter opções de pesquisa, alteração e exclusão de informações do cadastro.

Cadastro de Professores – O sistema deve exibir um formulário onde o atendente

informará o nome do professor, endereço, RG, CPF e outros dados pessoais, até o

preenchimento total para a inclusão dos dados do professor. O formulário também deverá

conter as opções de pesquisa, alteração e exclusão de informações do cadastro.

Cadastro de Animais – O sistema deve exibir um formulário onde o atendente

informará o nome do animal, código do cliente. O formulário também deverá conter as

opções de pesquisa, alteração e exclusão de informações do cadastro.

Cadastro de Alimentação – O sistema deve exibir um formulário onde o atendente

informará o código da alimentação, a quantidade de porção, nome da alimentação,

quantidade mínima para cada animal, quantidade máxima para cada animal, quantidade

atual do estoque, preço de compra e preço de venda. O formulário também deverá conter

as opções de pesquisa, alteração e exclusão de informações do cadastro.

Cadastro de Ferraduras – O sistema deve exibir um formulário onde o atendente

informará o código da ferradura, o tipo da ferradura, nome da ferradura, quantidade mínima

para cada animal, quantidade máxima para cada animal, quantidade atual do estoque, preço

de compra e preço de venda. O formulário também deverá conter as opções de pesquisa,

alteração e exclusão de informações do cadastro.

Cadastro de Medicamentos – O sistema deve exibir um formulário onde o atendente

informará o código do medicamento, a quantidade de doses, nome do medicamento,

quantidade mínima para cada animal, quantidade máxima para cada animal, quantidade

atual do estoque, preço de compra e preço de venda. O formulário também deverá conter

as opções de pesquisa, alteração e exclusão de informações do cadastro.

Cadastro de Tipos de Aula – O sistema deve exibir um formulário onde o atendente

informará o código da aula, a descrição das aulas, bem como, o preço das aulas. O

formulário também deverá conter as opções de pesquisa, alteração e exclusão de

informações do cadastro.

Cadastro de Aulas – O sistema deve exibir um formulário onde o atendente

informará o código do professor, o código do cliente, o código da aula e data de aula. O

formulário também deverá conter as opções de pesquisa, alteração e exclusão de

informações do cadastro.

3.4.2. Regras de Negócio para Emissão de Relatórios

Relatório Administrativo e Gerencial – O sistema deve exibir uma relação dos

relatórios disponíveis. O atendente ou o gerente deve informar qual o tipo de relatório

desejado, conforme opções a seguir:

• Relatórios Administrativos:

o Relatório de Cliente;

o Relatório de Aulas por Cliente;

o Relatório de Estoque;

o Relatório de Boletos por Clientes;

o Relatório de Todos os Boletos Emitidos;

• Relatórios Gerenciais:

o Relatório de Aulas Gerais;

o Relatório de Acompanhamento de Faturamento;

o Relatório de Fechar Faturamento.

3.5. Modelagem do Sistema

A metodologia adotada para a modelagem do sistema constitui no levantamento dos

requisitos do SGH. O processo de modelagem limita-se as etapas de análise e projeto do

sistema utilizando a UML. Este tópico apresenta de forma ilustrada todo o processo de

desenvolvimento através dos diagramas de casos de uso, diagramas de classe e diagramas

de sequência.

3.5.1. Diagrama de Casos de Uso

Os diagramas a seguir são compostos por todos os casos de uso, o que possibilita

identificar de maneira geral a influência externa dos atores para utilização de uma ou mais

funcionalidades do sistema.

Figura 01 – Diagrama de Casos de Uso (Sistema de Gerenciamento de Hípicas)

Fonte: Elaborado pelos autores.

Figura 02 – Seções do Sistema (Manter Cliente)


Figura 03 – Seções do Sistema (Manter Professor)


Figura 04 – Seções do Sistema (Manter Animal)


Figura 05 – Seções do Sistema (Manter Alimentação)


Figura 06 – Seções do Sistema (Manter Ferradura)


Figura 07 – Seções do Sistema (Manter Medicação)


Figura 08 – Seções do Sistema (Manter Aulas)


Figura 09 – Seções do Sistema (Manter Relatórios)


3.5.2. Descrição de Casos de Uso

As descrições dos casos de uso estão compostas pelos seguintes elementos:

• Título do Caso de Uso;

• Visão Geral;

• Atores que participam do Caso de Uso;

• Finalidade.

Caso de uso: Manter Cliente Visão Geral: O ator define a opção desejada. Ator: Atendente. Finalidade: Apresentar para o ator as opções para o cliente. Caso de uso: Manter Cliente

Ator Sistema Classe

1- O caso de uso começa quando o ator escolhe a opção cliente: a- Se escolher a

opção cadastrar, ver seção Cadastrar Cliente.

b- Se escolher a opção alterar, ver seção Alterar Cliente.

c- Se escolher a opção Apagar, ver a opção Apagar Cliente.

d- Se escolher a opção pesquisar, ver seção Pesquisar Cliente

Caso de uso: Seção Cadastrar Cliente. Visão Geral: O ator insere os dados do cliente e o sistema salva no BD. Ator: Atendente. Finalidade: Cadastrar um novo cliente Seção Cadastrar Clientes

Ator Sistema Classe

1- Apresenta formulário para inserir os dados do cliente.

2- Digita os dados.

3- Valida os dados digitados Include(Validar Dados) .

4- Solicita armazenar no BD.

5- Autoriza o armazenamento.

6- Salva no BD. Cliente

Inclusão (Validar Dados)

Ator Sistema Classe

1- Valida os dados digitados

Sequencia Alternativa

1.1- Apresenta mensagem de erro: “Dados inválidos”.

Caso de uso: Seção Alterar Cliente Visão Geral: O ator altera os dados de um cliente. Ator: Atendente. Finalidade: Alterar os dados de um cliente cadastrado. Seção Alterar Cliente.

Ator Sistema Classe

1- Solicita o código do cliente.

2- Informa o código

3- Validar o código. Include (Validar CodCliente)

Cliente

4- Obtém dados do cliente Cliente

5- Apresenta o formulário com os dados do cliente.

6- Altera os dados.

7- Valida os dados digitados. Include (Validar Dados) .



10- Salva no BD Cliente

Inclusão (Validar CodCliente)

Ator Sistema Classe

1- Validar código Cliente

Sequência alternativa

1.1- Apresenta Mensagem de erro: “Código inválido”

Caso de uso: Seção Apagar Cliente Visão Geral: O ator desabilita os dados de um cliente. Ator: Atendente. Finalidade: Marcar um cliente como inativo pra não ser visualizado pelo ator. Seção Apagar Cliente.

Ator Sistema Classe




Cliente

4- Obtém dados do cliente Cliente

5- Apresenta o formulário com os dados do cliente.

6- Confirma exclusão.

7- Marca o cliente como inativo.

Cliente

Caso de uso: Manter Professor. Visão Geral: O ator define a opção desejada. Ator: Atendente. Finalidade: Apresentar para o ator as opções para os professores. Caso de uso: Manter Professor.

Ator Sistema Classe.

1- O caso de uso começa quando o ator escolhe a opção Professor: a- Se escolher a

opção cadastro, ver seção Cadastrar Professor.

b- Se escolher a opção alterar, ver seção Alterar Professor .

c- Se escolher a opção apagar, ver a seção Apagar Professor .

d- Se escolher a opção Pesquisar, ver seção Pesquisar Professor.

Caso de uso: Seção Cadastrar Professor Visão Geral: O ator insere os dados do professor e o sistema salva no BD. Ator: Atendente. Finalidade: Cadastrar um novo professor. Seção Cadastrar Professor

Ator Sistema Classe

1- Apresenta formulário para inserir os dados do professor.

2- Digita os dados.




6- Salva no BD. Professor

Caso de uso: Seção Alterar Professor. Visão Geral: O ator altera os dados de um professor. Ator: Atendente. Finalidade: Alterar os dados de um professor cadastrado. Seção Alterar Dados dos Professores.

Ator Sistema Classe

1- Solicita o código do Professor.


3- Validar o código. Include (Validar Professor)

Professor

4- Obtém dados do professor.

Professor

5- Apresenta o formulário com os dados do professor.

6- Altera os dados.

7- Valida os dados digitados. Include (Validar Dados) .



10- Salva no BD Professor

Inclusão (Validar Professor)

Ator Sistema Classe

1- Valida código Professor


1.1- Apresenta Mensagem de erro: “Professor não cadastrado”

Caso de uso: Seção Apagar Professor Visão Geral: O ator desabilita os dados de um professor. Ator: Atendente. Finalidade: Marcar um professor como inativo pra não ser visualizado pelo ator. Seção Apagar Professor

Ator Sistema Classe

1- Solicita o código do professor.



Professor

4- Obtém dados do professor

Professor

5- Apresenta o formulário com os dados do

professor. 6- Confirma exclusão.

7- Marca o professor como inativo.

Professor

Caso de uso: Seção Pesquisar Professor Visão Geral: O ator pesquisa os dados de um professor. Ator: Atendente. Finalidade: Pesquisar os dados de um professor cadastrado. Seção Pesquisar Professor.

Ator Sistema Classe

1- Solicita o código do professor.



Professor

4- Obtém dados do professor.

Professor

5- Apresenta o formulário com os dados do professor.

Caso de uso: Manter Animal. Visão Geral: O ator define a opção desejada. Ator: Atendente. Finalidade: Apresentar para o ator as opções para os animais. Caso de uso: Manter Animal.

Ator Sistema Classe.

2- O caso de uso começa quando o ator escolhe a opção Animal: e- Se escolher a

opção cadastro, ver seção Cadastrar Animal.

f- Se escolher a opção alterar, ver seção Alterar Animal .

g- Se escolher a opção apagar, ver a seção Apagar Animal .

h- Se escolher a opção Pesquisar, ver seção Pesquisar Animal.

Caso de uso: Seção Cadastrar Animal Visão Geral: O ator insere os dados dos animais e o sistema salva no BD. Ator: Atendente. Finalidade: Cadastrar um novo animal. Seção Cadastrar Animal.

Ator Sistema Classe

1- Apresenta formulário para inserir os dados do animal.

2- Digita os dados.




6- Salva no BD. Animal

Caso de uso: Seção Alterar Animal Visão Geral: O ator altera os dados de um animal. Ator: Atendente. Finalidade: Alterar os dados de um animal cadastrado. Seção Alterar Animal

Ator Sistema Classe

1- Solicita o código do dono do animal.



Cliente

4- Obtém dados dos animais

Animal

5- Apresenta o formulário com os dados dos animais.

6- Altera os dados.




10- Salva no BD Animal

Caso de uso: Seção Apagar Animal Visão Geral: O ator desabilita os dados de um animal cadastrado. Ator: Atendente. Finalidade: Marcar um animal como inativo pra não ser visualizado pelo ator. Seção Apagar Animal

Ator Sistema Classe



11- Validar o código Include (Validar CodCliente)

Cliente

3- Obtém dados do animal Animal

4- Apresenta o formulário com os dados do animal.


6- Marca o animal como inativo.

Animal

Caso de uso: Seção Pesquisar Animal Visão Geral: O ator pesquisa os dados de um animal. Ator: Atendente. Finalidade: Pesquisar os dados de um animal cadastrado. Seção Pesquisar Professor.

Ator Sistema Classe




Cliente

4- Obtém dados do animal.

Animal

5- Apresenta o formulário com os dados do animal.

Caso de uso: Manter Alimentação Visão Geral: O ator define a opção desejada. Ator: Atendente. Finalidade: Apresentar para o ator as opções para Alimentação. Caso de uso: Manter Alimentação

Ator Sistema Classe

2- O caso de uso começa quando o ator escolhe a opção produto: e- Se escolher a

opção cadastrar, ver seção Cadastrar Alimentação.

f- Se escolher a opção alterar, ver seção Alterar Alimentação.

g- Se escolher a opção Apagar, ver a opção Apagar Alimentação.

h- Se escolher a opção pesquisar, ver seção Pesquisar Alimentação.

Caso de uso: Seção Cadastrar Alimentação Visão Geral: O ator insere os dados do alimento e o sistema salva no BD. Ator: Atendente. Finalidade: Cadastrar um novo alimento. Seção Cadastrar Alimentação.

Ator Sistema Classe

1- Apresenta formulário para inserir os dados do produto.

2- Digita os dados.




6- Salva no BD. Alimentacao

Caso de uso: Seção Alterar Alimentação. Visão Geral: O ator altera os dados de um alimento. Ator: Atendente. Finalidade: Alterar os dados de um alimento cadastrado. Seção Alterar Alimentação

Ator Sistema Classe

1- Solicita o código do alimento.

2- Informa o código.

3- Valida o código. Include(Validar Alimento)

Alimentacao

4- Obtém dados do produto.

Alimentacao

5- Apresenta o formulário com os dados do alimento.

6- Altera os dados.




10- Salva no BD Alimentacao

Inclusão (Validar Alimento)

Ator Sistema Classe

1- Valida o código do alimento

Alimentacao


1.2- Apresenta Mensagem de erro: “Alimento não encontrado”

Caso de uso: Seção Apagar Alimentação Visão Geral: O ator desabilita os dados de um alimento cadastrado. Ator: Atendente. Finalidade: Marcar um alimento como inativo pra não ser visualizado pelo ator. Seção Apagar Alimentação

Ator Sistema Classe



3- Validar o código. Include (Validar

Alimentacao

Alimento) 4- Obtém dados do

alimento. Alimentacao



7- Marca o alimento como inativo.

Alimentacao

Caso de uso: Seção Pesquisar Alimentação Visão Geral: O ator pesquisa os dados de um alimento. Ator: Atendente. Finalidade: Pesquisar os dados de um alimento cadastrado. Seção Pesquisar Alimentação

Ator Sistema Classe



3- Validar o código. Include (Validar Alimento)

Alimentacao

4- Obtém dados do alimento.

Alimentacao


Caso de uso: Manter Ferradura Visão Geral: O ator define a opção desejada. Ator: Atendente. Finalidade: Apresentar para o ator as opções para ferradura. Caso de uso: Manter Ferradura

Ator Sistema Classe

1- O caso de uso começa quando o ator escolhe a opção ferradura: a- Se escolher a

opção cadastrar, ver seção Cadastrar Ferradura.

b- Se escolher a opção alterar, ver seção Alterar Ferradura.

c- Se escolher a opção Apagar, ver a opção Apagar Ferradura.

d- Se escolher a opção pesquisar, ver seção Pesquisar Ferradura.

Caso de uso: Seção Cadastrar Ferradura Visão Geral: O ator insere os dados da ferradura e o sistema salva no BD. Ator: Atendente. Finalidade: Cadastrar uma nova ferradura Seção Cadastrar Ferradura

Ator Sistema Classe

1- Apresenta formulário para inserir os dados da Ferradura.

2- Digita os dados.




6- Salva no BD. Ferradura

Caso de uso: Seção Alterar Ferradura. Visão Geral: O ator altera os dados de um produto. Ator: Atendente. Finalidade: Alterar os dados de um produto cadastrado. Seção Alterar Dados dos Produtos

Ator Sistema Classe

1- Solicita o código do produto.


3- Valida o código. Include(Validar Ferradura)

Ferradura

4- Obtém dados da ferradura.

Ferradura

5- Apresenta o formulário com os dados da ferradura.

6- Altera os dados.




10- Salva no BD Ferradura.

Inclusão (Validar Ferradura)

Ator Sistema Classe

1- Valida o código da ferradura

Ferradura


1.3- Apresenta Mensagem de erro: “Ferradura não encontrada”

Caso de uso: Seção Apagar Ferradura Visão Geral: O ator desabilita os dados de uma ferradura cadastrada. Ator: Atendente. Finalidade: Marcar uma ferradura como inativa pra não ser visualizado pelo ator. Seção Apagar Ferradura

Ator Sistema Classe

1- Solicita o código da ferradura.


3- Validar o código. Include (Validar Ferradura)

Ferradura

4- Obtém dados da ferradura

Ferradura



7- Marca a ferradura como inativa.

Ferradura

Caso de uso: Seção Pesquisar Ferradura Visão Geral: O ator pesquisa os dados de uma ferradura. Ator: Atendente. Finalidade: Pesquisar os dados de uma ferradura cadastrada. Seção Pesquisar Ferradura

Ator Sistema Classe

1- Solicita o código da Ferradura.


3- Validar o código. Include (Validar Ferradura)

Ferradura

4- Obtém dados da ferradura.

Ferradura


Caso de uso: Manter Medicação Visão Geral: O ator define a opção desejada. Ator: Atendente. Finalidade: Apresentar para o ator as opções para medicação. Caso de uso: Manter Medicação

Ator Sistema Classe

1- O caso de uso começa quando o ator escolhe a opção produto: a- Se escolher a

opção cadastrar, ver seção Cadastrar Medicação.

b- Se escolher a opção alterar, ver seção Alterar Medicação

c- Se escolher a opção Apagar, ver a opção Apagar Medicação

d- Se escolher a opção pesquisar, ver seção Pesquisar Medicação.

Caso de uso: Seção Cadastrar Medicação Visão Geral: O ator insere os dados da medicação e o sistema salva no BD. Ator: Atendente. Finalidade: Cadastrar uma nova medicação. Seção Cadastrar Medicação.

Ator Sistema Classe

1- Apresenta formulário para inserir os dados do produto.

2- Digita os dados.




6- Salva no BD. Medicacao

Caso de uso: Seção Alterar Medicação Visão Geral: O ator altera os dados de uma medicação cadastrada. Ator: Atendente. Finalidade: Alterar os dados de uma medicação cadastrada. Seção Alterar Dados Medicação.

Ator Sistema Classe

1- Solicita o código da medicação.


3- Valida o código. Include(Validar Medicação)

Medicacao

4- Obtém dados da medicação.

Medicacao

5- Apresenta o formulário com os dados da medicação.

6- Altera os dados.




10- Salva no BD Medicacao

Inclusão (Validar Medicação)

Ator Sistema Classe

1- Valida o código do produto

Medicacao


1.4- Apresenta Mensagem de erro: “Medicação não encontrada”

Caso de uso: Seção Apagar Medicação Visão Geral: O ator desabilita os dados de uma medicação cadastrada. Ator: Atendente. Finalidade: Marcar uma medicação como inativa pra não ser visualizada pelo ator. Seção Apagar Medicação

Ator Sistema Classe

1- Solicita o código da medicação


3- Validar o código. Include (Validar Medicação)

Medicacao

4- Obtém dados da medicação

Medicacao



7- Marca a medicação como inativa.

Medicacao

Caso de uso: Seção Pesquisar Medicação Visão Geral: O ator pesquisa os dados de uma medicação. Ator: Atendente. Finalidade: Pesquisar os dados de uma medicação cadastrada. Seção Pesquisar Medicação

Ator Sistema Classe

1- Solicita o código da medicação.


3- Validar o código. Include (Validar Medicação)

Medicação

4- Obtém dados da medicação

Medicação


Caso de uso: Manter Aulas Visão Geral: O ator define a opção desejada. Ator: Atendente. Finalidade: Apresentar para o ator as opções para marcar/desmarcar aulas. Caso de uso: Manter Aulas

Ator Sistema Classe

1- O caso de uso começa quando o ator escolhe a opção Aulas: a- Se escolher a

opção Marcar aulas, ver seção Marcar Aula.

b- Se escolher a opção Desmarcar aula, ver seção Desmarcar Aula.

Caso de uso: Seção Marcar Aula. Visão Geral: O ator marca as aulas e o sistema salva no BD. Ator: Atendente. Finalidade: Marcar uma aula para o cliente. Seção Marcar Aula.

Ator Sistema Classe




Cliente

4- Solicita escolher um professor.

5- Escolhe o professor

6- Valida o professor. Include (Validar Professor)

Professor

7- Obtém dados das aulas. Aulas

8- Apresenta formulário com horários.

9- Seleciona horário.

10- Validar horário. Include (Validar Horário)


12- Autoriza Armazenamento.

13- Salva no BD. Aulas

Inclusão (Validar Horário)

Ator Sistema Classe

1- Validar horário


1.1- Apresenta mensagem de erro: ”Horário indisponível”.

Caso de uso: Seção Desmarcar Aula. Visão Geral: O ator desmarca uma aula agendada pelo sistema. Ator: Atendente. Finalidade: Desmarcar uma aula agendada. Seção Desmarcar Aula.

Ator Sistema Classe



3- Valida o código. Include (Validar CodCliente)

Cliente

4- Solicita qual professor responsável pela aula.

5- Informa o professor

6- Valida o professor. Include (Validar Professor)

Professor

7- Obtém dados das aulas. Aulas

8- Apresenta formulário com horários.

9- Seleciona horário.

10- Validar horário. Include (Validar Horário)


12- Autoriza Armazenamento.

13- Salva no BD. Aulas

Caso de uso: Manter Relatórios Visão Geral: O ator define a opção desejada. Ator: Atendente. Finalidade: Apresentar para o ator as opções de relatórios gerados pelo sistema. Caso de uso: Manter Relatórios

Ator Sistema Classe

1- O caso de uso começa quando o ator escolhe a opção Relatórios a- Se escolher a opção

Cliente, ver seção Relatório/Cliente.

b- Se escolher a opção Estoque, ver a seção Relatório/Estoque.

c- Se escolher a opção Aulas/cliente, ver seção Relatório/Aulas_Cliente.

d- Se escolher a opção Aulas/Geral, ver a seção Relatório/Aulas_Geral.

e- Se escolher a opção Gerar Todos os Boletos, ver a seção Relatório/ Boletos Todos Clientes

f- Se escolher a opção Gerar Boletos Individuais, ver a seção Relatório/Boletos Individuais

g- Se escolher a opção Acompanhar Faturamento, ver seção Relatório/Acompanhar Faturamento.

h- Se escolher a opção Fechar Faturamento, ver seção Relatório/Fechar Faturamento.

Caso de uso: Seção Relatório/Cliente. Visão Geral: O ator define um mês para gerar um relatório do cliente. Ator: Atendente. Finalidade: Gerar o relatório de gastos de um cliente em um mês específico. Seção Relatório/Cliente

Ator Sistema Classe

1- Solicita o código


3- Valida o código. Include(Validar CodCliente)

Cliente

4- Solicita o mês

5- Informa o mês

6- Validar o mês. Include (Validar Mês)

7- Obtém os dados do cliente.

Cliente

8- Obtém os dados dos animais.

Animal

9- Obtém os dados das aulas

Aulas

10- Obter valor da aula TipoAula

11- Calcula o valor das aulas.

12- Calcula o valor dos gastos com os animais.

13- Calcula o custo total.

14- Gera o Relatório.

15- Apresenta relatório.

Inclusão (Validar Mês)

Ator Sistema Classe

1- Validar mês

Sequência Alternativa

1.1- Apresenta mensagem de erro: “Mês inválido”.

Caso de uso: Seção Relatório/Estoque. Visão Geral: O ator escolhe a opção estoque. Ator: Atendente. Finalidade: Gera relatório do estado atual do estoque de produtos.

Seção Relatório/Estoque

Ator Sistema Classe

1- Obtém dados dos alimentos.

Alimentacao

2- Obtém dados das ferraduras

Ferradura

3- Obtém dados das medicações.

Medicacao

4- Gera relatório.


Caso de uso: Seção Relatório/Aulas Cliente. Visão Geral: O ator define um período para gerar o relatório das aulas de um cliente. Ator: Atendente. Finalidade: Gera relatório das aulas de um cliente em um período específico. Seção Relatório/Aulas Cliente

Ator Sistema Classe

1- Solicita código.


3- Valida o código. Include (Validar CodCliente )

Cliente

4- Solicita período do relatório

5- Informa período

6- Validar período. Include (Validar Período)

7- Obtém dados das aulas do cliente.

Aulas

8- Obter o valor da aula TipoAula

9- Calcula valor das aulas.

10- Gera relatório


Include (Validar Período)

Ator Sistema Classe

1- Validar Período


1.1- Apresenta mensagem de erro: “Período inválido”.

Caso de uso: Seção Relatório/Aulas Geral. Visão Geral: O ator define um período para gerar o relatório das aulas. Ator: Gerente. Finalidade: Gera relatório de todas as aulas no período especificado. Seção Relatório/Aulas Geral

Ator Sistema Classe

1- Solicita período.

2- Informa período.

3- Valida período. Include (Validar Período)

4- Obtém os dados de todas as aulas.

Aulas

5- Obtém o valor da aula TipoAula


7- Gera o relatório.


Caso de uso: Seção Relatório/ Boletos Todos Clientes. Visão Geral: O ator define o mês para gerar os boletos. Ator: Atendente. Finalidade: Gera boletos individuais de todos os clientes do mês escolhido. Seção relatório/ Boletos Todos Clientes.

Ator Sistema Classe

1- Solicita mês.

2- Informa o mês.

3- Validar o mês. Include (Validar Mês)

4- Obtém dados dos clientes.

Clientes

5- Obtém dados dos animais.

Animal


7- Calcula valor das aulas.

8- Calcula valor dos gastos dos animais.

9- Calcula o valor total.

10- Gera boletos individuais com os gastos de todos os clientes.

Caso de uso: Seção Relatório/ Boletos Individuais. Visão Geral: O ator define o mês para gerar o boleto de um cliente. Ator: Atendente. Finalidade: Gera um boleto individual de um cliente do mês especificado. Seção: Seção Relatório/ Boletos Individuais

Ator Sistema Classe

1- Solicita código do cliente

2- Informa código.

3- Valida código. Include (Validar CodCliente)

Cliente

4- Solicita o mês

5- Informa o mês

6- Valida o mês. Include (Validar Mês)

7- Obtém os dados do Cliente

cliente 8- Obtém os dados dos

animais do cliente Animal


10- Calcula o valor das aulas

11- Calcula o valor gasto com os animais

12- Calcula o valor total

13- Gera o boleto do cliente

Caso de uso: Seção Relatório/Acompanhar Faturamento. Visão Geral: Define um período para gerar o relatório de faturamento. Ator: Gerente. Finalidade: Gera um relatório com o faturamento da empresa no período especificado. Seção Relatório/Acompanhar Faturamento

Ator Sistema Classe

1- Solicita o período

2- Informa o período

3- Validar o período. Include (Validar Período)

4- Obtém dados das aulas dos clientes.

Aulas

5- Obtém dados dos gastos dos animais dos clientes.

Animal

6- Obtém valor da aula TipoAula


8- Calcula o valor obtido com os animais.

9- Calcula o valor total.

10- Gera o relatório de faturamento.


Caso de uso: Seção Relatório/ Fechar Faturamento. Visão Geral: O ator define o mês para o fechamento do faturamento. Ator: Gerente. Finalidade: Gera o faturamento do mês especificado. Caso de uso: Seção Relatório/ Fechar Faturamento

Ator Sistema Classe

1- O caso de uso começa quando o ator escolhe a opção Fechar Faturamento.

2- Solicita o mês de fechamento.

3- Informa o mês

4- Valida o mês. Include (Validar Mês)

5- Obtém os dados dos clientes

Cliente

6- Obtém os dados dos animais dos clientes

Animal

7- Obtém os dados de todas as aulas do mês

Aulas

8- Obtém valor da aula TipoAula

9- Calcula o valor das aulas

10- Calcula o valor dos gastos com os animais

11- Calcula o custo total

12- Gera o faturamento

13- Salva os dados em um histórico

Histórico

14- Apresenta faturamento.

3.6. Diagramas de Classe

Um sistema projetado e desenvolvido com a metodologia OO, em geral, possui

três tipos de classes:

o Classes de Interface;

o Classes Internas;

o Classes de Acesso a Dados;

As classes de interface são responsáveis pela interação com os usuários. Elas

recebem os eventos do usuário e solicitam para as classes internas para executarem o

que foi solicitado.

Os serviços a serem executados pelas classes internas são descritos pelos casos de

uso, essas descrições são importantes no processo de identificação das classes internas

do sistema que passarão os resultados a um evento externo.

3.6.1. Diagramas de Classes Parcial

No diagrama de classe parcial as classes (figura 10) estão sem os seus métodos,

onde serão definidas quando forem definidas as visões dinâmicas do sistema.

Nestas condições o sistema possui o seguinte diagrama de classes:

Figura 10 – Diagrama de Classes Parcial

Fonte: Elaborado pelos Autores.

3.6.2. Diagramas de Classes Total

No diagrama de classe total, conforme figura 11, as classes estão com os seus

métodos e atributos:

Figura 11 – Diagrama de Classes Total


3.7. Diagramas de Sequência

Os diagramas de sequência (figura 12) mostram o comportamento de um único

cenário. As informações para a criação dos diagramas de sequência, são retirados dos

diagramas de caso de uso, para cada caso de uso é gerado um diagrama de sequência,

que mostrará a sequência que serão executadas as ações.

Podemos afirmar que o ator fará a interação com o sistema, onde o objeto

receberá ou executará uma ação, e as mensagens serão transmitidas de um objeto para

outro de acordo com a sequência de execução.

Figura 12 – Diagrama de Sequência (Seção Cadastrar Cliente)


Figura 13 – Diagrama de Sequência (Seção Alterar Cliente)


Figura 14 – Diagrama de Sequência (Seção Apagar Cliente)


Figura 15 – Diagrama de Sequência (Seção Pesquisar Cliente)

Figura 16 – Diagrama de Sequência (Seção Cadastrar Professor)


Figura 17 – Diagrama de Sequência (Seção Alterar Professor)


Figura 18 – Diagrama de Sequência (Seção Apagar Professor)


Figura 19 – Diagrama de Sequência (Seção Pesquisar Professor)


Figura 20 – Diagrama de Sequência (Seção Cadastrar Animal)


Figura 21 – Diagrama de Sequência (Seção Alterar Animal)


Figura 22 – Diagrama de Sequência (Seção Apagar Animal)


Figura 23 – Diagrama de Sequência (Seção Pesquisar Animal)


Figura 24 – Diagrama de Sequência (Seção Cadastrar Alimentação)


Figura 25 – Diagrama de Sequência (Seção Alterar Alimentação)


Figura 26 – Diagrama de Sequência (Seção Apagar Alimentação)


Figura 27 – Diagrama de Sequência (Seção Pesquisar Alimentação)


Figura 28 – Diagrama de Sequência (Seção Cadastrar Ferradura)


Figura 29 – Diagrama de Sequência (Seção Alterar Ferradura)


Figura 30 – Diagrama de Sequência (Seção Apagar Ferradura)


Figura 31 – Diagrama de Sequência (Seção Pesquisar Ferradura)


Figura 32 – Diagrama de Sequência (Seção Cadastrar Medicação)


Figura 33 – Diagrama de Sequência (Seção Alterar Medicação)


Figura 34 – Diagrama de Sequência (Seção Apagar Medicação)


Figura 35 – Diagrama de Sequência (Seção Pesquisar Medicação)


Figura 36 – Diagrama de Sequência (Seção Marcar Aulas)


Figura 37 – Diagrama de Sequência (Seção Desmarcar Aulas)


Figura 38 – Diagrama de Sequência (Seção Relatório de Cliente)


Figura 39 – Diagrama de Sequência (Seção Relatório de Estoque)


Figura 40 – Diagrama de Sequência (Seção Relatório de Aulas por Cliente)


Figura 41 – Diagrama de Sequência (Seção Relatório de Aulas Geral)


Figura 42 – Diagrama de Sequência (Seção Relatório Boleto de Todos os Clientes)


Figura 43 – Diagrama de Sequência (Seção Relatório Boletos Individuais)


Figura 44 – Diagrama de Sequência (Seção Relatório Acompanhar Faturamento)


Figura 45 – Diagrama de Sequência (Seção Relatório Fechar Faturamento)


3.8. Arquitetura de Sistema

O projeto de arquitetura de sistema foi a primeira etapa e teve como objetivo

representar os vínculos entre os processos de engenharia de requisitos e o projeto. Uma

das principais vantagens nesta arquitetura está na possibilidade de reutiliza-la no

desenvolvimento de sistemas que apresentam requisitos similares, dessa maneira

fornece a possibilidade ao reuso do sistema em grande escala. O desenvolvimento do

projeto passou por três etapas que são comuns a todos os processos de projeto de

arquitetura:

1. Estruturação do sistema: Efetuada a análise e definição dos requisitos

funcionais, como as abrangências e restrições, foram realizadas a estruturação

do sistema em subsistemas, de forma a dividi-los em unidades de sistemas

independentes.

2. Modelagem de controle: Em seguida foram estabelecidos de um modo geral

os relacionamentos de controle entre as partes do sistema.

3. Composição modular: Após a arquitetura estrutural ter sido projetada, o

próximo passo foi a divisão dos subsistemas em módulos.

O projeto de arquitetura teve como base dois modelos específicos de arquitetura:

Arquitetura Orientada a Objetos e Arquitetura em Camadas.

3.8.1. Arquitetura Orientada a Objeto

O sistema foi composto em um conjunto de objetos instanciados por classes que

se comunicam através de chamadas de funções. Os componentes de um sistema

encapsulam os dados e as operações que devem ser aplicadas para serem manipuladas.

Cada classe serve de modelo para um determinado aspecto da realidade. As classes por

sua vez são especificadas de acordo com a relação de dependência com outras classes

além de serem projetadas de forma hierárquica utilizando dependências de herança e

utilização.

3.8.2. Arquitetura em Camadas

A arquitetura em camadas surgiu com o objetivo de separar a interface com o

usuário, a lógica de negócios e o acesso ao banco de dados, possibilitando vários usuários

interagirem com o sistema sem ter a necessidade de instalar o sistema em suas

máquinas, tornando mais flexível o sistema, possibilitando que cada camada seja

acessada e modificada individualmente, sem a necessidade de modificar outras partes do

sistema.

Com interfaces padronizadas, o cliente pode escolher a implementação que julgar

necessária. As camadas podem ser testadas separadamente, facilitando a tarefa de

testes, camadas inteiras podem ter a implementação modificada sem afetar as outras

camadas, além disso possui a facilidade de dividir as camadas entre outros membros de

uma equipe para os testes.

1. Camada de Interface

É a camada de apresentação com o usuário, sendo a interface a camada que

proporcionará a entrada de dados e a visualização das respostas geradas.

Geralmente a interface contém formulários, tabelas, menus e botões para

entrada e saída de dados. Ela deve garantir que seu sistema reflita o estado da

camada de regra de negócio.

2. Camada de Regra de Negócio

É a camada que possui a lógica do sistema, é responsável pelas regras de

negócio, para sistemas persistentes, representa a informação (dados) dos

formulários e as regras de SQL para manipular dados do BD, esta camada

mantém o estado persistente do negócio e fornece ao controlador a

capacidade de acessar as funcionalidades do sistema.

3. Camada de Persistência

Permite a realização do processo de persistência, isto é, o armazenamento e

manutenção do estado dos objetos em algum meio não volátil, como um BD

de forma transparente. Graças a independência entre a camada de

persistência e o repositório utilizado, é possível gerenciar a persistência de um

modelo de objeto em diversos tipos de repositórios.

A utilização deste conceito permitiu aos desenvolvedores trabalhar em um

sistema completamente orientado a objetos, utilizando métodos para incluir,

alterar, remover e pesquisar objetos e uma linguagem de consulta ao SGDBs

Orientados a Objetos, a linguagem SQL para realizar consultas que retornam

coleções de objetos instanciados.

3.9. Dificuldades e Soluções Encontradas

Durante o desenvolvimento foram identificadas algumas dificuldades e por se

tratar de um sistema para um ramo de negócio específico, não foram encontrados

exemplos que pudessem dar maiores subsídios ao trabalho executado.

3.10. Arquitetura de Software

A arquitetura de software é centrada na ideia da redução da complexidade

através da abstração e separação de interesses.

Com a arquitetura de software foi possível direcionar as tomadas de decisões, no

processo de desenvolvimento bem como das tarefas envolvidas em cada área de

especialidade e interesse do usuário, por exemplo, a parte interessada no que se refere a

sistemas, os desenvolvedores, o grupo de suporte, os testadores e os usuários do sistema

final. Neste sentido, a arquitetura de software se torna a ligação das múltiplas

perspectivas que um sistema traz com ele embutido. O fato de que estas várias

perspectivas diferentes possam ser interligadas em uma arquitetura de software padrão

justifica e valida a necessidade de criação da arquitetura antes do desenvolvimento do

software para que o projeto alcance a maturidade.

Figura 46 – Modelo Entidade de Relacionamento


3.11. Tabelas

AQUI SERIA INTERESSANTE, PARA NÃO DEIXAR A INFORMA A SEGUIR

PERDIDA, EXPLICAR QUE A PARTIR DO DIAGRAMA DE CLASSE E O MER,

SUGERE-SE A SEGUINTE ESTRUTURA DE TABELAS, COM SEUS RESPECITOS

ATRIBUTOS, BLA, BLA, BLA...

Tabela 01 – Cliente

Tabela : Cliente

Descrição: Armazena os dados dos clientes

Campo Tipo de dado

Tipo de Chave

Tabela de referência

Aceita valor nulo Descrição do campo

codCli numérico Primária não código do cliente

Nome Caractere não Nome do cliente

Rua Caractere não Endereço do professor

n°Casa numérico não Número da residência

CEP numérico não Cep da residência

RG numérico não Número do rg do cliente

telefone Caractere sim Número de telefone

Email Caractere sim Endereço de e-mail

CPF numérico não CPF do cliente

codEstado numérico Estrangeira Estado não código do estado (referência)

codCidade numérico Estrangeira Cidade não código da cidade (referência)

dataNascimento Data não Data de nascimento

tipoDeCliente numérico não 1 - Possui animal; 2 - Não possui animal

Sexo Caractere não M - Masculino; F - Feminino

dataCadastro Data não Data de Cadastro

cpfResponsavel numérico sim CPF do responsável pelo cliente menor de idade

nomeResponsavel Caractere sim Nome do responsável

Ativo Caractere não Referência de registro ativo


Tabela 02 – Cidade

Tabela : Cidade

Descrição: Armazena o nome das cidades.

Campo Tipo de dado

Tipo de Chave



codCidade numérico Primária não código da cidade (referência)


nomeEstado caractere não Nome do Estado


Tabela 03 – Estado

Tabela : Estado

Descrição: Armazena o nome e a unidade federativa dos estados.

Campo Tipo de dado

Tipo de Chave



codEstado numérico Primária não Código do estado (referência)

UF caractere não Sigla do estado

nomeEstado caractere não Nome do Estado


Tabela 04 – Professor

Tabela : Professor

Descrição: Armazena os dados dos professores.

Campo Tipo de dado

Tipo de Chave

Tabela de referência Aceita valor nulo Descrição do campo

codProfessor numérico Primária não código do professor

Nome Caractere não Nome do professor

Rua Caractere não Endereço do professor

n°Casa numérico não Número da residência

cep numérico não Cep da residência

rg numérico não Número do rg do professor

telefone Caractere sim Número de telefone

email Caractere sim Endereço de e-mail

CPF numérico não CPF do professor

sexo Caractere não M - Masculino; F - Feminino

codCidade numérico Estrangeira Cidade não código da cidade (referência)

dataNascimento Data não Data de nascimento

salario-hora numérico não Salario - hora do professor


ativo Caractere não Referência de registro ativo


Tabela 05 – Animal

Tabela : Animal

Descrição: Armazena os dados dos animais

Campo Tipo de dado

Tipo de Chave


codAnimal Numérico Primária não Código do animal

codCli Numérico Estrangeira Cliente não código do cliente

nomeAnimal Caractere não Nome do animal



Tabela 06 – Ligação Animal x Alimentação

Tabela : Ligacao_Ani_Alim

Descrição: Tabela de ligação entre as tabelas Animal e Alimentacao

Campo Tipo de dado

Tipo de Chave


codAnimal Numérico FK Animal não Código do animal

codAlimentacao Numérico FK Alimentacao não código do alimento

Porcao numérico não Porção dada ao animal

Data data não Data de registro da alimentação


Tabela 07 – Alimentação

Tabela : Alimentacao

Descrição: Armazena os dados dos alimentos

Campo Tipo de dado

Tipo de Chave


codAlimentacao numérico Primária não código do alimento

porcaoPorSaco numérico não Quantidades de porções por saco

nome Caractere não Nome do alimento

qteMinima numérico não Quantidade mínima do alimento

qteMaxima numérico não

Quantidade máxima do alimento

qteAtual numérico não Quantidade atual do alimento

precoVenda numérico não Preço de venda da porção

precoCompra numérico não Preço pago pela

empresa



Tabela 08 – Ferradura

Tabela : Ferradura

Descrição: Armazena os dados das ferraduras

Campo Tipo de dado Tipo de Chave


codFerradura Numérico Primária não código da ferradura

nome Caractere não Nome da ferradura

tipoFerradura Numérico não Tipo de ferradura

qteMinima Numérico não Quantidade mínima de ferraduras

qteMaxima Numérico não Quantidade máxima de ferraduras

qteAtual Numérico não Quantidade atual de ferraduras

precoVenda Numérico não Preço de venda da ferradura

precoCompra Numérico não Preço pago pela empresa



Tabela 09 – Ligação Animal x Ferradura

Tabela : Ligacao_Ani_Ferr

Descrição: Tabela de ligação entre as tabelas Animal e Ferradura



codAnimal numérico FK Animal não Código do animal

codFerradura numérico FK Ferradura não Código da ferradura

tipo numérico não Tipo de ferradura

data data não Data de registro da

ferradura


Tabela 10 – Medicação

Tabela : Medicacao

Descrição: Armazena os dados das medicações



codMedicacao Numérico Primária Medicacao não Código da medicação

dosePorVidro Numérico não Quantidade de doses por vidro

nome Caractere não Nome da medicação

qteMinima Numérico não Quantidade mínima da medicação

qteMaxima Numérico não Quantidade máxima da medicação

qteAtual Numérico não Quantidade atual da medicação

precoVenda Numérico não Preço de venda da dose

precoCompra Numérico não Preço pago pela empresa



Tabela 11 – Ligação Animal x Medicação

Tabela : Ligacao_Ani_Med

Descrição: Tabela de ligação entre as tabelas Animal e Medicacao




codAnimal numérico FK Animal não Código do animal

codMedicacao numérico FK Medicacao não Código da medicação

dose numérico não Dose de medicação aplicada no animal

data data não Data de registro da medicação


Tabela 12 – Aulas

Tabela : Aulas

Descrição: Registro das aulas




codProfessor numérico FK professor não código do professor

codCli numérico FK Cliente não código do cliente

codAula numérico FK tipoAula não código da aula

data data não Data de registro da aula


Tabela 13 – Tipo de Aulas

Tabela : TipoAula

Descrição: Registro dos tipos de aulas




codAula Numérico Primária não Código da aula

descrição Caractere não Descrição da aula

preco Numérico não Preço da aula


Tabela 14 – Histórico

Tabela : Historico

Descrição: Historico de vendas




codHist numérico Primária não Código do historico

data data não Data da venda

total numérico não Valor faturado


CONSIDERAÇÕES FINAIS

A informatização para inúmeras empresas na corrida contra o tempo passa a

ser fundamental nas grandes cidades para a sua sobrevivência no mercado de hoje,

junto aos seus concorrentes. Nesta busca incessante pelo diferencial a um mercado,

as vezes saturado de ofertas e atrativos comerciais, muitos empresários que

administram pequenas empresas procuram um meio de se destacar.

Este diferencial muitas vezes está aliado a informática, através de técnicas

que facilitem cada vez mais o cliente, como uma forma de aumentar seus lucros e

garantir sua permanência no mercado.

Os sistemas são criados, para gerar soluções e facilidades para as empresas

interessadas a conduzir seus usuários num mundo mais tecnológico, facilitando suas

atividades diárias na condução das informações pertinentes a empresa.

O SGH foi definido com o intuito de atender aos proprietários de Hípicas,

auxiliando-os a controlar melhor suas finanças, garantindo ao administrador uma

maior capacidade de controle para gerir seus negócios, ampliando sua visão

empresarial, pois o controle financeiro é um dos grandes diferenciais entre as muitas

outras Hípicas existentes.

O principal objetivo é prover a qualidade do sistema e atender de forma

eficiente a todos os requisitos. Destacamos o quanto é importante planejar,

gerenciar o tempo e acima de tudo trabalhar em equipe, sendo esse um dos maiores

desafios que encontramos em nossa jornada desse desenvolvimento acadêmico.

Sentimo-nos felizes e realizados por concretizar esse projeto, pois nada é

mais gratificante após nosso grande esforço e dedicação, colhermos os resultados

satisfatórios e, nos enriquecendo como pessoas e com o que conquistamos.

REFERÊNCIAS

PMBOK, A Guide to the Project Management Body of Knowledge Third Edition ed.

[S.l.]: Project Management Institute, 5ª Edição. 2013.

BEZERRA, E. Princípios de Análise e Projeto de Sistemas com UML. 2ª Edição. Rio

de Janeiro. Editora Campus, 2007.

DIAS, M. A., Administração de Materiais. 4ª Edição. Editora Atlas, 2010.

GOÉS, W.M. Aprenda UML por meio de Estudos de Caso. 1ª Edição. São Paulo:

Novatec Editora Ltda, 2014. Não referenciado no texto

LARMAN, C. Utilizando UML e Padrões. 3ª Edição. Artmed Editora, 2008.

OLIVEIRA, C.H.P. SQL, Curso Prático. 1ª Edição. São Paulo: Novatec Editora Ltda,

2002.

OLIVEIRA, D.P.R. Sistemas, Organização e Métodos: Uma Abordagem Gerencial,

15ª Edição. São Paulo: Editora Atlas, 2005.

SOMMERVILLE, I. Engenharia de Software, 8ª Edição. São Paulo: Editora Pearson,

2007.

SISTEMA DE GESTÃO DE HÍPICA - sistemas24horas.com.br · empresa em estudo não possui um software...

Documents

Transcript of SISTEMA DE GESTÃO DE HÍPICA - sistemas24horas.com.br · empresa em estudo não possui um software...