sistema de gestÃo de hÍpica - sistemas24horas.com.br · empresa em estudo não possui um software...
TRANSCRIPT
ALBERTO OLIVEIRA BARBOSA
LUCIANO DE SOUZA COELHO
MATHEUS DA ROCHA FERREIRA
SISTEMA DE GESTÃO DE HÍPICA
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
SISTEMA DE GESTÃO DE HÍPICA
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)
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)
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)
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)
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)
Figura 09 – Seções do Sistema (Manter Relatórios)
Fonte: Elaborado pelos autores.
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) .
8- Solicita armazenar no BD.
9- Autoriza o armazenamento.
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
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- 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.
3- Valida os dados digitados Include(Validar Dados) .
4- Solicita armazenar no BD.
5- Autoriza o armazenamento.
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.
2- Informa o código
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) .
8- Solicita armazenar no BD.
9- Autoriza o armazenamento.
10- Salva no BD Professor
Inclusão (Validar Professor)
Ator Sistema Classe
1- Valida código Professor
Sequência alternativa
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.
2- Informa o código
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- 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.
2- Informa o código
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.
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.
3- Valida os dados digitados Include(Validar Dados) .
4- Solicita armazenar no BD.
5- Autoriza o armazenamento.
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.
2- Informa o código
3- Validar o código. Include (Validar CodCliente)
Cliente
4- Obtém dados dos animais
Animal
5- Apresenta o formulário com os dados dos animais.
6- Altera os dados.
7- Valida os dados digitados Include(Validar Dados) .
8- Solicita armazenar no BD.
9- Autoriza o armazenamento.
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
1- Solicita o código do dono do animal.
2- Informa o código
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.
5- Confirma exclusão.
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
1- Solicita o código do dono do animal.
2- Informa o código
3- Validar o código Include (Validar CodCliente)
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.
3- Valida os dados digitados Include(Validar Dados) .
4- Solicita armazenar no BD.
5- Autoriza o armazenamento.
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.
7- Valida os dados digitados Include(Validar Dados) .
8- Solicita armazenar no BD.
9- Autoriza o armazenamento.
10- Salva no BD Alimentacao
Inclusão (Validar Alimento)
Ator Sistema Classe
1- Valida o código do alimento
Alimentacao
Sequência alternativa
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
1- Solicita o código do alimento.
2- Informa o código
3- Validar o código. Include (Validar
Alimentacao
Alimento) 4- Obtém dados do
alimento. Alimentacao
5- Apresenta o formulário com os dados do alimento.
6- Confirma exclusão.
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
1- Solicita o código do alimento.
2- Informa o código
3- Validar o código. Include (Validar Alimento)
Alimentacao
4- Obtém dados do alimento.
Alimentacao
5- Apresenta o formulário com os dados do alimento.
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.
3- Valida os dados digitados Include(Validar Dados) .
4- Solicita armazenar no BD.
5- Autoriza o armazenamento.
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.
2- Informa o código.
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.
7- Valida os dados digitados Include(Validar Dados) .
8- Solicita armazenar no BD.
9- Autoriza o armazenamento.
10- Salva no BD Ferradura.
Inclusão (Validar Ferradura)
Ator Sistema Classe
1- Valida o código da ferradura
Ferradura
Sequência alternativa
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.
2- Informa o código
3- Validar 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- Confirma exclusão.
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.
2- Informa o código
3- Validar o código. Include (Validar Ferradura)
Ferradura
4- Obtém dados da ferradura.
Ferradura
5- Apresenta o formulário com os dados da 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.
3- Valida os dados digitados Include(Validar Dados) .
4- Solicita armazenar no BD.
5- Autoriza o armazenamento.
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.
2- Informa o código.
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.
7- Valida os dados digitados Include(Validar Dados) .
8- Solicita armazenar no BD.
9- Autoriza o armazenamento.
10- Salva no BD Medicacao
Inclusão (Validar Medicação)
Ator Sistema Classe
1- Valida o código do produto
Medicacao
Sequência alternativa
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
2- Informa o código
3- Validar 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- Confirma exclusão.
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.
2- Informa o código
3- Validar o código. Include (Validar Medicação)
Medicação
4- Obtém dados da medicação
Medicação
5- Apresenta o formulário com os dados da 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
1- Solicita o código do cliente.
2- Informa o código
3- Validar o código Include (Validar CodCliente)
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)
11- Solicita armazenar no BD.
12- Autoriza Armazenamento.
13- Salva no BD. Aulas
Inclusão (Validar Horário)
Ator Sistema Classe
1- Validar horário
Sequencia Alternativa
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
1- Solicita o código do cliente.
2- Informa o código
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)
11- Solicita armazenar no BD.
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
2- Informa 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.
5- Apresenta 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.
2- Informa o 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
11- Apresenta relatório.
Include (Validar Período)
Ator Sistema Classe
1- Validar Período
Sequencia Alternativa
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
6- Calcula o valor das aulas.
7- Gera o relatório.
8- Apresenta 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
6- Obtém o valor da aula TipoAula
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
9- Obtém o valor da aula TipoAula
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
7- Calcula o valor das aulas.
8- Calcula o valor obtido com os animais.
9- Calcula o valor total.
10- Gera o relatório de faturamento.
11- Apresenta relatório.
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:
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
Fonte: Elaborado pelos Autores.
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)
Fonte: Elaborado pelos Autores.
Figura 13 – Diagrama de Sequência (Seção Alterar Cliente)
Figura 40 – Diagrama de Sequência (Seção Relatório de Aulas por Cliente)
Fonte: Elaborado pelos Autores.
Figura 42 – Diagrama de Sequência (Seção Relatório Boleto de Todos os Clientes)
Fonte: Elaborado pelos Autores.
Figura 43 – Diagrama de Sequência (Seção Relatório Boletos Individuais)
Fonte: Elaborado pelos Autores.
Figura 44 – Diagrama de Sequência (Seção Relatório Acompanhar Faturamento)
Fonte: Elaborado pelos Autores.
Figura 45 – Diagrama de Sequência (Seção Relatório Fechar Faturamento)
Fonte: Elaborado pelos Autores.
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.
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
Fonte: Elaborado pelos Autores.
Tabela 02 – Cidade
Tabela : Cidade
Descrição: Armazena o nome das cidades.
Campo Tipo de dado
Tipo de Chave
Tabela de referência
Aceita valor nulo Descrição do campo
codCidade numérico Primária não código da cidade (referência)
codEstado numérico Estrangeira Estado não código do estado (referência)
nomeEstado caractere não Nome do Estado
Fonte: Elaborado pelos Autores.
Tabela 03 – Estado
Tabela : Estado
Descrição: Armazena o nome e a unidade federativa dos estados.
Campo Tipo de dado
Tipo de Chave
Tabela de referência
Aceita valor nulo Descrição do campo
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
Fonte: Elaborado pelos Autores.
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
codEstado numérico Estrangeira Estado não código do estado (referência)
ativo Caractere não Referência de registro ativo
Fonte: Elaborado pelos Autores.
Tabela 05 – Animal
Tabela : Animal
Descrição: Armazena os dados dos animais
Campo Tipo de dado
Tipo de Chave
Tabela de referência Aceita valor nulo Descrição do campo
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
ativo Caractere não Referência de registro ativo
Fonte: Elaborado pelos Autores.
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
Tabela de referência Aceita valor nulo Descrição do campo
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
Fonte: Elaborado pelos Autores.
Tabela 07 – Alimentação
Tabela : Alimentacao
Descrição: Armazena os dados dos alimentos
Campo Tipo de dado
Tipo de Chave
Tabela de referência Aceita valor nulo Descrição do campo
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
ativo Caractere não Referência de registro ativo
Fonte: Elaborado pelos Autores.
Tabela 08 – Ferradura
Tabela : Ferradura
Descrição: Armazena os dados das ferraduras
Campo Tipo de dado Tipo de Chave
Tabela de referência Aceita valor nulo Descrição do campo
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
ativo Caractere não Referência de registro ativo
Fonte: Elaborado pelos Autores.
Tabela 09 – Ligação Animal x Ferradura
Tabela : Ligacao_Ani_Ferr
Descrição: Tabela de ligação entre as tabelas Animal e Ferradura
Campo Tipo de dado Tipo de Chave
Tabela de referência Aceita valor nulo Descrição do campo
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
Fonte: Elaborado pelos Autores.
Tabela 10 – Medicação
Tabela : Medicacao
Descrição: Armazena os dados das medicações
Campo Tipo de dado Tipo de Chave
Tabela de referência Aceita valor nulo Descrição do campo
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
ativo Caractere não Referência de registro ativo
Fonte: Elaborado pelos Autores.
Tabela 11 – Ligação Animal x Medicação
Tabela : Ligacao_Ani_Med
Descrição: Tabela de ligação entre as tabelas Animal e Medicacao
Campo Tipo de dado Tipo de Chave
Tabela de referência
Aceita valor nulo Descrição do campo
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
Fonte: Elaborado pelos Autores.
Tabela 12 – Aulas
Tabela : Aulas
Descrição: Registro das aulas
Campo Tipo de dado Tipo de Chave
Tabela de referência
Aceita valor nulo Descrição do campo
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
Fonte: Elaborado pelos Autores.
Tabela 13 – Tipo de Aulas
Tabela : TipoAula
Descrição: Registro dos tipos de aulas
Campo Tipo de dado Tipo de Chave
Tabela de referência
Aceita valor nulo Descrição do campo
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
Fonte: Elaborado pelos Autores.
Tabela 14 – Histórico
Tabela : Historico
Descrição: Historico de vendas
Campo Tipo de dado Tipo de Chave
Tabela de referência
Aceita valor nulo Descrição do campo
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
Fonte: Elaborado pelos Autores.
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.