Sie sind auf Seite 1von 77

CARLOS MAGNO BORGES DE OLIVEIRA

DIGO DOS SANTOS DO NASCIMENTO


JADER CASTELO BRANCO PANIZ
JOBSON ALVES MENEZES
RAPHAEL PEREIRA SAMPAIO
VICTOR HUGO DIAS MARTINS
WESLEY BORGES DA CONCEIO

SISTEMA DE CONTROLE DE AVALIAO FSICA PARA PERSONAL


TRAINER

APARECIDA DE GOINIA
2015

FACULDADE NOSSA SENHORA APARECIDA


CURSO SUPERIOR DE TECNOLOGIA EM ANLISE E
DESENVOLVIMENTO DE SISTEMAS
CARLOS MAGNO BORGES DE OLIVEIRA
DIGO DOS SANTOS DO NASCIMENTO
JADER CASTELO BRANCO PANIZ
JOBSON ALVES MENEZES
RAPHAEL PEREIRA SAMPAIO
VICTOR HUGO DIAS MARTINS
WESLEY BORGES DA CONCEIO

SISTEMA PARA CONTROLE DE AVALIAO FSICA PARA


PERSONAL TRAINER

Projeto Interdisciplinar II apresentado


coordenao do Curso Superior de
Tecnologia
em
Anlise
e
Desenvolvimento de Sistemas da
Faculdade Nossa Senhora Aparecida
FANAP, para obteno do grau de
Tecnlogo em Anlise de Sistemas.

Orientador: Prof. Esp. Pabllo Borges


Cardoso

APARECIDA DE GOINIA
2015

CARLOS MAGNO BORGES DE OLIVEIRA


DIGO DOS SANTOS DO NASCIMENTO
JADER CASTELO BRANCO PANIZ
JOBSON ALVES MENEZES
RAPHAEL PEREIRA SAMPAIO
VICTOR HUGO DIAS MARTINS
WESLEY BORGES DA CONCEIO
SISTEMA PARA CONTROLE DE AVALIAO FSICA PARA
PERSONAL TRAINER

Projeto Interdisciplinar aprovado como requisito parcial para a obteno do ttulo


de Tecnlogo em Anlise e Desenvolvimento de Sistemas, no Curso Superior de
Tecnologia em Anlise e Desenvolvimento de Sistemas da Faculdade Nossa
Senhora Aparecida FANAP.

Banca Examinadora

Orientador (a): ________________________________________________


Esp. Pabllo Borges Cardoso

Examinador (a): ________________________________________________


Ma. Maria Rita Almeida Gonzaga

Examinador (a): ________________________________________________


Esp. Saul Matuzinhos de Moura

Aparecida de Goinia, 29 de Setembro de 2015.

Em primeiro lugar queremos dedicar


aos nossos familiares que nos
ajudaram neste caminho ao longo
desse tempo. coordenao do curso
de Analise em Desenvolvimento de
Sistemas da FANAP, e s pessoas com
quem convivemos nesses espaos ao
longo desses anos. A experincia de
uma produo compartilhada na
comunho
com
amigos
nesses
espaos foi a melhor experincia da
nossa formao acadmica.

Agradecemos a Deus, por nos ter


proporcionado vida, sade, sabedoria e
nimo para o desenvolvimento dessa
obra. Aos nossos pais pela dedicao e
amor. Aos nossos mestres que estiveram
firmemente ao nosso lado, nos
orientando e auxiliando nas dvidas em
busca do conhecimento.

RESUMO
NASCIMENTO, Digo dos santos. MENEZES, Jobson Alves. GOUVEA, Mario
Marcos de Oliveira. MARTINS, Victor Hugo Dias. SAMPAIO, Raphael Pereira.
CONCEIO, Wesley Borges. PANIZ, Jader Castelo Branco. Sistema para
controle de avaliao fsica para personal trainer. Aparecida de Goinia, 2014.
38 pginas. Projeto Interdisciplinar (Graduao Tecnolgica em Anlise de
Sistemas). Curso Superior de Tecnologia em Anlise e Desenvolvimento de
Sistemas, Faculdade Nossa Senhora Aparecida FANAP.

O personal trainer o profissional que tem como objetivo oferecer um


condicionamento fsico e especfico para cada cliente, por isso ele precisa gerir e
organizar informaes para avaliar seus clientes. Com o surgimento de novas
oportunidades tecnolgicas, como sistemas de informaes, os profissionais que
ainda no optaram por um recurso mais eficiente acabam ficando ultrapassados.
Essa necessidade que o personal trainer tem em buscar algo que possa suprir
seus objetivos, levou ao desenvolvimento de um sistema de gerenciamento que
possa resolver os problemas desse profissional. Observou-se atravs de
questionrios e entrevistas que alguns profissionais desta rea, em sua maioria
usam planilhas eletrnicas tanto para gerenciar atividades relacionadas gesto
quanto para avaliar o desempenho fsico de cada cliente. Aps este planejamento
tcnico e um estudo das rotinas implicadas ao personal trainer, decidiu-se
desenvolver e implementar o sistema de gerenciamento, assim poderiam ter
maior controle das informaes com isso espera-se ao final do projeto chegar a
implementao deste sistema. O sistema ter uma diviso entre parte
administrativa e avaliao fsica. Isso se justifica, pois se encontrou algumas
dificuldades relacionadas com os fluxos de informaes dos clientes e o risco de
se perder ou confundir dados, alm disso, o personal no trabalha em lugar fixo,
por isso ele pode desmarcar aulas a todo momento. Tendo isso em vista, esse
sistema de gerenciamento de clientes possuir ferramentas como cadastros,
clculos relacionados ao fsico, relatrios e, por fim, a parte administrativa do
personal. Para oferecer de forma mais eficiente o controle e organizao do seu
trabalho, todas as operaes gerenciais estaro concentradas em um nico
sistema, facilitando assim seu trabalho.

Palavras-chave: Sistema; Informaes; Personal Trainer; Organizao.

ABSTRACT

NASCIMENTO, Digo dos santos. MENEZES, Jobson Alves. GOUVEA, Mario


Marcos de Oliveira. MARTINS, Victor Hugo Dias. SAMPAIO, Raphael Pereira.
CONCEIO, Wesley Borges. PANIZ, Jader Castelo Branco. System for
controlling physical assessment for personal trainer. 38 pages Interdisciplinary
Project (Graduate Technological Analysis Systems). Degree in Technology
Analysis and Systems Development, Faculty Nossa Senhora Aparecida FANAP.

The personal trainer is a profession that aims to offer a physical and conditioning
specific to each customer, so it needs to manage and organize information to
assess their clients. With the emergence of new technological opportunities such
as information systems, practitioners who have not opted for a more efficient use
end up getting outdated. This need that the trainer has to seek something that can
meet their objectives, stimulated the interest of students of the college Nossa
Senhora Aparecida (FANAP) to develop a management system that can solve the
problems of this professional. Scholars have observed through questionnaires and
interviews with some professionals in this area, that most of them use
spreadsheets to manage both related to management activities and to evaluate
the physical performance of each client. After this technical planning and routines
involved a study of the personal trainer, scholars decided to develop and
implement management system, so they could have more control of the
information about it is expected to reach the end of the project implementation of
this system. The system will have a split between management and selling
physical assessment. This is justified because we found some difficulties related to
the flow of customer information and the risk of losing or confusing data, moreover,
the personal works not fixed in place, so it should clear lessons all the time.
Keeping this in view, this management system will have tools like customer
records, related to the physical, reports, calculations, and finally, the administrative
part of the personal. To provide more efficient control and organize their work, all
management operations will be concentrated in a single system, thus facilitating
their work. This project was creat about, a clear and objective analysis of the
interests of the personal trainer was held.

Keywords: Information; Personal Trainer; Organization.

LISTA DE SIGLAS

IMC - ndice de Massa Corporal.


FANAP - Faculdade Nossa Senhora Aparecida.
SCAFPT - Sistema para Controle para de Avaliao Fsica para Personal Trainer.
CREF - Conselho Regional de Educao Fsica.
JVM - Java Virtual Machine.
PJ - Personal Jobs.
TI - Tecnologia da Informao.
WWW World Wide Web
IMAP internet Message Access Protocol
SNMP Simple Network Management Protocol
NNTP Network News Transfer Protocol
POP3 Post Office Protocol
SGBD Data Base Management System
UoD Universo of Discourse
DBA Database Administrator
DDL Dynamic-link library
GUI Graphical user interface
OLTP Online Transaction Processing
GNU/GLP General Public License
TB Terabytes
SQA Software quality assurance
IEEE Institute of Electrical and Electronic Engineers
ISO International Organization for Standardization

LISTA DE ILUSTRAES
Figura 1: Diagrama de Fluxo de Dados..................................................................50
Figura 2: Diagrama de Entidade Relacionamento..................................................56
Figura 3: Tela de acesso ao sistema......................................................................61
Figura 4: Tela de cadastro de Principal..................................................................62
Figura 5: Tela de cadastro de Cliente..................Error: Reference source not found
Figura 6: Tela de cadastro de Agenda....................................................................62
Figura 7: Tela de cadastro de Treino...................Error: Reference source not found
Figura 8: Tela cadastro de Anamnese.................Error: Reference source not found
Figura 9: Tela cadastro de Avaliao Risco Cardaco.. Error: Reference source not
found
Figura 10: Tela cadastro de Avaliao Fsica......Error: Reference source not found
Figura 11: Tela cadastro de Composio Corporal.......Error: Reference source not
found
Figura 12: Tela cadastro de IMC..........................Error: Reference source not found
Figura 13: Tela cadastro de PAR-Q.....................Error: Reference source not found
Figura 14: Tela cadastro de Perimetria................Error: Reference source not found
Figura 15: Tela cadastro Financeiro.....................Error: Reference source not found
Figura 16: Tela de Relatrios...............................Error: Reference source not found
Figura 17: Modelo Fsico.....................................Error: Reference source not found

LISTA DE TABELAS
Tabela 1: Cronograma de Atividades...................Error: Reference source not found
Tabela 2: Requisito do Sistema Estado............Error: Reference source not found
Tabela 3: Requisito do Sistema Cidade............Error: Reference source not found
Tabela 4: Requisito do Sistema Cliente............Error: Reference source not found
Tabela 5: Requisito do Sistema Fornecedores. Error: Reference source not found
Tabela 6: Requisito do Sistema Produto...........Error: Reference source not found
Tabela 7: Requisito do Sistema Estoque..........Error: Reference source not found
Tabela 8: Requisito do Sistema Departamento Error: Reference source not found
Tabela 9: Requisito do Sistema Cargo.............Error: Reference source not found
Tabela 10: Requisito do Sistema Funcionrio. .Error: Reference source not found
Tabela 11: Requisito do sistema Nvel de Usurio....Error: Reference source not
found
Tabela 12: Requisito do Sistema Usurio.........Error: Reference source not found
Tabela 13: Requisito do Sistema Situao de Pedidos...Error: Reference source
not found
Tabela 14: Requisito do Sistema Pedido..........Error: Reference source not found
Tabela 15: Requisito do Sistema Histrico de Pedidos...Error: Reference source
not found
Tabela 16: Requisito do Sistema Detalhe de PedidosError: Reference source not
found
Tabela 17 - Depsito de dados D1.........................................................................58
Tabela 18 - Depsito de dados D2.........................................................................59
Tabela 19 - Depsito de dados D3.........................................................................60

LISTA DE QUADROS

Quadro 1 - Exemplo de aplicao do padro MVC. .Erro! Indicador no definido.

SUMRIO

LISTA DE SIGLAS.....................................................................................................8
LISTA DE ILUSTRAES........................................................................................9
LISTA DE TABELAS................................................................................................10
1 INTRODUO.....................................................................................................14
1.1 TEMA.............................................................................................................14
1.2 DELIMITAO DO TEMA.............................................................................14
1.3 OBJETIVOS GERAIS....................................................................................15
1.4 OBJETIVOS ESPECFICOS.........................................................................15
1.5 PROBLEMA...................................................................................................16
1.6 HIPTESE.....................................................................................................16
1.7 JUSTIFICATIVA.............................................................................................16
1.8 METODOLOGIA............................................................................................17
1.9 CRONOGRAMA DE ATIVIDADES................................................................18
2 FUNDAMENTAO TERICA...........................................................................19
2.1 OBJETIVO DA PROFISSO DE PERSONAL TRAINER..............................19
2.1.1 FORMAO NECESSRIA PARA SE TORNAR UM PERSONAL........20
2.1.2 APRESENTAO DOS PRINCIPAIS PROCESSOS..............................21
2.2.1 HISTRIA DO JAVA................................................................................22
2.2.3 CARACTERSTICAS DA LINGUAGEM DE PROGRAMAO JAVA.....23
2.2.4 UTILIZAO DA LINGUAGEM NA WEB................................................24
2.2.5 PARTICULARIEDADES DA LINGUAGEM..............................................24
2.2.6 MECANISMO DE AUXLIO......................................................................25
2.3 USO DO BANCO DE DADOS / MYSQL.......................................................25
2.3.1 ORGANIZAO DO BANCO DE DADOS..............................................26
2.3.4 VANTAGENS DE SE USAR O BANCO DE DADOS...............................27

2.3.5 SGBD RELACIONAIS..............................................................................28


2.4.1 Qualidade de Software...............................................................................31
2.4.2 Elementos de Garantia da Qualidade de Software....................................31
2.5 PADRES DE PROJETO..............................................................................33
2.5.1 Conceito......................................................................................................33
3 PERFIL DA ORGANIZAO...............................................................................36
3.1 CARACTERSTICAS INTERNAS DA ORGANIZAO................................36
3.1.2 COLABORADORES................................................................................36
3.1.3 REGRAS DE NEGOCIO..........................................................................37
3.2 RELACIONAMENTO COM CLIENTE...........................................................37
3.3 RELAO COM OS COLABORADORES E SERVIOS.............................38
4 SOLUO PROPOSTA.......................................................................................39
4.1 ANLISE DE REQUISITOS...........................................................................39
4.1.2 CONTEXTO DE APLICAO...................................................................40
4.1.2.3 LEVANTAMENTO DE REQUISITOS.......................................................41
4.1.1 Descrio do Sistema ou Produto.................................................................41
4.1.3.1 Definio dos Atores................................................................................41
4.1.3.2 Lista de Eventos do Sistema...................................................................42
4.1.2 Especificao de Requisitos do Sistema ou Produto.................................42
4.1.3 Especificao de Requisitos do Sistema.................................................44
4.1.4 Modelo de Dados.....................................................................................47
4.1.4.1. DFD Preliminar....................................................................................48
4.1.4.3 Diagrama de Classes..........................................................................51
4.1.4.4 Diagrama de Casos de Uso..................................................................51
4.1.4.4.1 Diagrama de Caso De Uso..............................................................54
4.1.4.4 Diagrama de Entidade Relacionamento...............................................55
4.1.4.6 Diagrama de Classe.............................................................................57

4.1.5 Dicionrio de Dados.................................................................................58


4.2 PROJETO......................................................................................................61
4.2.1 Prototipao.............................................................................................61
. 4.2.2 Modelo Fsico do Banco de Dado.........................................................69
CONSIDERAES FINAIS....................................................................................70
REFERNCIAS.......................................................................................................71
APNDICE..............................................................................................................73
ATA DA 1 REUNIO DO PROJETO INTERDISCIPLINAR....................................73
REUNIAO COM O PERSONAL..............................................................................73
ANEXO I..................................................................................................................75

14

1 INTRODUO
O personal trainer um especialista em condicionamento fsico que
trabalha com clientes de forma individualizada e personalizada. Tem por objetivo
oferecer uma condio fsica especfica para cada perfil de sua clientela. Com o
aumento na demanda, estes profissionais acabam se deparando com certas
dificuldades relacionadas ao gerenciamento de dados e ao controle financeiro.
Para facilitar o trabalho desse profissional est sendo desenvolvido um
sistema que possa auxili-lo no manejo mais seguro dos dados.
O sistema auxiliar nas principais funes do personal trainer, tais como
cadastrar clientes, agendar aulas, prescrever treinos, avaliar o condicionamento
fsico a partir dos testes realizados, avaliar riscos e histrico de sade, para que
posteriormente seja gerado um relatrio da sade fsica de cada cliente.
Utilizando de uma viso mais prtica, est sendo desenvolvido um
sistema gerenciador de rotinas do personal trainer, assim o usurio desfrutar de
um sistema mais abrangente e moderno, capaz de controlar e organizar os dados
dos seus clientes de forma mais eficiente e segura. Este sistema tambm possui
uma ferramenta que gera um relatrio do estado fsico do cliente, pois isto
facilitar a decidir quais mudanas de treinos, alimentaes devem ser realizadas
ou aprimoradas de um modo geral.
1.1 TEMA
Sistema para administrao de clientes, gerenciamento e avaliao fsica
para o personal trainer.
1.2 DELIMITAO DO TEMA
Este sistema est sendo implementado com objetivo de facilitar a gesto
de clientes do personal trainer. Ser dividido em duas partes: administrao e
avaliao fsica dos clientes. Na parte administrativa, o personal trainer poder
agendar aulas, cadastrar novos clientes alm de ter o controle sobre a parte
financeira. J na parte de avaliao fsica, ele poder avaliar a sade fsica do

15

cliente realizando testes de classificao de risco e fazer os clculos necessrios


para o condicionamento fsico e ganho de massa muscular, tais como: clculos de
dobras cutneas, clculos de IMC (ndice de Massa Corporal), perimtrica,
relao cintura e quadril, frequncia cardaca, percentual de gordura e presso
arterial. Tambm poder prescrever treinamentos especficos para cada cliente. O
sistema ser desenvolvido somente no decorrer no curso, ou seja, no trmino do
curso no ter novas verses e nem suporte futuro.
1.3 OBJETIVOS GERAIS
Este projeto tem como objetivo facilitar a organizao dos processos
administrativos dos profissionais de educao fsica, proporcionando maior
produtividade em todas as reas de negcio tais como aulas e treinos. Alm
disso, possui ferramentas para cadastro de alunos, gerenciador da parte
financeira e agendamento de aula.
importante destacar que o foco de trabalho deste profissional analisado
para a implementao do sistema o condicionamento fsico, perda de gordura
corporal e ganho de massa corporal. Sendo assim, todos seus clientes devero
ser previamente aprovados na avaliao fsica e no possurem histricos de
problemas de sade.
Desse modo, o personal trainer ter maior controle sobre cada cliente e
isto possibilitar ter uma maior preciso e organizao nas suas rotinas dirias.
Com estas ferramentas facilitara o controle de dados dos clientes gerando assim
maior eficincia do tempo e organizao para que o profissional possa se dedicar
ao mximo aos treinos dos alunos.
1.4 OBJETIVOS ESPECFICOS

Gerenciar as informaes dos alunos;

Gerenciar as funes financeiras;

Organizar as rotinas administrativas;

Avaliar fsico do cliente;

16

Agendar aulas;

Gerar relatrios financeiros;

Gerar relatrios de desempenho dos clientes.

1.5 PROBLEMA
Grande parte dos profissionais de educao fsica que trabalham como
personal trainer so autnomos, ou seja, no possuem uma academia especfica
e, por conta disto, sofrem com a falta de recursos e ferramentas para o controle
de informaes. Umas das principais necessidades a utilizao de uma agenda
para anotar dados cadastrais e aulas. O risco deste profissional perder ou
esquecer essa agenda, pode prejudicar algum horrio de compromisso, bem
como dificultar a busca de alguma informao.
1.6 HIPTESE
Devido falta de um projeto para organizao dos processos
administrativos de um personal trainer, decidiu-se ento elaborar um sistema
para o perfil desse profissional. Percebeu-se a possibilidade de solucionar esses
problemas com a implantao de um sistema com ferramentas capazes de
controlar informaes de clientes e auxiliar a parte administrativa, alm de
organizar as finanas e horrios. Com essa informatizao, o usurio ter maior
controle e segurana de dados dos clientes e optimizao do tempo, dessa forma
ter mais meios de aumentar a produtividade.
1.7 JUSTIFICATIVA
Com o constante crescimento na rea de personal trainer, alguns
problemas comearam a surgir, como especializao neste ramo de trabalho e
a dificuldade de encontrar os dados de um cliente devido ao acumulo de
informaes do mesmo, pois todo sucesso de um personal trainer ou centro de
personal training, est direcionado conquista e manuteno da clientela.

17

Por ter uma exigncia de qualidade muito mais elevada, o diferencial


nesse mercado vem da especializao do profissional, recursos utilizado para a
excelncia no atendimento clientela e do nvel dos recursos de tecnologia e
instrumentos e equipamentos utilizados.
O desenvolvimento desse sistema ser de grande importncia para o
personal gerir e trabalhar com as informaes de seus clientes, alm de controlar
de suas atividades corriqueiras.
1.8 METODOLOGIA
Durante toda a anlise e desenvolvimento do sistema, optou-se por
utilizar no apenas um mtodo, mas sim, mtodos que pelas suas caractersticas
demonstraram ser essenciais para a coleta eficiente de dados do software a ser
projetado e implementado. So eles: entrevista, questionrio, pesquisa de campo
e pesquisa bibliogrfica. A entrevista um encontro entre duas pessoas e tem
como escopo a obteno de informaes sobre determinado assunto. Optou-se
pela sua forma no estruturada, ou seja, menos formalidade e mais liberdade na
elaborao das questes. Atravs desta foi possvel colher informaes sobre a
rotina de trabalho do personal trainer.
Em relao ao questionrio (Anexo 1), constitudo por perguntas
ordenadas que devem ser respondidas sem a presena do entrevistador e por
escrito. Atravs deste instrumento previamente elaborado foi possvel colher
informaes mais detalhadas sobre todos os processos envolvidos no dia-a-dia
de trabalho do profissional.
A pesquisa de campo consiste na observao dos fatos e fenmenos que
ocorrem em determinado ambiente. Atravs desta foi possvel analisar com mais
detalhes o trabalho do profissional e por consequncia clarear algumas dvidas
que at ento no tinham sido elucidadas.
Por fim, a pesquisa bibliogrfica foi feita atravs do estudo de vrios livros
de autores renomados da rea de TI. Dessa forma foi possvel conhecer
profundamente a metodologia, linguagem de programao e o SGBD a serem
utilizados no desenvolvimento do sistema.

1.9 CRONOGRAMA DE ATIVIDADES


Tabela 1: Cronograma
Fonte: Elaborado pelos acadmicos

Atividade

Perodo

2014
Ago

2015

Set Out Nov

dez

Jan

Fev

Mar

Abr

Mai

Jun

Jul

Ago

Set

Desenvolvimento
do

Sistema
Entrevista
Orientao
Reunio com
grupo

Elaborao
do
projeto
Programao

Out

Nov

Dez

19

2 FUNDAMENTAO TERICA
2.1 OBJETIVO DA PROFISSO DE PERSONAL TRAINER
O mercado de trabalho para professores e profissionais de educao
fsica competitivo, e a oferta de trabalho tende a crescer no setor privado. H
centenas de milhares de profissionais de educao fsica atuando em todo o pas,
a grande maioria deles dedicada ao magistrio. O quadro vem mudando nos
ltimos anos devido conscientizao de que condicionamento fsico sinnimo
de bem-estar e sade. O nmero de academias cresce a cada ano, e com elas a
procura por profissionais da rea. Surgem empresas prestadoras de servios
esportivos e franquias, que atendem demanda criada por hotis, clubes e
condomnios e geram empregos. Com a regulamentao, a demanda por
profissionais bem-qualificados deve aumentar, j que profissionais formados que
atuam na rea esportiva so relativamente poucos. Alm de escolas e academias,
empresas tambm demandam esses profissionais seja para atuar na rea de
marketing e promoo, seja para treinar suas equipes esportivas ou cuidar de
eventos ligados aos esportes. Um outro segmento que tambm vem
experimentando

um

crescimento

acelerado

do

acompanhamento

personalizado ou personal trainer. A atividade no nova, mas foi redescoberta


por artistas, personalidades e executivos, que por motivos diversos preferem
trabalhar exclusivamente com um profissional a ter que frequentar academias e
clubes.
O personal atua no ramo de musculao e condicionamento fsico do
cliente, atravs de exerccios fsicos e rotinas aplicadas durante a aula, tem o
objetivo de trazer condicionamento fsico adequado para seus clientes. Ele
oferece um servio de exclusividade, tanto na parte de atendimento quanto na
parte de acompanhamento, promovendo assim maior motivao e incentivo do
cliente, pois est sempre presente demonstrando maior comodidade e vantagem
para o comprimento das metas e objetivos.

20

2.1.1 FORMAO NECESSRIA PARA SE TORNAR UM PERSONAL


Legalmente, o personal trainer s pode atuar aps se formar como
bacharel em educao fsica e ter seu registro junto ao Conselho de Educao
Fsica no CREF. Porm essa formao e registro no tm relao direta com as
aptides necessrias para engrenar no negcio.
Avalia programas educativos em centros comunitrios, parques, hospitais,
clnicas, "spas", creches, hotis, casas de menores e penitencirias; Ensino:
Leciona em escolas de primeiro, segundo e terceiro graus. Para exercer esta
atividade o bacharel deve complementar sua formao com disciplinas do
currculo do curso de Licenciatura; Grupos Especiais: Organiza e implanta
atividades recreativas para idosos, deficientes fsicos e mentais, pessoas com
problemas cardacos, de coluna ou musculares; Recreao: o responsvel pelo
entretenimento de hspedes, associados e turistas em hotis, clubes e "spas";
Treinamento: Desempenha a funo de tcnico de equipes das mais variadas
modalidades esportivas, profissionais ou amadores. Personal Trainer: Profissional
graduado e especializado em determinada rea da Educao Fsica, que presta
servios personalizados, que atravs de um acompanhamento particular, realiza
os objetivos do cliente com mais rapidez e segurana.
Segundo a lei ordinria nmero 9.696 de 01 de setembro de 1998 dispe
sobre a regulamentao da profisso de educao fsica e cria os respectivos
conselho federal e conselho regionais de Educao Fsica. De acordo
(Constituio Federal, 1988, ART- 93 INC-9 ART-5 INC-36, FED LEI- 6830).
Artigo 1 O exerccio das atividades de educao fsica e a
designao de profissional de educao fsica e prerrogativa dos
profissionais regularmente registrados nos conselhos regionais de
educao fsica.
Artigo 2 Apenas sero inscrito nos quadros dos conselhos
regionais de educao fsica os seguintes profissionais:

I - Os possuidores de diploma obtido em curso de educao fsica,


oficialmente autorizado ou reconhecido; e

II - Os possuidores de diploma em educao fsica expedido por


instituio de ensino superior estrangeira revalidado na forma de
legislao em vigor.

21

2.1.1.2 REALIZAO DO TRABALHO


Profissional responsvel em formar hbitos e atitudes que promovam o
desenvolvimento harmonioso do corpo humano, mediante instruo sobre higiene
corporal e mental e mediante vrios e sistemticos exerccios, esportes e jogo
Devido ao stress no corpo durante os exerccios o personal trainer tenta
sempre brincar e variar a forma dos treinos para no ocorrer o desgaste fsico e
mental, j que este profissional trabalha tambm com uma gesto de pessoas e
para isso o comportamento tico importante para com seus clientes.
Condicionamento Fsico: D aulas de ginstica coletiva e individual,
visando a melhoria da condio muscular e cardiovascular, principalmente para
adultos e idosos. responsvel pelo planejamento e desenvolvimento de
atividades fsicas individuais e coletivas em escolas, academias de ginstica e de
musculao, ginsios esportivos e piscinas Consultoria e assessoria: Pode atuar
junto a rgos pblicos e empresas privadas para organizao e implantao de
programas de Educao Fsica para funcionrios.
2.1.2 APRESENTAO DOS PRINCIPAIS PROCESSOS
A gesto do trabalho do personal est diretamente relacionada com
pessoas, porm ele tambm lida com uma grande quantidade de documentao e
informaes. Estas so das respectivas reas:

Gerenciamento de informaes de clientes, como horrios de

treinos telefones e restries de treinamentos por motivos de doenas etc.;

Controle dos pagamentos dos clientes e rea de finanas em geral;

Prescrio de relatrios e rotinas de atividades fsicas; e

Avaliaes fsicas, treinamentos e clculos de IMC, dobras

cutneas.

22

2.2 LINGUAGEM DE PROGRAMAO JAVA


2.2.1 HISTRIA DO JAVA
De acordo com Deitel (2010), Java uma linguagem de programao
orientada a objetos, desenvolvida por uma equipe Sun Microsystem, em 1991.
Java a contribuio mais importante da revoluo do microprocessador. O
microprocessador tem um impacto grande entre os dispositivos eletrnicos
inteligentes. Em 1995, o Java chamou a ateno devido ao sucesso mundial da
World Wide Web.
O principal propsito do desenvolvimento da linguagem de programao
Java era conseguir que os processadores de eletrodomsticos funcionassem em
qualquer plataforma, pois devido constante evoluo dos eletrnicos toda vez
que um novo produto era lanado no mercado com um novo processador
embutido, era necessrio um novo programa para pudesse funcionar no
compilador. Devido este desgaste os programadores estavam descontentes com
as linguagens convencionais da poca. De acordo com Deitel (2010).
No incio de 1990, Naughton, Gosling e Sheridan comearam a definir as
bases para o projeto de uma nova linguagem de programao,
apropriada para eletrodomsticos, sem os problemas j to conhecidos
de linguagens tradicionais como C e C++. O consumidor era o centro do
projeto, e o objetivo era construir um ambiente de pequeno porte e
integrar esse ambiente em uma nova gerao de mquinas para
pessoas comuns. A especificao da linguagem terminou em agosto de
1991, e a ela deu-se o nome de "Oak"[Carvalho]. Por problemas de
copyrigth (j existia uma linguagem chamada Oak) o nome foi mudado
em 1995 para Java, em homenagem ilha de Java, de onde vinha o caf
consumido pela equipe da Sun Microsystem.

2.2.2 INTRODUO LINGUAGEM DE PROGRAMAO JAVA


De acordo com o livro Java Como Programar de Paul J. Deitel e Dr.
Harvey M. Deitel a linguagem de programao Java tem como caracterstica uma
plataforma independente, ou seja, escreva uma vez e executa em qualquer lugar,
ela tambm possui uma extensa biblioteca que o auxilia a cooperao com

23

protocolos como HTTP e FTP de uso nas aplicaes de internet. A sintaxe dessa
linguagem e bastante similar ao C/C++ pois foi desenvolvida a partir da mesma.
Para a execuo de algum dispositivo escrito nesta linguagem ou ate
mesmo para o desenvolvimento e necessrio ter um pacote j instalado, chamado
JVM (Java Virtual Machine) com este ambiente de execuo pode se utilizar qual
quer aplicao JAVA.
O Java praticamente a base para todos os tipos de aplicaes, tanto
para o padro global do desenvolvimento das aplicaes quanto para as
incorporadas como moveis. Seu contedo e baseado nos softwares corporativos e
na web est presente na maioria dos jogos, telefones e internet.
2.2.3 CARACTERSTICAS DA LINGUAGEM DE PROGRAMAO JAVA
Segundo

Deitel

(2010),

contribuio

mais

importante

do

microprocessador at essa data que ele tornou possvel o desenvolvimento de


computadores pessoais. Em 2008, a empresa Sun Microsystems criou o projeto
Ice Tea, que reescreveu todos os cdigos da ferramenta e liberou, em maio, a
verso gratuita e livre do Java. Ser livre no a principal caracterstica que
diferencia a linguagem Java, mas a multiplataforma. A tecnologia Java teve uma
enorme utilizao em diversos equipamentos eletrnicos, logo que a empresa IBM
deu incio a suporte para a linguagem, os produtos desta empresa rodariam
aplicativos feitos em Java, devido a isso essa linguagem passou a ser utilizada
para dezenas de produtos diferentes: Computadores, celulares, palmtops e ate
produtos da Apple.
Segundo Deitel (2010), o Java se tornou a linguagem preferida para
implementar aplicativos baseados na internet e software para dispositivos que se
comunicam por uma rede na grande maioria so aplicativos de celular. O Java se
tornou a linguagem preferida para implementar aplicativos baseados na internet e
software para dispositivos que se comunicam por uma rede na grande maioria so
aplicativos de celular. Atualmente, existem bilhes de celulares e dispositivos
portteis compatveis com Java, linguagem que evoluiu a partir do C++. Programa
Java consistem em partes chamadas classes, essas mesmas incluem partes

24

chamadas mtodos, objetos, listas entre mais, que realizam tarefas e retornam
informaes quando as tarefas so concludas.
2.2.4 UTILIZAO DA LINGUAGEM NA WEB
Tendo em vista o que declara Deitel (2010), um servio Web um
componente de software armazenado em um computador que pode ser acessado
por um aplicativo de celular ou em outro computador por uma rede. Java tem uma
plataforma multifuncional com outros sistemas operacionais criando assim um
grande recurso quando se trata de utilizao na web um grande exemplo da sua
capacidade a Receita Federal. Antigamente tinha que ser feito verses
diferentes do programa de declarao de Renda para todos os tipos de
plataformas, Windows, Linux, MacOs etc. Agora com a utilizao da linguagem de
programao Java feita apenas uma verso do software.
2.2.5 PARTICULARIEDADES DA LINGUAGEM
Segundo Deitel (2010), a Mquina Virtual Java JVM parte do ambiente
de runtime Java a responsvel pela interpretao dos bytecodes programa
compilado em Java os programas escritos em Java no so compilados para
uma plataforma especifica como nas demais linguagens, eles so convertidos em
cdigos chamados bytecodes destinada mquina virtual Java, ou seja, a JVM
um interpretador de cdigos para a plataforma que esto sendo executados, por
isso um programa Java pode ser executado em qualquer sistema operacional.
Java no tem uma boa performance, se comparada as outras linguagens com
cdigo nativo, devido essa razo a mquina virtual possui compiladores
chamados de "just in time" que compilam os bytecodes trazendo uma melhoria
significativa para os programas.
Em geral, os programas Java passam por cinco fases: edio,
compilao, carregamento, verificao e execuo. O programa criado em um
editor e armazenado com o nome de (.java) ao final, por sua vez o compilador cria
os bytecodes e os armazena em discos, o arquivo recebe o (.class) ento o
carregador de classes l os arquivos (.class) que contm os bytecodes a partir do
disco e coloca esses dados na memria. Ento o verificador confirma se todos os

25

bytecodes so validos e no violam restries de segurana do Java, e para


executar o programa a JVM (Java Virtual Machine) l os bytecodes e os compila
para uma linguagem que o computador possa entender.
2.2.6 MECANISMO DE AUXLIO
A linguagem de programao Java possui um mecanismo chamado
Multithreading, sua funcionalidade de executar mltiplas rotinas ou mesmo
tempo, possibilitando sua sincronizao, onde essas rotinas funcionam como se
fosse um fluxo de execuo denominado de thread, que so um grande e
importante recurso da programao para aplicaes mais sofisticadas e
elaboradas. O autor declara.
Que ao definir mais de uma thread em um mesmo programa, as tarefas
que elas contm podem ser executadas de maneira simultnea e
independente umas das outras. Esse recurso chamado multi-threading,
ou multi-escalonamento e possibilita a realizao de mltiplas atividades
em paralelo, proporcionando melhoras evidentes no desempenho,
principalmente de tarefas mais complexas. eficaz em computadores
com um nico processador, no entanto possvel construir
computadores ou sistemas de computadores com muitos processadores
que trabalham em paralelo, maximizando ainda mais o desempenho
(Deitel,2010)

2.3 USO DO BANCO DE DADOS / MYSQL


Segundo Korth (2006, p.2) banco de dados uma coleo de dados
inter-relacionados, representando informaes sobre um domnio especfico, ou
seja, sempre que for possvel agrupar dados afim que obtenha informaes que
se relacionam e tratam de um mesmo assunto, posso dizer que tenho um banco
de dados.
O mesmo autor diz que o banco de dados a parte mais importante para
o bom funcionamento do sistema, logo a utilizao do SGBD deve ser pensada na
melhor maneira de se relacionar com o software e suas ferramentas. Em funo
das caractersticas como facilidade de manuseio, facilidade de instalao,
tamanho e velocidade presentes no MySQL e tambm sua verso livre (open

26

source), foi a escolha mais interessante para a implementao do banco de


dados.
Fornecido pela empresa MySQL AB disponvel na maior parte do mundo
atravs da internet, permite conectar-se ao MySQL Server e executar queries de
SQL, qual quer programa que saiba se comunicar com o MySQL Server um
cliente.
Segundo Elmasri e Navathe (2002), o compilador DDL processa as
definies de esquemas especficos e armazena as descries dos esquemas
(metadados) no catlogo do SGBD. O catlogo inclui informaes como os nomes
e os tamanhos dos arquivos, nomes e tipos de dados dos itens de dados,
detalhes de armazenamento de cada arquivo, informaes de mapeamento entre
esquemas e restries. Alm disso, o catlogo armazena muitas outras
informaes de grande importncia para o SGBD e pode ento utilizar as
informaes do catlogo de acordo com sua necessidade.
2.3.1 ORGANIZAO DO BANCO DE DADOS
Quando se implementa um banco de dados deve haver um cuidado com a
organizao dos dados pois, muitas das vezes criamos alguma coisa e
executamos sem se dedicar tempo e ateno adequado ao projeto. Essa falta de
cuidado leva frequentemente a reprojetos e reimplementaes, o que torna esse
processo complexo e demorado. Por isso,
Sistema gerenciador de banco de dados so gabinetes preenchidos
eletronicamente que ajudam indivduos e organizaes a gerenciar a
informao em massa que eles processam a cada dia. (WILLIANS, 2004,
p.9)

Seguindo as vises lgicas de Willians (2004, p.5), concepo dos dados


so formados por trs componentes de um SGBD:

Linguagem de definio de dados (especifica contedos, estrutura a base


de dados e define os elementos de dados);

27

Linguagem de manipulao de dados (para poder alterar os dados na


base); e

Dicionrio de dados (guardas definies de elementos de dados e


respectivas caractersticas descreve os dados, quem os acessa, etc).

2.3.3 MODELAGEM DO BANCO DE DADOS


A modelagem, segundo Korth (2006), deve seguir uma normalizao no
momento de elaborao, o mesmo autor criou um modelo de entidade e
relacionamento para o auxlio da elaborao do banco de dados. Na
implementao, um banco de dados deve primeiramente saber como as
informaes iro ser armazenadas, e a forma que as tabelas iriam se relacionar
entre si. Para dar-se incio ao desenvolvimento do banco de dados necessrio
utilizar uma tcnica de modelagem chamada de modelo de entidaderelacionamento, que no nada mais que a representao abstrata dos aspectos
especficos sobre a realidade, e que se permite compreender um conceito ou
objeto antes de sua existncia real. O modelo deve ser construdo com objetivos
preestabelecidos e bem definidos que determinem os aspectos mais importantes
a serem representados de forma que fique o mais fielmente possvel da realidade
atual.
2.3.4 VANTAGENS DE SE USAR O BANCO DE DADOS
Segundo Korth (2006), o SGBD gerncia todo o controle dos dados
reduzindo ao mximo a redundncia de dados. No processamento tradicional de
arquivos cada sistema tinha seu prprio conjunto de arquivos e dados e seus
prprios usurios utilizando aquele recurso. Desta forma, ocorria muitas
redundncias de dados que prejudicam o sistema.
O autor ainda afirma que com a utilizao do sistema gerenciador de
banco de dados todos os usurios podem ter acesso aos dados ao mesmo tempo
e ligando mltiplas aplicaes ao mesmo tempo alm de assegurar os recursos e
atualizaes. Porm a principal caracterstica e o isolamento dos dados a
segurana da informao atravs de limites de recursos no qual apenas um

28

administrador DBA teria o acesso a todo o banco de dados. O DBA tambm seria
o responsvel pela segurana e suporte na criao de contas para especificar as
restries tanto no acesso aos dados quanto ao uso de softwares inerentes ao
SGBD.
2.3.5 SGBD RELACIONAIS
Segundo Patrick (2001), o SGBD pode ser divido em partes, primeira
definida pela estrutura de dados simples que so formadas por tabelas
bidimensionais cujo os elementos so itens de dados. Permitindo assim um alto
grau de independncia de dados, ou seja, um banco de dados e formados por
tabelas e que se interagem.
Outra parte em que est dividido modelo relacional, no qual esto
acostumamos a trabalhar tambm pode ser dividido em uma fundao slida para
a consistncia de dados pois so mantidos de maneira uniforme por regras de
integridade, o projeto de banco de dados auxiliado pelo processo de
normalizao que elimina anomalia de dados.
Terceira caracterstica do modelo relacional a ordenao das relaes
orientadas a conjuntos, essa caracterstica levou ao desenvolvimento de
linguagens poderosas baseadas na teoria dos conjuntos.
Valduriez(2001), define um banco de dados relacional como uma coleo
estruturada de dados relacionados a alguns fenmenos reais que estamos
tentando modelar.
A arquitetura de SGBDs tem seguido tendncia semelhante aquelas dos
sistemas de computao em geral. Muitas aplicaes Web utilizam uma
arquitetura chamada arquitetura de trs camadas, que acrescenta uma camada
intermediaria entre o cliente e o servidor de banco de dados, (ELMASRI E
NAVATHE, 2002).
2.4 ENGENHARIA DE SOFTWARE
Pressman (2011, p. 21) aborda o conceito de software, dizendo o
seguinte:

29

Software de computador o produto que profissionais de software


desenvolvem e ao qual do suporte em longo prazo. Abrangem
programas executveis em um computador de qualquer parte ou
arquitetura, contedos (apresentadas medida que os programas so
executados), informaes descritivas tanto na forma impressa (hard
copy) como na virtual, abrangem praticamente qualquer mdia eletrnica.
A engenharia de software abrange um processo, um conjunto de
mtodos (prticas) e um leque de ferramentas que possibilitam aos
profissionais desenvolverem software de altssima qualidade.
(PRESSMAN 2011, p. 21).

O mesmo autor ainda afirma que software importante porque afeta a


quase todos os aspectos de nossas vidas e tornou-se pervasivo (incorporado) no
comrcio, na cultura e em nossas atividades cotidianas. A engenharia de software
importante porque ela nos capacita para o desenvolvimento de sistemas
complexos dentro do prazo e com alta qualidade.
Hoje em dia, dez grandes categorias de software apresentam desafios contnuos
para os engenheiros de software:
* Software de sistema conjunto de programas feito para atender a outros
programas;
* Software de aplicao programas sob medida que solucionam uma
necessidade especfica de negcio;
* Software cientfico/de engenharia tem sido caracterizado por algoritmos
numbersurching (para processamento numrico pesado).
* Software embutido Residente num produto o sistema utilizado para
programar e controlar caractersticas e funes para o usurio final e para o
prprio sistema.
* Software para linha de produo Projetado para prover capacidade especifica
de utilizao por muitos clientes diferentes.
* Aplicaes para Web chamada de Webapps, essa categoria do software
centralizada em redes abarca uma vasta gama de aplicaes.
* Software de inteligncia artificial - faz uso de algoritmos no numricos para
solucionar problemas complexos que no so passiveis de computao ou de
anlise direta.

30

* Computao mundial aberta o rpido crescimento de redes sem fio pode, em


breve, conduzir a uma verdadeira computao distribuda e pervasiva (ampliada,
compartilhada e incorporada nos ambientes domsticos e comerciais).
* Netsourcing (recursos via internet) a internet est se tornando, rapidamente,
tanto um mecanismo computacional, como um provedor de contedo.
* Software aberto uma tendncia crescente que resulta na distribuio de
cdigo-fonte para aplicaes de sistemas (por exemplo, sistemas operacionais,
bancos de dados e ambientes de desenvolvimento).
Segundo Sommerville (2007), os requisitos de software de um sistema
so descries dos servios fornecidos pelo sistema e as suas restries
operacionais. Esses requisitos refletem as necessidades dos clientes de um
sistema que ajuda a resolver algum problema. O processo de descobrir, analisar,
documentar e verificar esses servios e restries chamado de engenharia de
requisitos (RE Requeriments Engineering).
Ainda segundo Sommerville (2007), os requisitos de software so
divididos em requisitos de usurio, que so declaraes, em uma linguagem
natural com diagramas, de quais servios so esperados do sistema e as
restries sob as quais ele deve operar.
Sommerville

(2007),

afirma

que

requisitos

de

sistema

definem,

detalhadamente, as funes, os servios e as restries operacionais do sistema.


O documento de requisitos de sistema (s vezes chamado de especificao
funcional) deve ser preciso. Ele deve definir exatamente o que ser
implementado. Pode ser parte do contrato entre o comprador do sistema e os
desenvolvedores de software.
Requisitos funcionais: So declaraes de servios que o sistema deve
fornecer como o sistema deve reagir a entradas especificas e como o sistema
deve se comportar em determinadas situaes. Em alguns casos, os requisitos
funcionais podem tambm estabelecer explicitamente o que o sistema no deve
fazer, (SOMMERVILLE, 2007).
Requisitos no funcionais: So restries sobre os servios ou as funes
oferecidos pelo sistema. Eles incluem restries de timing, restries sobre o
processo de desenvolvimento e padres. Os requisitos no funcionais aplicam-se

31

frequentemente, ao sistema como um todo. Em geral, eles no se aplicam s


caractersticas ou servios individuais de sistema, (SOMMERVILLE, 2007).
Ainda define que requisitos de domnio: So requisitos provenientes do
domnio da aplicao do sistema e que refletem as caractersticas e as restries
desse domnio. Podem ser requisitos funcionais ou no funcionais.
Os requisitos de um sistema de software definem o que o sistema deve
fazer e as restries sobre suas operaes e sua implementao. O processo de
engenharia de requisitos inclui um estudo de viabilidade, licitao e anlise,
especificao, validao e gerenciamento de requisitos. O processo de
gerenciamento de requisitos inclui o planejamento de gerenciamento, no qual as
polticas e procedimentos de gerenciamento de requisitos so projetados, e o
gerenciamento de mudanas, no qual voc deve analisar as mudanas de
requisitos propostas e avaliar seu impacto, (SOMMERVILLE, 2007).
2.4.1 QUALIDADE DE SOFTWARE
Pressman (2011), diz que o problema da gesto da qualidade no o que
as pessoas no sabem a seu respeito. Mas sim, o que eles pensam que sabem.O
mesmo ainda afirma que alguns desenvolvedores de software continuam a
acreditar que a qualidade de software algo sobre o qual comea a
preocupar depois que o cdigo gerado. Nada poderia estar to distante
da verdade. A garantia da qualidade de software, SQA, muitas vezes denominada
gesto da qualidade uma atividade universal aplicada em toda a gesto de
qualidade.
2.4.2 ELEMENTOS DE GARANTIA DA QUALIDADE DE SOFTWARE
Segundo Pressman (2011), a garantia da qualidade de software engloba
um amplo espectro de preocupaes e atividades que se concentram na gesto
da qualidade de software e que podem ser sintetizadas das seguintes maneiras:
* Padres O IEEE, a ISO e outras organizaes de padronizaes produzam
uma ampla gama de padres para engenharia de software e os respectivos
documentos.

32

* Revises e auditorias As revises tcnicas so uma atividade de controle de


qualidade realizada por engenheiros de software para engenheiros de software.
Seu intuito o de revelar erros.
* Testes Os testes de software so uma funo de controle de qualidade com
um objetivo principal descobrir erros. O papel da SQA garantir que os testes
sejam planejados apropriadamente e conduzidos eficientemente de modo que se
tenha a maior probabilidade possvel de alcanar seu objetivo primrio.
* Coleta e anlise de erros/defeitos A nica forma de melhorar medir o
desempenho. A SQA rene e analisa dados de erros e defeitos para melhor
compreender, com os erros, so introduzidos e quais atividades de engenharia de
software melhor se adquam para sua eliminao.
* Gerenciamento de mudanas As mudanas so um dos aspectos mais
negativos de qualquer projeto de software, se no forem administradas
apropriadamente, podem gerar confuso, e confuso quase sempre leva a uma
qualidade inadequada.
* Educao Toda organizao de software quer melhorar suas prticas de
engenharia de software. Um fator fundamental para o aperfeioamento a
educao dos engenheiros de software, seus gerentes e outros interessados. A
organizao de SQA assume a liderana no processo de aperfeioamento do
software e um proponente fundamental e patrocinador de programas
educacionais.
* Administrao da segurana Com o aumento dos crimes cibernticos e novas
regulamentaes governamentais referentes privacidade, toda organizao de
software deve instituir polticas que protejam os dados em todos os nveis,
estabelecer proteo atravs de firewalls para as aplicaes da Internet
(Webapps) e garantir que o software no tenha sido alterado internamente, sem
autorizao.
* Proteo O fato de o software ser quase sempre um componente fundamental
de sistemas que envolvem vidas humanas (por exemplo, aplicaes na indstria
automotiva ou aeronutica), o impacto de defeitos ocultos pode ser catastrfico. A
SQA pode ser responsvel por avaliar o impacto de falhas de software e por
iniciar as etapas necessrias para reduo de riscos.

33

* Administrao de riscos Embora a anlise e a reduo de riscos seja


preocupao dos engenheiros de software, o grupo de SQA garante que as
atividades de gesto de riscos sejam conduzidas apropriadamente e que planos
de contingncia relacionados a riscos tenham sido estabelecidos.
O mesmo autor ainda afirma que alm de cada uma dessas preocupaes
a atividades, a SQA trabalha para garantir que atividades de suporte ao software
(por exemplo, manuteno, suporte on-line, documentao e manuais) sejam
realizadas ou produzidas tendo a qualidade como preocupao dominante.
2.5 PADRES DE PROJETO
Padres de projeto so solues para os problemas recorrentes dos
projetos elaborados. Eles so utilizados para melhorar a organizao interna do
cdigo e facilitar sua manuteno e, principalmente, sua extenso.
2.5.1 CONCEITO
Baseado nos conceitos de Freeman et al (2007) os padres de projeto
so solues reutilizvel para um problema que ocorre com frequncia dentro do
projeto de software, em um projeto que no foi finalizado e que pode ser
transformado ou modificado, um modelo de como resolver um problema que
pode ser usado em muitas situaes diferentes, padres so melhores prticas
formalizadas que o programador utiliza para resolver problemas comuns quando
projeta uma aplicao ou sistema, padres de projeto orientados a objeto
normalmente mostram relacionamentos e interaes entre classes ou objetos, ele
no especifica as classes ou objetos da aplicao final que esto envolvidas.
Um padro de projeto definido por:

Nome: uma descrio da soluo, um nome permiti definir o


vocabulrio a ser utilizado pelos projetistas e desenvolvedores em um

nvel mais alto de abstrao.


Exemplo: uma ou mais figuras, diagramas ou descries que ilustrem
um prottipo de aplicao.

34

Contexto: a descrio das situaes sob as quais o padro se aplica


todo padro deve relatar de maneira clara a qual problema ele deve
ser aplicado, ou seja, quais so os problemas que quando inserido em

um determinado contexto o padro conseguir resolve-lo.


Problema: uma descrio das foras e restries envolvidas e como

elas interagem.
Soluo: relacionamentos estticos e regras dinmicas descrevendo
como construir artefatos de acordo com o padro, frequentemente
citando variaes e formas de ajustar a soluo segundo as
circunstncias.

Os padres de projeto visam facilitar a reutilizao de solues de


desenho - isto , solues na fase de projeto do software e estabelecem um
vocabulrio comum de desenho, facilitando comunicao, documentao e
aprendizado dos sistemas de software.
Christopher Alexander (1977/1979) estabelece que um padro deva ter,
idealmente, as seguintes caractersticas:

Encapsulamento: um padro encapsula um problema ou soluo bem


definida. Ele deve ser independente, especfico e formulado de
maneira a ficar claro onde ele se aplica.

Generalidade: todo padro deve permitir a construo de outras


realizaes a partir deste padro.

Equilbrio: quando um padro utilizado em uma aplicao, o


equilbrio d a razo, relacionada com cada uma das restries
envolvidas, para cada passo do projeto. Uma anlise racional que
envolva uma abstrao de dados empricos, uma observao da
aplicao de padres em artefatos tradicionais, uma srie convincente
de exemplos e uma anlise de solues ruins ou fracassadas pode
ser a forma de encontrar este equilbrio.

Abstrao: os padres representam abstraes da experincia


emprica ou do conhecimento cotidiano.

Abertura: um padro deve permitir a sua extenso para nveis mais


baixos de detalhe.

35

Combinatoriedade: os padres so relacionados hierarquicamente.


Padres de alto nvel podem ser compostos ou relacionados com
padres que endeream problemas de nvel mais baixo.

Existem varias formas de estruturar o cdigo e o projeto da sua aplicao,


geralmente prudente seguir padres comuns, pois isso ir fazer com que seu
cdigo seja mais fcil de manter e mais fcil de ser entendido por outros
desenvolvedores, todo o trabalho foi desenvolvido utilizando o padro modelview-controller (MVC), segue abaixo apresentao de alguns modelos existentes:
Padro Factory ou Fbrica: um dos padres de design mais utilizados,
atravs dele uma classe simplesmente cria o objeto que voc gostaria de usar,
Esse cdigo usa uma Factory para criar o objeto do tipo Automobile, ou seja,
voc no precisa instanciar um objeto para usar o mtodo de criao, (FREEMAN
ET AL, 2007).
Padro Singleton (nica Instancia): til quando voc precisa garantir
que somente uma instncia da classe seja criada em todo o ciclo de vida da
requisio em uma aplicao web. Isso tipicamente ocorre quando voc tem
objetos ou um recurso compartilhado (como uma lista de eventos), (FREEMAN ET
AL. 2007).
Padro Strategy (Estratgia): com este padro voc encapsula famlias
especficas de algoritmos permitindo com que a classe cliente responsvel por
instanciar esse algoritmo em particular no necessite de conhecimento sobre sua
implementao atual, (FREEMAN ET AL. 2007).
}
public function createDatabase() {
$this->conect();
if (!mysql_query('CREATE DATABASE ' . $this->db . ' CHARACTER SET utf8
COLLATE utf8_general_ci;')) {
echo '<script>alert("Nao foi possivel criar o banco ' . $this->db . ' em ' .
$this->host . ' com o usuario ' . $this->user . '. Mensagem: ' . mysql_error() .
'");</script>';
exit;
}
$this->close();
}

36

3 PERFIL DA ORGANIZAO
3.1 CARACTERSTICAS INTERNAS DA ORGANIZAO
Nos dias de maior procura por aulas que geralmente so segunda, quarta
e sexta o personal trainer comea a dar suas aulas por volta das 10 horas da
manh com durao de 1 hora por aula, e agenda as demais de acordo com as
outras aulas agendadas 11:10 e assim por diante. Este profissional j tem uma
ordem das atividades pr-programada para o dia, que e feito pensando nos seus
clientes e objetivos do mesmo, porem a ordem dos exerccios vai se adequando
de acordo com a disponibilidades dos equipamentos. No dia a dia o personal ele
necessita de uma grade de horrios para planejar as rotinas dos exerccios pois
se os equipamentos do exerccio B estiver ocupado ele j altera para o exerccio
G que e do mesmo grupamento muscular.
Se um determinado aluno precisa perder peso ele utiliza um sistema de
treinamento que aumente a sua frequncia cardaca e os equipamentos como:
bicicleta, esteira ou ento faz aulas de ginasticas como: jump, dana, luta, circuito,
steep (uma aula que se faz em cima de uns caixotes). J para ganho de massa
muscular o treino e menos intenso, as atividades giram em torno de musculao e
circuito de musculao.
Este profissional utiliza de um projeto de alimentao especifica para
situao. Para reduo de peo ele orienta reduzir os carboidratos, massas,
bebida alcolica e diminuir as refeies aps as 18 horas. J para os clientes que
querem um ganho de massa muscular a orientao e o oposto, fazer uma maior
ingesto de carboidratos e protenas. Somente aps o ganho mximo de massa
muscular ingerindo comida que e liberado o uso de suplementos alimentares,
caso o aluno no tenha nenhum aumento de massa muscular mesmo aps utilizar
de recursos como suplementos ele e orientado e procurar um nutricionista.
3.1.2 COLABORADORES
O personal trainer Leandro Fabino utiliza vrias academias para dar suas
aulas algumas delas como: fitness sensations hull, champion fitness, speed

37

academia alm disto o mesmo se apoia em alguns parques para complementar


suas aulas parque Areio e Cascavel so os mais utilizados.
O personal trainer pretende ainda abrir sua prpria academia. Com o
tempo est reunindo recursos para comprar os equipamentos junto com seus
scios Diego Oliveira que tambm e formado em educao fsica e trabalha nas
academias das vizinhanas. Ambos pretendem abrir a "Fabino fitness".
3.1.3 REGRAS DE NEGOCIO
Durante este trabalho algumas regras de negcio so impostas pelas
academias que o mesmo utiliza para poder dar suas aulas pois algumas delas
cobram uma taxa para se poder trabalhar, essas taxas variam de R$ 200,00 a
R$400,00 por aluno , mais a algumas que optam por taxas anuais de at R$
1.200,00 e algumas cobram o uso de uniforme diferenciado dos outros que j
trabalham no estabelecimento mas a outras que no cobram nenhum nus para o
personal trainer, porem todas elas s liberam o aluno que esteja cadastrados na
academia.
No caso do personal trainer utilizar uma determinada academia para
trabalhar e necessrio que alm das taxas e regulamentos faa um registro. Este
registro e feito em todas as academias, os documentos exigidos so a cpia do
CRAFT um documento que autoriza o profissional a dar aulas.
3.2 RELACIONAMENTO COM CLIENTE
O relacionamento com o cliente geralmente e feito por indicaes de
amigos ou divulgaes nas redes sociais ou at nas prprias academias que o
personal trainer j tenha uma espcie de convnio. O primeiro contato feito por
telefone. Posteriormente a esse contato agendada uma aula experimental para
o profissional conhecer os objetivos do cliente e passar as informaes de acordo
com o que o mesmo procura.

38

3.3 RELAO COM OS COLABORADORES E SERVIOS


O personal trainer diz no ter muito contado com os colaboradores pois
ele no tem nenhum tipo de responsabilidade para com as academias, porem ele
sempre que pode tenta criar vnculos com os funcionrios das academias.
Este personal trainer geralmente cobra por volta de R$ 30,00 a R$ 80,00
por hora aula sem contar as taxas extras da academia, variando de acordo com o
local e situao do cliente. Ele tem mdia de 3 aulas por semana e 5 alunos nos
principais dias de segunda, quarta e sexta, O faturamento chega entorno de R$
150,00 por dia nos dias mais procurados.

39

4 SOLUO PROPOSTA
4.1 ANLISE DE REQUISITOS
Hoje quando se pensa em desenvolvimento de software, pode parecer
uma tarefa fcil levando em conta todos os recursos e ferramentas que so
oferecidos no mercado para a automatizao de uma empresa. Segundo
(SOMMERVILLE, 2007) muita gente associa o termo software aos programas de
computadores sem levar em conta que um software no composto somente
pelo programa em si, mas tambm por toda documentao associada ao mesmo
e aos dados de configuraes necessrios para fazer com que esses programas
operem corretamente. Mesmo tendo em mos um projeto para uma empresa de
mdio porte, a elaborao do mesmo deve ser realizada de forma concreta, tendo
como objetivo alcanar um nvel mais elevado em termos de qualidade.
Dessa forma, durante a elaborao deste projeto foram seguidas vrias
atividades de validao e reviso da documentao e demais artefatos de projeto
de modo a garantir qualidade nas atividades e tarefas que estavam sendo
realizadas.
Segundo (SOMMERVILLE, 2007), a engenharia de software se ocupa de
todos os aspectos da produo de um de software, desde os estgios iniciais de
especificaes do sistema at a manuteno desse sistema, depois que ele
entrou em operao.
Em razo da aplicao de mtodos e tcnicas de engenharia de software
espera-se que as solues sejam obtidas de forma mais rpida e coerente
alcanando assim resultados mais satisfatrios no final desse projeto. O projeto
foi elaborado para uma empresa que presta servio de musculao e fitness. Os
principais objetivos do projeto so ajudar a empresa, principalmente, na
organizao dos procedimentos e na comunicao interna ente seus funcionrios
e externa com seus clientes. Acredita-se que esses objetivos, quando alcanados
venham a contribuir para o crescimento da empresa como da vontade do
proprietrio.
Este projeto est organizado em duas macro sees. Alm das sees de
introduo e consideraes finais do trabalho, a seo um discute sobre

40

engenharia de requisitos e a seo dois apresenta a aplicaes dessa abordagem


de engenharia de requisitos em contexto de aplicao, destacando a modelagem
do diagrama de classes e diagrama de casos de uso.
Para a elaborao das funcionalidades deste sistema foi feita um
levantamento de requisitos com o objetivo de coletar os dados necessrios para a
construo

projeto.

Depois

de

feita

esta

anlise

das

necessidades

do personal trainer e identificado todos os requisitos funcionais e no funcionais,


pde-se dar incio soluo do problema identificado.
Como diz Pressman(2011) em seu livro Engenharia de Software Na
perspectiva do processo de software, a engenharia de requisitos uma ao
importante que se inicia durante a atividade de comunicao e continua na
modelagem. Os requisitos que foram identificados so:
Requisitos Funcionais: Possibilitar que o usurio seja identificado no
sistema atravs de uma tela de login, cadastrar clientes, realizar buscas, fazer
alteraes e excluses, realizar clculos de composio corporal, realizar testes
de classificaes de risco, anamneses, questionrios de par-Q e relatrios
financeiros.
Requisitos No Funcionais: Fcil portabilidade devido instalao da
Java Virtual Machine, segurana, integridade dos dados, interface amigvel,
capacidade de armazenamento dos dados, interoperabilidade: ter facilidade de
se comunicar com outros sistemas.
4.1.2 CONTEXTO DE APLICAO
Com a engenharia de requisitos realizado o levantamento de requisitos,
onde so levantados os requisitos funcionais e no funcionais do sistema, os
problemas existentes na empresa so identificados e descritos para que o sistema
possa supri-los, as solues alternativas so apresentadas aos donos e futuros
usurios do sistema para escolha de um sistema especfico para a empresa.
Impactos viro com a implantao do novo sistema, as principais mudanas sero
no ambiente fsico com a implantao de maquinrio especfico e o treinamento
dos usurios para a adaptao a nova forma de trabalho.

41

4.1.2.3 LEVANTAMENTO DE REQUISITOS


No levantamento de requisitos feita a definio de requisitos do sistema
que segundo (SOMMERVILLE, 2007), se destina a coletar as caractersticas do
sistema como um todo. Esse processo envolve vrias consultas com os clientes e
usurios finais. Essa fase de definio de requisitos, normalmente, se concentra
em derivar trs tipos de requisitos: requisitos funcionais, propriedades do sistema
e caractersticas que o sistema no deve possuir funcionais e no funcionais do
sistema, com uma maior abrangncia do que o usurio final desejava.
Essa seo mostra a descrio do sistema atual, com os problemas
existentes do personal trainer, os desejos do usurio, as solues alternativas
apresentadas pelos alunos, a alternativa escolhida pelo personal trainer e, por
ltimo, os diagramas de classe e caso de uso. Esse levantamento de requisitos foi
realizado pelos alunos envolvidos no projeto, atravs de entrevistas com o
personal trainer sobre os processos de atendimento, administrativo e desejos do
usurio quanto ao desenvolvimento de um sistema computacional.
4.1.1 DESCRIO DO SISTEMA OU PRODUTO
Aps o levantamento de requisitos j ser possvel realizar a descrio dos
atores que so quem ir interagir com o sistema, a lista de eventos que o sistema
realizar como cadastro de cliente, o diagrama de caso de uso vira para
demonstrar os eventos do sistema graficamente como seus cursos normais e
alternativos e tambm o diagrama de classe que mostra os conjuntos de classes,
interfaces e colaborao e seus respectivos relacionamentos existentes no
software.
4.1.3.1 DEFINIO DOS ATORES
Os atores so quem interage com o sistema, mas sobre o qual no se tem
controle eles esto fora da influncia do sistema, ou seja, os atores tem um papel
externo e so quem do incio aos casos de uso. Tipicamente os atores
representam o papel que o ser humano, outro processo, outro sistema ou at

42

mesmo um dispositivo de hardware desempenha ao interagir com o sistema.


Cada ator corresponde a um papel especfico, uma pessoa que desempenha
diferentes papis nas interaes com o sistema representado por diferentes
atores, por outro lado, diversas pessoas que desempenham o mesmo papel
correspondem a um nico ator. So eles quem utiliza o sistema, fiscalizam o
sistema, fornecem os dados e usam as informaes do sistema (MATOS, 2002).
O ator usurio representa qualquer um dos demais atores do sistema.
4.1.3.2 LISTA DE EVENTOS DO SISTEMA
A lista de eventos mostra as funcionalidades do sistema que vai de efetuar
login, cadastros e gerao de relatrios. Na sequncia, foram apresentados os
eventos que sero atendidos pelo sistema.
O Smart Fit foi projetado e desenvolvido com o objetivo de auxiliar de
maneira eficiente o personal trainer em suas atividades cotidianas e tem como
funcionalidades:

Evento 1 Efetuar Login

Evento 2 Cadastrar Usurio

Evento 3 Cadastrar Cliente Cadastrar Matrcula

Evento 5 Cadastrar Medida

Evento 6 Cadastrar Pacote

Evento 7 Receber Mensalidade

Evento 8 Gerar Relatrio de Usurio

Evento 9 Gerar Relatrio de Cliente

Evento 10 Gerar Relatrio de Recebimento

4.1.2 ESPECIFICAO DE REQUISITOS DO SISTEMA OU PRODUTO


Para a soluo dos problemas mencionados anteriormente, os proprietrios
desejam um sistema operacional e gerencial com cadastros de clientes e medidas
e que permita o controle das mensalidades pagas por todos os alunos, mostrando

43

a situao dos mesmos, ou seja, se o aluno est ativo ou no na academia. Outra


vontade o usurio a gerao de relatrios para o acompanhamento tanto
financeiro quanto de evoluo dos alunos. Os proprietrios necessitam que o
sistema viabilize o cadastro de clientes e que contenha pesquisa por nomes
deixando assim o atendimento mais dinmico e rpido.
O sistema tambm deve conter o cadastro de medidas para que o
professor consiga fazer as anotaes necessrias sobre os alunos, tendo assim
fcil acesso s informaes tcnicas. Na viso do cliente, a construo de um
sistema com essas caractersticas deixar os alunos mais satisfeitos com o
atendimento disponibilizado pela academia.
O sistema dever disponibilizar relatrios dirios, mensais ou anuais para o
gerente sobre as mensalidades e o professor tambm ter a acesso a relatrios
sobre a evoluo dos alunos. Esses relatrios podero ser impressos, caso seja
de interesse do aluno. Outro desejo do proprietrio da academia que o sistema
tenha uma interface simples, para que o sistema seja de rpido aprendizado e
fcil manuseio.
Devido a isto, o sistema foi dividido em duas partes: parte administrativa e
parte de gerenciamento das atividades do personal trainer. A partir deste
momento foi elaborado no projeto as ferramentas e funes de cada parte e quais
seria as suas atribuies. Segue abaixo um fluxograma das telas da parte
administrativa e uma breve exibio de como seus campos se relacionam.
Na parte de gerencia das atividades do personal trainer o sistema conta
com funes que realizam clculos e processa as informaes, dando maior
auxilio nas atividades rotineiras do usurio. O ponto forte deste sistema a
organizao dos projetos e os clculos realizados pelo usurio, esta parte de
clculos feita na parte relacionada a de avaliao fsica, esta tela foi projetada
para ser o ponto chave e o diferencial do sistema, pois possui as ferramentas
solicitadas pelo personal trainer e as analisada pelo acadmicos para fornecer
maior controle e agilidade dos processos do usurio. Outra tela muito importante
no sistema Treino, essa parte e tipo de descrio detalhada da rotina de cada
cliente e seus objetivos.
A organizao de cada aba foi projetada a partir da anlise de requisitos.
Este sistema foi desenvolvido de forma simples, para que qualquer usurio possa

44

utiliza-lo sem muitos problemas dispensando assim a necessidade de um estudo


profundo sobre a rea, ou as utilidades desse sistema. Segue abaixo um
fluxograma detalhando a parte de gerenciamento das atividades do personal
trainer.
4.1.3 ESPECIFICAO DE REQUISITOS DO SISTEMA
Tabela 1: Requisito do Sistema Login
Fonte: Elaborada pelos Acadmicos.

Requisito do Sistema Login


Os dados que sero registrados na
tabela Login so:

1.1 Cdigo do Login;


1.2 Usurio;
1.3 Senha.

Tabela 2: Requisito do Sistema Estado


Fonte: Elaborada pelos Acadmicos.

Requisito do Sistema - Estado


Os dados que sero registrados na
tabela Estado so:

2.1 Cdigos da cidade;


2.2 Nomes;
2.3 Unidade federativa.

Tabela 2: Requisito do Sistema Cidade


Fonte: Elaborada pelos Acadmicos.

Requisito do Sistema - Cidade


Os dados que sero registrados na
tabela Cidade so:

3.1 Cdigo cidade;


3.2 Nomes;
3.3 Cdigo do Estado:
3.4 CEP;
3.5 Rua;
3.6 Quadra;
3.7 Lote;
3.8 Bairro.

Tabela 3: Requisito do Sistema Cliente


Fonte: Elaborada pelos Acadmicos.

Requisito do Sistema - Cliente


Os dados que sero registrados na
tabela Cliente so:

4.1 Cdigos cliente:


4.2 CPF;
4.3 RG;
4.4 Treino;
4.5 Telefone;
4.6 Rua;
4.7 Quadra;

45

4.8 Lote;
4.9 Bairro;
4.10 CEP;
4.11 Cidade;
4.12 Personal Trainer;
4.13 E-mail.
Tabela 4: Requisito do Sistema Permetros
Fonte: Elaborada pelos Acadmicos.

Requisito do Sistema - Permetros


Os dados que sero registrados na
tabela Permetros so:

5.1 Cdigo Permetros;


5.2 Cliente;
5.3 Permetros;
5.4 Dimetros.

Tabela 5: Requisito do Sistema Composio Corporal


Fonte: Elaborada pelos Acadmicos.

Requisito do Sistema Composio


Corporal
Os dados que sero registrados na
tabela Composio Corporal so:

6.1 Cdigo da Composio Corporal;


6.2 Dobras Cutneas;
6.3 Resultado.

Tabela 6: Requisito do Sistema IMC


Fonte: Elaborada pelos Acadmicos.

Requisito do Sistema - IMC


Os dados que sero registrados na
tabela IMC so:

7.1 Cdigo do IMC;


7.2 Cliente;
7.3 Clculos.

Tabela 7: Requisito do Sistema Anamnese


Fonte: Elaborada pelos Acadmicos.

Requisito do Sistema Anamnese


Os dados que sero registrados na
tabela Anamnese so:

8.1 Cdigo Anamnese;


8.2 Cliente;
8.3 Anamnese;
8.4 Doenas Anteriores;
8.5 Anamnese Nutricional;
8.6 Anamnese de Atividade Fsica;
8.7 Atividades fsicas preferidas;
8.8 Observaes.

Tabela 8: Requisito do Sistema Avaliao de Risco


Fonte: Elaborada pelos Acadmicos.

Requisito do Sistema Avaliao de

46

Risco
Os dados que sero registrados na
tabela Avaliao de Risco so:

9.1 Cdigo da Avaliao de Risco;


9.2 Cliente;
9.3 Avaliao.

Tabela 9: Requisito do Sistema Par-Q


Fonte: Elaborada pelos Acadmicos.

Requisito do Sistema Par-Q


Os dados que sero registrados na
tabela Par-Q so:

10.1 Cdigo Par-Q;


10.2 Cliente;
10.3 Pergunta 1;
10.4 Pergunta 2;
10.5 Pergunta 3;
10.6 Pergunta 4;
10.7 Pergunta 5;
10.8 Pergunta 6;
10.9 Pergunta 7.

Tabela 10: Requisito do sistema Treino


Fonte: Elaborada pelos Acadmicos.

Requisito do Sistema Treino


Os dados que sero registrados na
tabela Treino so:

11.1 Cdigo do Treino;


11.2 Cliente;
11.3 Prescrio.

Tabela 11: Requisito do Sistema Personal Trainer


Fonte: Elaborada pelos Acadmicos.

Requisito do Sistema Personal


Trainer
Os dados que sero registrados na
tabela Personal Trainer so:

12.1 Cdigo usurio;


12.2 Nome;
12.3 Login;
12.4 Senha;
12.5 Cdigo Cliente;

Tabela 12: Requisito do Sistema Financeiro


Fonte: Elaborada pelos Acadmicos.

Requisito do Sistema Financeiro


Os dados que sero registrados na
tabela Financeiro so:

13.1 Cdigo do Financeiro;


13.2 Oramento;
13.3 Controle.

47

Tabela 13: Requisito do Sistema Relatrio


Fonte: Elaborada pelos Acadmicos.

Requisito do Sistema Relatrio


Os dados que sero registrados na
tabela Relatrio so:

14.1 Cdigo Relatrio;


14.2 Cdigo Cliente;
14.3 Cdigo Personal Trainer;
14.4 Descrio:
14.5 Data do aula;
14.6 valor da aula;
14.7 Cdigo do Financeiro;
14.8 Data de Oramento;
14,9 Data do Controle.

4.1.4 MODELO DE DADOS


A modelagem de dados uma tcnica usada para a especificao das
regras de negcios e as estruturas de dados de um banco de dados. Ela faz parte
do ciclo de desenvolvimento de um sistema de informao e de vital importncia
para o bom resultado do projeto. Modelar dados consiste em desenhar o sistema
de informaes, concentrando-se nas entidades lgicas e nas dependncias
lgicas entre essas entidades.
Modelagem de dados ou modelagem de banco de dados envolve uma
srie de aplicaes tericas e prticas, visando construir um modelo de dados
consistente, no redundante e perfeitamente aplicvel em qualquer SGBD
moderno. A modelagem de dados est dividida em:

Modelo conceitual
A modelagem conceitual baseia-se no mais alto nvel e deve ser usada
para envolver o cliente, pois o foco aqui discutir os aspectos do negcio
do cliente e no da tecnologia. Os exemplos de modelagem de dados
vistos pelo modelo conceitual so mais fceis de compreender, j que no
h limitaes ou aplicao de tecnologia especfica. O diagrama de dados
que deve ser construdo aqui o Diagrama de Entidade e Relacionamento,
onde devero ser identificados todas as entidades e os relacionamentos

48

entre elas. Este diagrama a chave para a compreenso do modelo


conceitual de dados.

Modelo lgico
O modelo lgico j leva em conta algumas limitaes e implementa
recursos como adequao de padro e nomenclatura, define as chaves
primrias e estrangeiras, normalizao, integridade referencial, entre
outras. Para o modelo lgico deve ser criado levando em conta os
exemplos de modelagem de dados criados no modelo conceitual.

Modelo fsico
No modelo fsico fazemos a modelagem fsica do modelo de banco de
dados. Neste caso leva-se em conta as limitaes impostas pelo SGBD
escolhido e deve ser criado sempre com base nos exemplos de
modelagem de dados produzidos no item anterior, modelo lgico.

4.1.4.1. DFD PRELIMINAR


De acordo com Pompilho (2002) a analise estruturada preconiza uma
abordagem para particionamento do sistema estritamente do tipo Top-down, ou
seja, partindo do diagrama de contexto, decompe-se o sistema em DFD de
nveis hierrquicos. A analise essencial no exclui as duas abordagens citadas,
mais propem o particionamento do sistema baseado nos eventos.
O mesmo autor diz que partindo do DFD preliminar, podemos usar a
abordagem preliminar Top-down, decompor as funes encontradas para obter
os DFDs de nveis mais baixos, devemos agrupar as funes, usando uma
abordagem Bottom-up para construir os DFDs de nveis mais altos.
Para se obter um DFD de nvel zero tem-se de agrupar as funes
comeando com os DFDs preliminares, neste caso foi preciso apenas um nvel de
agrupamento, mais em outros sistemas poderia ser necessrio uma quantidade
maior de nveis ate se chegar ao DFD-zero. (POMPILHO, 2002).
O DFD-zero representa o nvel de DFD imediatamente abaixo do nvel de
diagrama de contexto. Logo possvel que para se construir um DFD de funes

49

em um ou mais nveis, tenhamos de agrupar funes em um ou mais nveis


superiores. (POMPILHO, 2002)
Pompilho (2002) diz que a rigor a principal preocupao deve ser a
facilidade na comunicao. Se um DFD em qualquer nvel que seja no for
inteligvel havendo excesso de detalhes seria conveniente agrupar as funes
em nveis de abstrao superiores, para facilitar a comunicao. Uma boa soluo
funes que tenham o mximo de independncias e com isso o mnimo de
acoplamento entre si. Se buscarmos agruparmos as funes que tenham muitas
ligaes entre si, estaremos automaticamente, obtendo um DFD de nvel de
abstrao superior bem elaborado.

50

4.1.4.2 DIAGRAMA DE FLUXO DE DADOS

Figura 1: Diagrama de Fluxo de Dados


Fonte: Elaborado pelos Acadmicos.

51

4.1.4.3 DIAGRAMA DE CLASSES


A equipe de projeto adotou a UML (Linguagem Unificada de Modelagem)
para visualizao, especificao, construo e documentao dos artefatos. O
diagrama de classe o diagrama encontrado com maior frequncia na
modelagem de sistemas orientada a objeto, ele importante tanto para a
visualizao, a especificao e a documentao de modelos, quanto para a
construo de sistemas executveis por intermdio de engenharia de produo e
reserva (BOOCH, RUMBAUGH, JACOBSON, 2000).
Um diagrama de classes mostra um conjunto de classes, interfaces e
colaborao e seus respectivos relacionamentos, graficamente uma coleo de
vrtices e arcos. Sua utilizao para fazer uma modelagem da viso esttica do
sistema em questo, oferecendo suporte para os requisitos funcionais do sistema,
ou seja, as aes que o sistema ir executar.
Segundo Deboni (2003), diagramas de classes so modelados para
esquematizar o domnio de um sistema informacional, contribuindo para
elaborao da estrutura inicial do software a ser desenvolvido, as classes
representam as entidades que sero operadas pelo sistema, alm das interaes
durante funcionamento da aplicao.
O diagrama de classes do sistema, onde foram modeladas as classes
Cliente, Cidade, Estado, Medida, Usurio, Matrcula e Mensalidade e Pacote.
Para

cada

classe

foi

apontada

respectivos

atributos

mtodos.

Os

relacionamentos e as cardinalidades entre as classes tambm so exibidos.


4.1.4.4 DIAGRAMA DE CASOS DE USO
Diagrama de Casos de Uso Os diagramas de casos de uso tm um papel
central para a modelagem do comportamento de um sistema cada um mostra um
conjunto de casos de uso e atores e seus relacionamentos, os diagramas de
casos de uso so importantes para visualizar, especificar e documentar o
comportamento de um elemento. Tecnicamente, um diagrama de caso de uso
um diagrama que mostra um conjunto de casos de uso, atores e seus
relacionamentos (BOOCH, RUMBAUGH, JACOBSON, 2000).

52

Os diagramas de caso de uso devem conter casos de uso, atores e


relacionamentos de dependncia, generalizao e a associao. Assim como os
outros diagramas podem conter notas e restries. Esse diagrama aplicado
para fazer modelagem da viso esttica de caso de uso do sistema, essa viso
proporciona suporte principalmente para o comportamento de um sistema, os
servios extremamente visveis que o sistema fornece no contexto de seu
ambiente (BOOCH, RUMBAUGH, JACOBSON, 2000).
Foram elaborados diagramas de casos de uso, assim como roteiro normal
e roteiros alternativos para cada um dos eventos apresentados. Esse
detalhamento foi necessrio para compreender todas as situaes de interao
dos atores com as funcionalidades do sistema. Exemplifica o diagrama de caso
de uso de cadastro de usurio, nele demonstrado o curso normal do cadastro
de usurio, onde o gerente solicita um novo cadastro, informa os dados do novo
usurio e confirma o salvamento do registro. Alm disso, os cursos alternativos
foram modelados, por exemplo, caso o gerente solicite uma alterao, pesquisa
ou excluso de algum registro; ou quando os dados informados para a realizao
do novo cadastro estejam errados.
Um modelo de caso de uso um modelo que descreve como diferentes
tipos de usurios interagem com o sistema para resolver um problema. Como tal,
ele descreve as metas dos usurios, as interaes entre os usurios e o sistema,
bem como o comportamento necessrio do sistema para satisfazer estas metas.
Um modelo de caso de uso consiste em um conjunto de elementos de modelo. Os
elementos de modelo mais importantes so: casos de uso, atores e as relaes
entre eles.
Um diagrama de caso de uso usado para descrever graficamente um
subconjunto do modelo para simplificar a comunicao. Normalmente existiro
vrios diagramas de caso de uso associados a um determinado modelo, cada um
mostrando um subconjunto de elementos de modelo relevantes para um
determinado fim. O mesmo elemento de modelo pode ser exibido em vrios
diagramas de caso de uso, mas cada instncia tem que ser consistente. Se
alguma ferramenta for usada para manter o modelo de caso de uso, esta restrio
de consistncia deve ser automatizada, de forma que quaisquer alteraes em
um

elemento

de

modelo

(alterao

do

nome,

por

exemplo)

sero

53

automaticamente refletidas em todos os diagramas de caso de uso que mostram


o elemento. O modelo de caso de uso pode conter pacotes que so usados para
estruturar o modelo e simplificar a anlise, a comunicao, a navegao, o
desenvolvimento, a manuteno e o planejamento. Muito do modelo de caso de
uso na verdade textual, com o texto capturado nas Especificaes de Caso de
Uso que esto associadas a cada elemento de modelo de caso de uso. Estas
especificaes descrevem o fluxo de eventos do caso de uso.
O modelo de caso de uso serve como um unificador em todo o
desenvolvimento do sistema. usado como a principal especificao dos
requisitos funcionais para o sistema, servindo como base para a anlise e o
design, como uma entrada para o planejamento da iterao, como base para a
definio de casos de teste e como base para a documentao dos usurios.

54

4.1.4.4.1 DIAGRAMA DE CASO DE USO

55

4.1.4.4 DIAGRAMA DE ENTIDADE RELACIONAMENTO

Figura 2: Diagrama de Fluxo de Dados


Fonte: Elaborado pelos Acadmicos.

56

4.1.4.5 DIAGRAMA DE ENTIDADE RELACIONAMENTO

Figura 3: Diagrama de Entidade Relacionamento


Fonte: Elaborado pelos Acadmicos.

57

4.1.4.6 DIAGRAMA DE CLASSE

58

4.1.5 DICIONRIO DE DADOS


Tabela 14 - Depsito de dados D1
Fonte: Elaborado pelos Acadmicos.

DD de D1 Personal
Tabela Departamento
@ id_departamento: NUMERIC(8)
descricao: CHAR(50)
Tabela Cargo
@ id_cargo: NUMERIC(8)
descricao: CHAR(50)
@ id_departamento: NUMERIC(8)
Tabela Estado
@ id_estado: NUMERIC(8)
nome: CHAR(80)
unidade_federativa: CHAR(2)
Tabela Cidade
@ id_cidade: NUMERIC(8)
nome: CHAR(80)
@ id_estado: NUMERIC(8)
Tabela Funcionario
@ id_funcionario: NUMERIC(8)
nome: CHAR(100)
cpf: NUMERIC(11)

DESCRIO
Armazena dados referente ao cadastro
dos funcionrios.
Armazena dados da tabela
Departamento.
Atributo que representa cdigo e
identifica a tabela Departamento.
Atributo que representa a descrio do
departamento.
Armazena dados da tabela Cargo.
Atributo que representa cdigo e
identifica a tabela Cargo.
Atributo que representa a descrio do
cargo.
Atributo que representa cdigo
referente tabela Departamento.
Armazena dados da tabela Estado.
Atributo que representa o cdigo e
identifica tabela Estado.
Atributo que representa o nome do
estado.
Atributo que representa a abreviao
do estado.
Armazena dados da tabela Cidade.
Atributo que representa o cdigo e
identifica a tabela Cidade.
Atributo que representa o nome da
cidade.
Atributo que representa o cdigo
referente a tabela Estado.
Armazena dados da tabela
Funcionario.
Atributo que representa cdigo e
identifica a tabela Funcionrio.
Atributo que representa o nome do
personal.
Atributo que representa o nmero do
CPF do funcionrio

59

rg: NUMERIC(10)
telefone: NUMERIC(20)
email: CHAR(100)
rua: CHAR(100)
quadra: CHAR(100)
lote: NUMERIC(6)
numero: NUMERIC(10)
cep: NUMERIC(20)
bairro: CHAR(100)
id_cidade: NUMERIC(8)
salario: NUMERIC(10,2)
percentual_comissao: NUMERIC(7,2)
data_admissao: DATE
@ id_cargo: NUMERIC(8)

Atributo que representa o nmero do


RG do personal.
Atributo que representa o nmero de
telefone do personal.
Atributo que representa o endereo de
email do personal.
Atributo que representa o nome da rua
no endereo do personal.
Atributo que representa o numero da
quadra no endereo do personal.
Atributo que representa o numero do
lote no endereo do personal.
Atributo que representa o numero no
endereo do personal.
Atributo que representa o numero do
CEP do endereo.
Atributo que representa o bairro do
personal.
Atributo que representa o cdigo e
identifica a tabela cidade.
Atributo que representa o valor do
salario do personal.
Atributo que representa o valor da
porcentagem da comisso do personal.
Atributo que representa a data de
admisso do personal.
Atributo que representa cdigo
referente tabela Cargo.

Tabela 15 - Depsito de dados D2


Fonte: Elaborado pelos Acadmicos.

DD de D2 Usurio
Tabela Nivel_Usuario
@ id_nivel_usuario: NUMERIC(8)
descricao: CHAR(50)
Tabela Usuario
@ id_usuario: NUMERIC(8)
@ id_nivel_usuario: NUMERIC(8)

DESCRIO
Armazena dados do cadastro de
usurio.
Armazena dados da tabela
Nivel_Usuario.
Atributo que representa o cdigo e
identifica a tabela Nivel_Usuario.
Atributo que representa a descrio do
nvel de usurio.
Armazena dados da tabela Usuario.
Atributo que representa o cdigo unico
e idntica a tabela Usuario.
Atributo que representa o cdigo
referente a tabela Nivel_Usuario.

60

@ id_funcionario: NUMERIC(8)
nome: CHAR(100)
@ login: CHAR(40)
senha: CHAR(40)
data_cadastro: DATE
data_alteracao: DATE
usuario_cadastro: CHAR(100)
usuario_alteracao: CHAR(100)
ultimo_acesso: DATE.

Atributo que representa o cdigo


referente a tabela personal.
Atributo que representa o nome do
personal.
Atributo que representa o login do
usurio.
Atributo que representa a senha do
usurio.
Atributo que representa a data de
cadastro do usurio.
Atributo que representa a data de
alterao de informaes do usurio.
Atributo que representa o usurio que
cadastrou o login.
Atributo que representa o usurio que
fez a alterao no login.
Atributo que representa a ultima data
de acesso do usurio.

Tabela 16 - Depsito de dados D3


Fonte: Elaborado pelos Acadmicos.

DD de D3 Cliente
Tabela Estado
@ id_estado: NUMERIC(8)
nome: CHAR(50)
unidade_federativa: CHAR(2)
Tabela Cidade
@ id_cidade: NUMERIC(8)
nome: CHAR(50)
@ id_estado: NUMERIC(8)
Tabela Cliente
@ id_cliente: NUMERIC(8)
cnpj: NUMERIC(20)
inscricao_estadual: NUMERIC(10)

DESCRIO
Armazena dados referente ao cadastro
do cliente.
Armazena dados da tabela Estado.
Atributo que representa o cdigo e
identifica tabela Estado.
Atributo que representa o nome do
estado.
Atributo que representa a abreviao
do estado.
Armazena dados da tabela Cidade.
Atributo que representa o cdigo e
identifica a tabela Cidade.
Atributo que representa o nome da
cidade.
Atributo que representa o cdigo
referente tabela Estado.
Armazena dados da tabela Cliente.
Atributo que representa o cdigo e
identifica a tabela Cliente.
Atributo que representa o numero do
CNPJ do cliente.
Atributo que representa o numero da IE

61

razao_social: CHAR(100)
nome_fantasia: CHAR(100)
telefone: NUMERIC(10)
fax: NUMERIC(10)
contato: CHAR(50)
email: CHAR(100)
rua: CHAR(100)
quadra: CHAR(50)
lote: NUMERIC(10)
numero: NUMERIC(10)
cep: NUMERIC(20)
bairro: CHAR(100)
@ id_cidade: NUMERIC(8)

4.2 PROJETO
4.2.1 PROTOTIPAO

Figura 4: Tela de acesso ao sistema


Fonte: Elaborado pelos Acadmicos.

do cliente.
Atributo que representa o nome de
registro da empresa do cliente.
Atributo que representa o nome da
empresa do cliente.
Atributo que representa o numero de
telefone do cliente.
Atributo que representa o numero de
fax do cliente.
Atributo que representa o nome de
contato do cliente.
Atributo que representa o endereo de
email do cliente.
Atributo que representa o nome da rua
no endereo do cliente.
Atributo que representa o numero da
quadra no endereo do cliente.
Atributo que representa o numero do
lote no endereo do cliente.
Atributo que representa o numero no
endereo do cliente.
Atributo que representa o numero do
CEP do endereo.
Atributo que representa o bairro do
cliente.
Atributo que representa o cdigo
referente a tabela Cidade.

62

Figura 5: Tela de cadastro Principal do Sistema


Fonte: Elaborado pelos Acadmicos.

Figura 5: Tela de cadastro de Cliente


Fonte: Elaborado pelos Acadmicos.

63

Figura 6: Tela da Agenda


Fonte: Elaborado pelos Acadmicos.

Figura 7: Tela do Treino


Fonte: Elaborado pelos Acadmicos.

64

Figura 8: Tela de Anamnese


Fonte: Elaborado pelos Acadmicos.

Figura 9: Tela de Avaliao de Risco Cardaco


Fonte: Elaborado pelos Acadmicos.

65

Figura 10: Tela de Avaliao Fsica


Fonte: Elaborado pelos Acadmicos.

Figura 11: Tela de Composio Corporal


Fonte: Elaborado pelos Acadmicos.

66

Figura 12: Tela de Massa Corporal


Fonte: Elaborado pelos Acadmicos.

Figura 13: Tela de ndice de Massa Corporal


Fonte: Elaborado pelos Acadmicos.

67

Figura 14: Tela de PAR-Q


Fonte: Elaborado pelos Acadmicos.

Figura 15: Tela de Perimetria


Fonte: Elaborado pelos Acadmicos.

68

Figura 16: Tela do Financeiro


Fonte: Elaborado pelos Acadmicos.

Figura 15: Tela de Perimetria


Fonte: Elaborado pelos Acadmicos

69

4.2.2 MODELO FSICO DO BANCO DE DADOS

70

CONSIDERAES FINAIS
Ao decorrer do trabalho foi abordada toda especificidade de cada item
implantado, visando deixar o mais claro e objetivo para os usurios. No decorrer
do projeto, foram sanados os problemas propostos que garantem ao sistema um
suporte eficiente e um controle mais detalhado do estoque.
medida que aprofundvamos na soluo proposta, novos problemas
foram surgindo, fazendo-se necessrias reunies com o grupo para argumentlas, discuti-las e san-las para que, o projeto ficasse de acordo com os modelos
necessrios para o mercado. Neste projeto foram alcanados os objetivos
propostos. Procurou-se enfatizar a bibliografia utilizada no decorrer deste trabalho
que permitiu o conhecimento e a abordagem da soluo proposta. As ferramentas
que tal profissional necessita so: cadastros, descrio das rotinas de
treinamentos, informaes pessoas, histricos e avaliao do desempenho do
cliente.
Para colocar o personal trainer atualizado das novas tendncias e
tecnologias, o sistema ter um desing moderno e arrojado com ferramentas
prticas e interessantes. Utilizando uma interface grfica amigvel com o usurio,
ter o objetivo de facilitar o uso de suas ferramentas, podendo assim tirar o maior
proveito de todas as suas funes. Todo o manuseio do sistema ser prtico e
simples. Dessa forma qualquer usurio no ter problemas durante a utilizao
independentemente do nvel de conhecimento.
O principal problema analisado foi a dificuldade com a parte administrativa
de suas informaes, devido isso a elaborao de um sistema que se adque ao
escopo de trabalho e se alinhe de acordo com suas atividades durante seus
treinamentos de seus clientes e indispensvel. Este ser o principal foco dos
acadmicos, criar toda uma estrutura administrativa para poder gerir todas as
funes como: informaes como compromissos e dados de clientes, clculos
complexos, controle de finanas alinhando toda sua parte administrativa.

71

REFERNCIAS
KORTH, H.F. e Silberschatz, A.; Sistemas de Bancos de Dados, Makron Books, 5
edio, 2006.
SAIED, Tabaghoghi e HUGH E. Williams.; Aprendendo MySQL, Altabooks, 1 a
edio 2004.
M. TAMER Ozsu e PATRICK Valduriez.; Princpios de sistema de banco de dados
distribudos, Rio de Janeiro: Campus 2a edio 2001.
PAUL J. Deitel E HARVEY M. Deitel.; Java como programar, Person 8 edio
2010.
YOURDON, Edward Analise Estruturada Moderna, Campus Bela Morada, 1
Edio 1990.
PRESSMAM, Roger S. ENGENHARIA DE SOFTWARE: UMA ABORDAGEM
PROFISSIONAL. 7. Ed. Porto Alegre: AMGH, 2011.
SOMMERVILLE, Ian. ENGENHARIA DE SOFTWARE. 8. Ed. So Paulo: Pearson
Educacion, 2007.
ELMASRI, Ramez; NAVATHE, Shamkant B. . SISTEMAS DE BANCO DE DADOS
FUNDAMENTOS E APLICAES. 3. Ed. So Paulo: LTC, 2002.
POMPILHO, S. ANALISE ESSENCIAL: GUIA PRATICO DE ANALISE DE
SISTEMAS. 1. Ed. Rio de Janeiro: CINCIA MODERNA, 2002.
FILGUEIRAS, Dra. Lcia V. L.; MELNIKOFF, Dra. Selma Shin Shimizu
ENGENHARIA DE SOFTWARE.1. Ed. Rio de Janeiro: CINCIA MODERNA,
2002.
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: Guia do Usurio.
12 Ed., Rio de Janeiro: Campus, 2000. DEBONI, Jos Eduardo Zindel.

72

Modelagem Orientada a Objetos com a UML. So Paulo: Editora Futura, 2003.


MATOS, Alexandre Veloso. UML Prtico e Descomplicado. So Paulo: rica,
2002.
PAULA FILHO, Wilson de Pdua. Engenharia de Software: Fundamentos,
Mtodos e Padres. 2 Ed., Rio de Janeiro: LTC, 2000.

73

APNDICE

ATA DA 1 REUNIO DO PROJETO INTERDISCIPLINAR


REUNIAO COM O PERSONAL

Data: 28/02
Local: Jardim Nova Era
Hora incio: 14:27
Hora termino: 16:25
Participantes: Mrio, Wesley, Jobson, Diego e Leandro Fabino

No dia 28/02/2014 os acadmicos fizeram uma reunio com o personal


trainer Leandro Fabino no setor Jardim Nova Era. Foi lhe mostrado o software,
como ele lhe funcionara e perguntado como funciona seus processos
administrativos e de atividades. O mesmo falou que j utilizou outros aplicativos
como Vida que e um software j especifico para o personal trainer e possui as
ferramentas para as atividades fsicas porem os mesmos no tinham as
ferramentas para os quais ele necessitava. Foi discutido as maiores necessidades
no cotidiano desse personal trainer e so agenda das aulas e cadastros dos
alunos.
Foram discutidas as funes do software e os processos dirios do
personal trainer chegando assim a concluso de algumas funes e ferramentas
que o sistemas deveria lhe proporcionar. Alguns campos que deveriam aparecer
no relatrio do cliente: Peso, IMC, reao cintura quadril (medida da
circunferncia da cintura com o quadril [dividir a cintura pelo quadril]), frequncia
cardaca (porcentagem), percentual de gordura (volume de massa muscular, peso
dos ossos, densidade corporal), presso arterial, tipo sanguneo (tela inicial de
cadastros).

74

Tambm foi dada algumas sugestes pelo profissional de como o sistema


deveria se comportar e as ferramentas que lhe ajudariam no cotidiano, dentre as
principais observaes foram discutidas com o grupo para chegar em uma anlise
mais consistente.
Sugesto: Dentro da parte financeira gerar um recibo com os dados do
cliente.
Sugesto: Dentro da avaliao fsica deve fazer uma anamnese
(questionrio para prontido de atividade fsica) Ateno se apenas uma das
avaliao for marcada como sim deve ser necessria avaliao medica.
Sugesto: Gerar um grfico de desempenho das atividades. Na tela
financeiro gerar um recibo para imprimir ou enviar por e-mail.
Funo agenda: tirar um extrato do dia. Visualizao (planilha dos
horrios do dia. Opo do personal trainer abrir uma planilha semanal).

75

ANEXO I
Questionrio enviado para o personal trainer.
1- Como o seu processo administrativo?
2 - Como sua rotina de trabalho?
3 - Como e feito o agendamento de treino ou aulas. Onde voc anota ou guarda
informaes?
4 - Se voc tivesse um sistema que gerenciasse o seu trabalho, como voc
gostaria que fosse este sistema?
5 - Quais so as principais ferramentas de trabalho que so utilizadas? Quais o
sistema necessitaria para automatizao?
6 - Qual a forma que voc utiliza para organizar a sua rotina de treino e aulas? E
como um sistema poderia te auxiliar?
Respostas
1 - No meu processo administrativo eu elaboro planilhas no Excel com os dados
pessoais dos alunos, data de vencimento e com valores a receber. Dessa forma
tenho controle de cada vencimento.
2 - A rotina de trabalho simples. Aps elaborar o treinamento individual de cada
aluno em planilhas no Word ou Excel, repasso os treinamentos e ao final este
aluno assina a folha de concluso da aula dada.
3 - Quando se fecha um horrio com o aluno, guardo na memria, pois ainda
tenho poucos alunos. Mas quando atingir um quantitativo maior, essas anotaes

76

de agendamento das aulas sero marcadas na agenda tradicional. Tanto para


aulas normais dadas ou para reposies de aula faltosa.
4-

Este sistema gerenciador deveria ter campos e telas individuais como: ficha

de cadastro completo do aluno, tela administrativa para organizar as finanas,


agendamento de aula, quadro de chamada se a aula foi concluda ou reposio,
planilha para deixar o treinamento dirio elaborado com opes para que
possamos cadastrar a nomenclatura dos exerccios, sries e repeties, cargas
de tempo de descanso e outros.
5 - Dados dos alunos, treinamento, avaliao fsica so os mais utilizados.
6 - Bem como disse anteriormente, organizo a rotina de treino de meus alunos de
forma geral utilizando metodologias fisiolgicas para que eles consigam chegar ao
resultado esperado. No utilizo programa e monto os treinos variados sem anotlos. Vai mais de cabea. E vejo o resultado de desemprenho atravs da avaliao
Fsica, sendo assim, melhorando os dados da avaliao significa que o
treinamento est dando certo e o programa que utilizo faz toda a anlise de
desempenho deste aluno.

Das könnte Ihnen auch gefallen