centro estadual de educação tecnológica paula souza

CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA
PAULA SOUZA
FACULDADE DE TECNOLOGIA DE LINS PROF. ANTÔNIO SEABRA
CURSO SUPERIOR DE TECNOLOGIA EM BANCO DE DADOS
KLINSMANN TEODORO ANTERO
RAFAELA ALVES DE SOUZA
SISTEMA DE INFORMAÇÃO PARA LOJA DE ALUGUEL DE ROUPAS
LINS/SP
2º SEMESTRE/2012
CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA
PAULA SOUZA
FACULDADE DE TECNOLOGIA DE LINS PROF. ANTÔNIO SEABRA
CURSO SUPERIOR DE TECNOLOGIA EM BANCO DE DADOS
KLINSMANN TEODORO ANTERO
RAFAELA ALVES DE SOUZA
SISTEMA DE INFORMAÇÃO PARA LOJA DE ALUGUEL DE ROUPAS
Trabalho de Conclusão de Curso apresentado à
Faculdade de Tecnologia de Lins para obtenção
do Título de Tecnólogo(a) em Banco de Dados.
Orientador: Prof. Me. Luiz Fernando Oliveira Silva
LINS/SP
2º SEMESTRE/2012
Dedicamos a Deus por nos dar sabedoria
para a realização desse trabalho.
Dedicamos às nossas famílias pelo incentivo
E por fim a nós que com força, garra e
determinação realizamos esse projeto.
Klinsmann e Rafaela
AGRADECIMENTOS
Acho importante dizer, antes de começar a agradecer, que há muitas pessoas
envolvidas que me deram força e me ajudaram ao longo dos anos para que eu
chegasse até aqui, como professores do ensino fundamental e médio, amigos e
familiares. A todos que participaram da minha trajetória, muito obrigado!
Sobre os agradecimentos para este trabalho, começo pela minha parceira de
pesquisa, Rafaela, que graças a ela pudemos iniciar o trabalho e concluí-lo.
Obrigado por sua presença total durante todo o desenvolvimento do projeto deste
trabalho e estar sempre disponível quando necessário.
Agradeço ao nosso orientador, o Prof. Me. Luiz Fernando que durante suas
orientações pôde nos ajudar a resolver grandes problemas no desenvolvimento do
software proposto.
Ainda, faço meus votos pela Prof.ª Me. Luciane Noronha, que esteve
disponível sempre que necessário. Foi um orgulho ter sido aluno desta grande
profissional.
E por fim, com grande honra, agradeço à minha família, meus amigos e
colegas que de qualquer forma tenham ajudado ou influenciado na produção deste
trabalho.
Klinsmann Teodoro Antero
AGRADECIMENTOS
Agradeço a Deus pelas oportunidades que me foram dadas na vida, que
iluminou o meu caminho durante esta caminhada. Principalmente por ter conhecido
pessoas e lugares interessantes, mas também por ter vivido fases difíceis, que foram
matérias-primas de aprendizado.
Aos meus pais Durvalina e Salvador. Ambos são responsáveis por cada
sucesso obtido e cada degrau avançado pro resto da minha vida. Durante todos
esses anos vocês foram pra mim um grande exemplo de força, de coragem,
perseverança e energia infinita para nunca desistir diante do primeiro obstáculo
encontrado. Obrigada simplesmente por participarem comigo durante essa
caminhada, me ajudando a construir os alicerces de um futuro que começa agora,
após três anos de muita dedicação. Vocês me ensinaram direta e indiretamente
lições pra toda uma vida.
Agradeço aos meus irmãos, em especial meu irmão José Roberto pela força e
paciência que teve comigo, incentivo e ajuda de melhorar de forma geral na
elaboração do projeto e em matérias que tive dificuldades, OBRIGADA!
Agradeço também ao meu namorado, Gustavo, que de forma especial e
carinhosa me deu força e coragem, me apoiando nos momentos de dificuldades.
A todos os professores, em especial a nossa professora Luciane Noronha que
nos acompanha desde a 5ª série. Uma mulher corajosa, forte e guerreira, fonte
inesgotável de amor, carinho e incentivo que sempre esteve torcendo por nós esse
tempo todo, ansiando pelo nosso sucesso.
Ao amigo especial e companheiro de monografia, Klinsmann. Meu querido,
agradeço a você por todos os momentos que passamos juntos e pela árdua
caminhada que foi a concretização desse Trabalho de Conclusão de Curso.
Merecemos muito sucesso!
Obrigado a todos os meus colegas de classe e as pessoas que contribuíram
para meu sucesso e para meu crescimento como pessoa. Sou o resultado da
confiança e da força de cada um de vocês.
E claro, agradeço ao Orientador Luiz Fernando (Tuca) pela oportunidade de
sermos seus orientandos.
Rafaela Alves de Souza
RESUMO
A tecnologia da informação está se mostrando muito útil na questão de
gerenciamento de negócios. Ela agiliza os serviços e facilita na tomada de decisão.
Ao observar o mercado de aluguel de roupas local, nota-se certa carência de
recursos tecnológicos. Para exemplificar esta afirmação, chega-se à proposta do
desenvolvimento de um software para a loja de alguel de roupas Beleza Pura de
Lins. A loja enfrenta problemas com relação ao controle de aluguel de vestidos,
deficiência no controle e manutenção destes, desorganização no agendamento dos
horários de prova de vestidos, entre outros problemas. Os objetivos deste trabalho
são: melhorar o controle de locações, controle de vendas, agilizar o atendimento e
consolidar as informações dos clientes. Por meio de entrevistas e organização de
ideias, formularam-se os requisitos necessários para o desenvolvimento do software
proposto. Para elaboração do software foram utilizadas a linguagem de
programação Java, Unified Modeling Language para modelagem dos diagramas e
banco de dados Oracle para armazenar os dados. O sistema de informação foi
instalado na loja e está em fase de testes. Acredita-se que este software
desenvolvido ajudará a proprietária da loja de aluguel e os funcionários a gerenciar
melhor seus produtos, aluguéis, vendas, por meio de relatórios, consultas e outras
funcionalidades presentes.
Palavras-chave: Sistema de Informação. Aluguel de Roupas. Tecnologia. Loja.
ABSTRACT
Information technology is proving to be very helpful about business management. It
facilitates and accelerates services in taking decision. When looking at the rental
market local clothing, there is certain deficiency of technological resources.
Illustrating this assertion, it reaches the proposed development of software to the
rental clothing store named Beleza Pura from Lins. The store faces problems about
rental control dresses, deficiency in control and maintenance theirs, lack of
scheduling time for dresses taste, among other problems. The specific objectives in
producing this work are: improving the rental control, sales control, expedite and
improve customer service and consolidate customer information. Were used
interviews and organizing ideas to formulate the needed requirements to initiate the
development of the proposed software. To develop this software was used the
programming language named Java, Unified Modeling Language to modeling
diagrams and Oracle Database to store the data. The information system was
installed in the store and the first one is in test phase. It is believed this software will
help the rental store’s owner and its employees to manage their products, rentals and
sales by using reports, queries and other features present.
Keywords: Information Systems, Rental Clothing, Technology, Store.
LISTA DE ILUSTRAÇÕES
Figura 2.1 - Imagem da Loja .................................................................................... 23
Figura 2.2 - Diagrama de Casos de Uso .................................................................. 28
Figura 4.1 - Diagrama de Atividade Emitir Relatório ................................................ 44
Figura 4.2 - Diagrama de Atividade Lançar Pagamento ........................................... 44
Figura 4.3 - Diagrama de Atividade Manter Usuário ................................................ 45
Figura 4.4 - Diagrama de Atividade Manter Cliente .................................................. 46
Figura 4.5 - Diagrama de Atividade Efetuar Locação ............................................... 47
Figura 4.6 - Diagrama de Atividade Efetuar Venda .................................................. 48
Figura 4.7 - Diagrama de Atividade Efetuar Login .................................................... 49
Figura 4.8 - Diagrama de Atividade Manter Vestido ................................................. 50
Figura 4.9 - Diagrama de Classes ........................................................................... 51
Figura 4.10 - Diagrama de MVC Manter Vestido ...................................................... 52
Figura 4.11 - Diagrama de MVC Manter Usuário ..................................................... 53
Figura 4.12 - Diagrama de MVC Manter Cliente ...................................................... 53
Figura 4.13 - Diagrama de MVC Lançar Pagamento ............................................... 54
Figura 4.14 - Diagrama de MVC Emitir Relatório ..................................................... 55
Figura 4.15 - Diagrama de MVC Efetuar Venda ....................................................... 56
Figura 4.16 - Diagrama de MVC Efetuar Locação .................................................... 57
Figura 4.17 - Diagrama de MVC Efetuar Login ........................................................ 58
Figura 4.18 - Diagrama de Sequência Manter Vestido ............................................. 59
Figura 4.19 Diagrama de Sequência Efetuar Login .................................................. 60
Figura 4.20 Diagrama de Sequência Manter Usuário .............................................. 60
Figura 4.21 Diagrama de Sequência Manter Cliente ................................................ 61
Figura 4.22 Diagrama de Sequência Lançar Pagamento ......................................... 61
Figura 4.23 - Diagrama de Sequência Emitir Relatório ............................................ 62
Figura 4.24 - Diagrama de Sequência Efetuar Venda .............................................. 62
Figura 4.25 - Diagrama de Sequência Efetuar Locação ........................................... 63
Figura 4.26 - Modelo de Entidade e Relacionamento .............................................. 64
Figura 5.1 - Tela de Login ........................................................................................ 66
Figura 5.2 - Tela de Serviços - Proprietária .............................................................. 67
Figura 5.3 - Tela de Serivços - Funcionário .............................................................. 68
Figura 5.4 - Tela de Cadastro de Vestido ................................................................. 68
Figura 5.5 - Tela de Cadastro de Cliente ................................................................. 69
Figura 5.6 - Tela de Cadastro de Funcionário .......................................................... 70
Figura 5.7 - Tela Registrar Pagamento Cheque ....................................................... 71
Figura 5.8 - Tela Registrar Pagamento Cartão ......................................................... 71
Figura 5.9 - Tela Registrar Pagamento Dinheiro ...................................................... 72
Figura 5.10 - Tela Locação ....................................................................................... 72
Figura 5.11 - Tela Relatório ...................................................................................... 73
Figura 5.12 - Tela Venda .......................................................................................... 74
LISTA DE ABREVIATURAS E SIGLAS
API - Application Programming Interface
CnC - Cenário Chave
FB - Fluxo Básico
HTML - Hypertext Modeling Language
IDE - Interface Development Environment
JEE - Java Enterprise Edition
JME - Java Micro Edition
JSE - Java Standard Edition
J2EE - Java to Enterprise Edition
J2ME - Java to Micro Edition
J2SE - Java to Standard Edition
LPOO - Linguagem de Programação Orientada a Objetos
MER-EX - Modelo de Entidade e Relacionamento - Extended
MVC - Modelo, Visão e Controle
OSC - Oracle Systems Corporation
PU - Processo Unificado
RSI - Relational Software Inc.
RUP - Rational Unified Process
SDL - Software Development Labs
SGBD - Sistema Gerenciador de Banco de Dados
SI - Sistemas de Informação
SOA - Service-Oriented Architecture
TI - Tecnologia da Informação
UML - Unified Modeling Language
SUMÁRIO
INTRODUÇÃO ...................................................................................... 12
1 FUNDAMENTOS CONCEITUAIS E TECNOLOGIAS UTILIZADAS ...14
1.1 JAVA ................................................................................................................... 14
1.2 UML ..................................................................................................................... 16
1.2.1 Primeira fase: Concepção ................................................................................ 17
1.2.2 Segunda Fase: Elaboração .............................................................................. 18
1.2.3 Terceira Fase: Construção ............................................................................... 18
1.2.4 Quarta Fase: Transição .................................................................................... 18
1.3 BANCO DE DADOS ORACLE ............................................................................ 18
1.3.1 Estrutura do banco de dados ........................................................................... 19
1.3.1.1 Estrutura Física ............................................................................................. 19
1.3.1.2 Estrutura Lógica ............................................................................................ 20
1.3.2 Arquitetura de Processos ................................................................................. 20
1.3.2.1 Processos de Usuário ................................................................................... 21
1.3.2.2 Processos do Oracle ..................................................................................... 21
2 DOCUMENTOS INICIAIS DE UM SOFTWARE .................................22
2.1 ANÁLISE DE MERCADO .................................................................................... 22
2.2 HISTÓRICO DA EMPRESA ................................................................................ 22
2.3 LEVANTAMENTO DE REQUISITOS .................................................................. 23
2.4 DOCUMENTO VISÃO ......................................................................................... 24
2.4.1 Introdução do problema.................................................................................... 24
2.4.2 Instrução sobre a posição do produto .............................................................. 25
2.4.3 Resumo dos envolvidos ................................................................................... 25
2.4.4 Ambiente do usuário ........................................................................................ 26
2.4.5 Perspectiva do produto..................................................................................... 26
2.4.6 Premissas e dependências .............................................................................. 27
2.4.6.1 Necessidades e recursos .............................................................................. 27
2.4.6.2 Outros Requisitos do Produto ....................................................................... 27
2.5 Diagrama de casos de uso .................................................................................. 27
3 CASOS DE USO E SUAS ESPECIFICAÇÕES ..................................29
4 DIAGRAMAS E MODELAGEM DOS DADOS ....................................43
4.1 DIAGRAMAS DE ATIVIDADE ............................................................................. 43
4.2 DIAGRAMA DE CLASSES .................................................................................. 50
4.3 DIAGRAMAS DE MVC ........................................................................................ 52
4.4 DIAGRAMAS DE SEQUÊNCIA ........................................................................... 58
4.5 MER-EX .............................................................................................................. 63
5 PROTÓTIPO E DESENVOLVIMENTO DO SISTEMA ........................ 66
CONCLUSÃO ........................................................................................ 75
REFERÊNCIAS BIBLIOGRÁFICAS ...................................................... 77
ANEXO A – CONTRATO PARA LOCAÇÃO DE VESTIDOS ................. 79
12
INTRODUÇÃO
É indiscutível que quando existe um convite para uma festa, seja esta de
casamento, formatura ou até mesmo um jantar mais formal, há certa preocupação
das pessoas convidadas com relação ao que se deve vestir. Como cada celebração
é única, a maioria das mulheres convidadas se nega a comprar um vestido apenas
para a festa em questão, razão pela qual, muitas delas optam pelo aluguel do traje,
cuja opção se torna mais prática e financeiramente vantajosa.
Pode-se afirmar que lojas de aluguel de roupas para festas trabalham com
variedades de modelos, cores, tamanhos e tendências, sendo possível encontrar
vestimentas de todos os estilos e gostos para várias ocasiões e papéis: formandas,
madrinhas, debutantes, convidadas de formatura, casamento, entre outras
comemorações.
Ao observar o mercado de aluguel de roupas local, nota-se uma carência de
recursos tecnológicos na questão do gerenciamento de suas atividades. De acordo
com os dados do Serviço Brasileiro de Apoio às Micro e Pequenas Empresas –
SEBRAE (2006), o sucesso de qualquer empresa depende de várias decisões a
serem tomadas. Com base nestes dados, acredita-se que estabelecimentos com
mais recursos tecnológicos tenham uma organização mais rápida, então se chega à
proposta da elaboração de um sistema informatizado próprio para cada loja.
Ao compartilhar seus conhecimentos, Rosa (2010) explica que Sistemas de
Informação (SI) são sistemas computadorizados criados com a utilização de
recursos de Tecnologia da Informação (TI), ou seja, são softwares feitos para
computadores que gerenciam e tratam os dados para que estes sirvam de
informação para o usuário do sistema.
Os SI são elaborados por meio de técnicas sistemáticas e uso de linguagens
como a Unified Modeling Language (UML) aliados a uma linguagem de programação
que pode ser de alto ou de baixo nível e um banco de dados que armazena de forma
estruturada as informações.
Com efeito, os SI estão cada vez mais presentes em diversos lugares, uma
vez que eles transformam grande parte dos serviços e produtos providos por
determinada empresa, gerando a maioria deles de forma mais rápida, segura e
eficaz.
Com base nestas observações, o objetivo deste trabalho é propor e
13
desenvolver um SI para organização, vendas e controle de aluguel de roupas
femininas para a loja denominada Beleza Pura que trabalha com vestidos para
jovens e adultas.
A implantação de um SI em lojas de aluguel de roupas tem o objetivo de ser
útil, pois ele auxilia no controle do estoque de roupas, dinamiza a pesquisa de
produtos desejados pela cliente, verifica se os produtos estão disponíveis para
locação e fornece relatórios gerenciais para efetuar diversos tipos de análises.
O desenvolvimento do sistema proposto dar-se-á com o uso da linguagem de
programação Java, a qual terá como base teórica os irmãos Deitel (2005). A UML
será útil para a documentação do SI desenvolvido e a fundamentação principal terá
como base os conhecimentos de Medeiros (2004). E, por fim, o banco de dados
utilizado será o Oracle e os pensamentos de Ramalho (2005) serão levados em
consideração.
No primeiro capítulo, serão explanados os principais conceitos tratados neste
trabalho e as tecnologias utilizadas para o desenvolvimento do software. Já a
análise de mercado, descrição da empresa, o levantamento de requisitos e o
diagrama de casos de uso serão abordados no segundo capítulo. No terceiro
capítulo é possível encontrar cada uma das especificações dos casos de uso. A
partir do quarto capítulo, os diagramas de Classes; Modelo, Visão e Controle (MVC);
Atividades; Sequência; e Modelo de Entidade e Relacionamento - Extended (MEREX) serão exibidos. No quinto capítulo a implementação do software será iniciada e
na conclusão, haverá seu desfecho com os resultados e análises gerais do trabalho.
14
1 FUNDAMENTOS CONCEITUAIS E TECNOLOGIAS UTILIZADAS
Este primeiro capítulo aborda alguns fundamentos e tecnologias utilizadas,
como softwares próprios para o desenvolvimento da modelagem e da codificação.
1.1 JAVA
Em 1991 a Sun Microsystems, ao analisar como os computadores
modificaram a forma de gerenciamento dos negócios e a vida das pessoas, fez o
financiamento de um projeto de pesquisa corporativo interno chamado Green que
deu origem a uma linguagem de programação baseada na linguagem C++, a atual
linguagem Java. (DEITEL; DEITEL, 2005)
De acordo com o pensamento dos irmãos Deitel (2005), o pesquisador James
Gosling, enquanto trabalhava no projeto, observava uma árvore de Carvalho pela
janela. Então, ao terminar o projeto, Gosling resolveu homenagear a árvore dando o
nome à linguagem de programação resultante do seu trabalho de Oak, que significa
Carvalho em inglês.
Entretanto, descobriu-se que já havia uma linguagem com este nome, então
quando a equipe da Sun visitou uma cafeteria local, o nome da cidade Java, que era
a cidade de origem de um café importado foi sugerido. A partir daí o nome da
linguagem de programação desenvolvida pela Sun Microsystems passou a ser Java,
e este nome permanece até hoje. Até 1995 não era um nome formalizado, mas
desde então, após ser anunciado pela Sun em uma conferência em maio do ano em
questão, este se tornou seu nome formal. (DEITEL; DEITEL, 2005)
Segundo Gonçalves (2006), uma das principais vantagens da linguagem Java
é que ela é portável para diversos SOs, e não para apenas um específico.
Outro fator importante desta linguagem, é que ela possuí um tamanho
reduzido, uma vez que depois de instalada uma máquina virtual em um computador,
os arquivos Applet eram pequenos, assim como a velocidade de transmissão da
época, ficando mais fácil a visualização destes aplicativos. (GONÇALVES, 2006)
Hammerschmidt (2012) salienta que máquina virtual é uma emulação de um
sistema operacional dentro de outro ou de uma aplicação, ou seja, seria um
computador dentro de outro.
Um Applet, nas palavras do site Oracle (2012), trata-se de um programa
15
escrito na linguagem de programação Java que pode ser incluído em uma página
Hypertext Modeling Language (HTML), muitos da mesma forma que uma imagem é
incluída em uma página.
Sabe-se que Java é uma Linguagem de Programação Orientada a Objetos
(LPOO). Ao programar em Java é necessário desenvolver pequenas classes que
possuem métodos que realizam tarefas diferenciadas. De tal forma o programa pode
ser dividido em diversas classes visto que a quantidade delas varia dependendo da
necessidade do programador. Há uma rica coleção de classes chamada Application
Programming Interface (API) que já vem acoplada à linguagem de programação,
com isso, o programador tem a possibilidade de criar suas próprias classes e de
utilizar classes prontas. (POLONE; REAL; SOUZA, 2010)
Ainda seguindo os conhecimentos de Polone, Real e Souza (2010), conforme
o tempo passa a linguagem Java sofre mudanças. Devido ao aumento da criação de
aplicações desenvolvidas em Java houve a necessidade de criar três divisões, as
quais são: Java to Standard Edition (J2SE), Java to Micro Edition (J2ME) e Java to
Enterprise Edition (J2EE). A partir do ano de 2006, o número 2 foi retirado das
siglas, e elas passaram a ser chamadas de Java Standard Edition (JSE), Java Micro
Edition (JME) e Java Enterprise Edition (JEE) respectivamente.
De acordo com a pesquisa de Polone, Real e Souza (2010), a plataforma JSE
tem a função de desenvolvimento e implantação de aplicativos em Java para
desktops e servidores. As aplicações atuais exigem cada vez mais do desenvolvedor
e o Java oferece uma rica interface de usuário, portabilidade, versatilidade,
desempenho e segurança.
O ambiente da plataforma JME é robusto e flexível, funcionando em
dispositivos embarcados e dispositivos móveis (impressoras, telefones celulares,
decodificadores, assistentes pessoais digitais). Além de possuir uma interface
flexível e segurança robusta, o JME inclui protocolos de rede interna e suporte de
aplicativos online e offline. (POLONE; REAL; SOUZA, 2010)
O JEE é utilizado para desenvolver softwares corporativos, possuindo
Service-Oriented Architecture (SOA) que pode ser traduzido como arquitetura
orientada a serviços e aplicativos da web de última geração. (POLONE; REAL;
SOUZA, 2010)
Compartilhando
seus
conhecimentos,
Gonçalves
(2006)
afirma
que
atualmente a linguagem Java é utilizada por grandes bancos, empresas que
16
desejam enviar e receber grande quantidade de dados e que necessitam de
portabilidade e estabilidade na conexão com outras empresas.
Ademais, é importante falar sobre a Interface usada para desenvolvimento do
software. O site Oficina da Net explica que o NetBeans se trata de um ambiente de
desenvolvimento integrado ou Interface Development Environment (IDE) Java, o
qual foi desenvolvido pela empresa Sun Microsystems.
Gonçalves (2006) salienta que a IDE é escrita totalmente em Java e é opensource (possui código aberto), evoluindo de forma acentuadamente rápida na
questão das funcionalidades que possui a cada versão lançada.
Este software bastante utilizado para criar outras aplicações será uma das
ferramentas utilizadas no desenvolvimento do SI deste trabalho já citado
anteriormente. A versão utilizada do programa será a 7.2.
Vale ressaltar que o NetBeans é gratuito e, segundo o site Oficina da Net
pode ser executado em múltiplas plataformas, como Windows, Linux, Solaris, e Mac
OS.
1.2 UML
É importante dizer que ao se falar de processo no contexto da Engenharia de
Software, há uma referência direta às etapas de criação e conclusão de um
software, desde a sua aprovação ao treinamento do usuário do produto final.
(MEDEIROS, 2004)
Portanto, a UML não é um processo de desenvolvimento de softwares, mas
sim uma linguagem. Por meio de diagramas, esta linguagem deve fazer a
comunicação entre duas partes: o desenvolvedor do software e o cliente que pediu a
ferramenta. (MEDEIROS, 2004)
Considerando as ferramentas utilizadas, os diagramas da UML serão
desenvolvidos com o auxílio do Astah, ferramenta gratuita que possibilita a criação
de diagramas em UML. Por ser uma versão community possui algumas limitações.
Essa ferramenta tem como principal função realizar a integração entre os casos de
uso, componentes, diagramas de estado, classes, sequência, atividade etc.
(LOYOLA, 2011)
O software será todo desenvolvido de acordo com as regras da UML 2.0.
Serão respeitadas todas as fases propostas pelo Processo Unificado (PU), as quais
17
segundo Medeiros (2004) são: Concepção, Elaboração, Construção e Transição. E
também serão seguidos os seus workflows que se tratam de atividades que
possuem um objetivo comum. Os workflows são: Requisitos, Análise, Projeto,
Implementação e Testes.
A seguir serão detalhadas as fases para a construção de um software.
1.2.1 Primeira fase: Concepção
A construção de um software surge da necessidade do stakeholder.
Stakeholder é aquele que possui interesse pelo sistema que será desenvolvido, ele
pode ser uma organização ou pessoa. (PAIVA, 2007)
Contudo, na maioria das vezes o stakeholder não sabe o que ele realmente
quer, sequer possui uma imagem mental daquilo que necessita, ele simplesmente
sabe que precisa de algo para ajudá-lo. (MEDEIROS, 2004)
De acordo com Rational Unified Process (RUP) a alvo dominante da fase de
concepção é abarar o consenso entre todos os envoltos sobre os objetivos do ciclo
de vida do projeto. A fase de iniciação (concepção) tem muita importância
principalmente para os esforços dos novos desenvolvimentos, nos quais há muitos
riscos de negócios e de requisitos que precisam ser tratados para que o projeto
possa prosseguir. (RUP, 2007)
Nesta fase é pensado em como será o software, são avaliadas as tecnologias
que são relacionadas aos principais riscos e são detectadas as áreas mais criticas
que devem ser tratadas. (MEDEIROS, 2004)
Com as informações adquiridas é criado um documento chamado Visão que é
apresentado ao cliente. Neste documento, constarão alguns diagramas como:
diagrama de Caso de Uso, Atividades, Classes e um Modelo de Entidade e
Relacionamento. Com isso, é informado ao stakeholder o preço e o prazo para a
construção do software. (MEDEIROS, 2004)
Como resultado, os documentos de Nomenclatura e Glossário começam a ser
desenvolvidos a partir daqui, uma vez que passam por todas as fases do PU.
(MEDEIROS, 2004)
Esta etapa termina após a escolha das tecnologias a serem utilizadas, como
por exemplo: Banco de Dados, Linguagem de Desenvolvimento, Ambiente de
Desenvolvimento, entre outras. (MEDEIROS, 2004)
18
1.2.2 Segunda Fase: Elaboração
O alvo principal da fase de elaboração é criar a baseline para a arquitetura do
sistema a fim de prover uma base estável para o esforço da fase de construção. A
arquitetura se amplia a partir de uma inspeção dos requisitos mais expressivo
(aqueles que têm grande impacto na arquitetura do sistema) e de uma avaliação de
risco. A estabilidade da arquitetura é avaliada por meio de um ou mais protótipos de
arquitetura. (RUP, 2007)
Baseline tem como definição ser 'imagem' de uma versão de cada artefato no
repositório do projeto. Ela funciona como um padrão oficial básico para os trabalhos
subseqüentes. Somente alterações autorizadas podem ser efetuadas na baseline.
(RUP, 2007)
1.2.3 Terceira Fase: Construção
Durante esta fase, o interessado deve a todo o momento fazer teste de
versões beta (ou versões de teste) do sistema, a cada iteração surge uma nova
versão beta (o surgimento de uma nova versão é sinal do fim de uma iteração).
(MEDEIROS, 2004)
1.2.4 Quarta Fase: Transição
No fim do ciclo de vida da Fase de Transição, as metas devem ter sido
atendidas e o software deve estar em uma posição de finalização. (RUP, 2007)
O ciclo de vida do software termina nesta fase. Na fase de transição parte do
software deixa de ser beta e pode ser avaliado como versão final, já que não deve
possuir muitos erros. Por fim, encerra-se o desenvolvimento quando há a
homologação. (MEDEIROS, 2004)
1.3 BANCO DE DADOS ORACLE
Os bancos de dados Oracle, atualmente, estão entre os mais utilizados no
desenvolvimento e engenharia de softwares em todo o mundo. (FARIAS, 2007)
Em 1977 surgia uma empresa que futuramente criaria um sistema de
19
gerência de banco de dados que revolucionaria o mercado de armazenagem de
dados, a Software Development Labs (SDL). Ela prestava consultoria a outras
empresas e a equipe era formada pelo profissional Bob Miner (presidente) e os
engenheiros de software Ed Oates e Bruce Scott. Envolvido na história, Larry Ellison
trabalhava para uma das empresas a qual a SDL dava consultoria, explica Farias
(2007).
Farias (2007) ainda explica que no ano de 1978, a empresa muda seu nome
para Relational Software Inc. (RSI) e posteriormente, em 1982, altera para Oracle
Systems Corporation (OSC) sendo que no mesmo ano, simplifica para Oracle
Corporation.
A seguir serão explicadas, sucintamente, as estruturas do banco de dados
Oracle e sua arquitetura de processos.
1.3.1 Estrutura do banco de dados
O Banco de dados Oracle é dividido em duas estruturas: física e lógica. As
estruturas são separadas no servidor, logo é possível que seja feito o
armazenamento físico dos dados sem interferir o acesso às estruturas lógicas do
armazenamento, segundo o autor Ramalho (2005).
1.3.1.1 Estrutura Física
Ainda seguindo os pensamentos de Ramalho (2005), o sistema operacional
possui arquivos que determinam a estrutura física do banco de dados. Existem três
arquivos que formam os bancos de dados Oracle, estes são datafiles, arquivos de
registro redo e arquivos de controle.
A saber, um arquivo datafile possui todos os dados das estruturas lógicas do
banco de dados, estas podem ser tabelas e índices, e são armazenados fisicamente
nos datafiles. (ORACLE, 2010)
Já arquivos de registro redo tem o objetivo de registrar as alterações que
foram feitas nos dados do banco, sendo assim, se houver alguma falha ela pode ser
consultada por meio destes arquivos, exemplifica Ramalho (2005).
Os arquivos de controle são arquivos que registram a estrutura física de um
banco de dados, os nomes e locais de bancos de dados associados e refazem os
20
arquivos de log, o carimbo de tempo da criação do banco de dados, o número de
seqüência atual de log e informações checkpoint. Ao iniciar o banco de dados o
arquivo de controle informa quais arquivos do banco e de registro redo devem ser
abertos para executar a operação solicitada. (ORACLE, 2010)
1.3.1.2 Estrutura Lógica
Estruturas lógicas de um banco de dados Oracle incluem tablespaces, objetos
de esquema, blocos de dados, extensões e segmentos. Como as estruturas físicas e
lógicas são separadas, o armazenamento físico dos dados pode ser gerenciado sem
afetar o acesso a estruturas de armazenamento lógico. (ORACLE, 2010)
Em virtude, os tablespaces são espaços lógicos de armazenamento que
possuem estruturas lógicas relacionadas, que geralmente todos os objetos são
agrupados, simplificando operações administrativas. (RAMALHO, 2005)
Um esquema se trata de um conjunto de objetos de banco de dados, já os
objetos de esquema, referem-se diretamente aos dados e são estruturas lógicas.
Este segundo contém estruturas como tabelas, visões, sequência, procedimentos
armazenados etc. afirma Ramalho (2005).
Já sobre o bloco de dados, é a menor unidade lógica de armazenamento de
dados em um banco de dados Oracle. Também chamado de blocos lógicos, blocos
Oracle, ou páginas. Um bloco de dados corresponde a um número específico de
bytes de dados de espaço físico no disco. (ORACLE, 2010)
A propósito, as extensões nada mais são do que uma aglomeração de blocos
de dados contíguos, e são utilizadas para armazenar determinadas informações.
(RAMALHO, 2005)
E ainda utilizando os conhecimentos de Ramalho (2005), segmentos são
conjuntos de extensões alocados para determinada estrutura. Eles podem ser de
dados, índices, rollback ou temporário.
1.3.2 Arquitetura de Processos
Um processo nada mais é que uma “thread de controle” ou um mecanismo do
próprio sistema operacional usado para executar etapas definidas. Para alguns o
melhor termo a ser usado para definir isso é trabalho ou tarefa. Um processo possui
21
sua área privada para executar na memória. (RAMALHO, 2005)
Threads são sequências de instruções que serão executadas por um
programa. Elas são executadas de forma independente dentro de um processo.
(MORIMOTO, 2007)
Cada processo em uma instância Oracle executa um trabalho específico. Ao
dividir o trabalho de aplicativos Oracle e banco de dados em vários processos,
vários usuários e aplicações podem se conectar a uma instância única base de
dados simultaneamente. (ORACLE, 2010)
Os servidores Oracle possuem processos distintos denominados processos
de usuário e processos Oracle, que serão investigados a seguir. (RAMALHO, 2005)
1.3.2.1 Processos de Usuário
Um processo de usuário executa códigos de software de aplicativo ou
ferramenta do Oracle. Este tipo de processo também serve para gerenciar uma
comunicação com processos de servidor por meio da interface de um programa diz
Ramalho (2005).
1.3.2.2 Processos do Oracle
De acordo com o
manual da Oracle (2010) os processos do Oracle são
executados a partir de outros e executam funções para esses que os invoca. Eles
são formados por processos de servidor e de segundo plano.
22
2 DOCUMENTOS INICIAIS DE UM SOFTWARE
Neste capítulo são abordados os documentos iniciais para o desenvolvimento
de um software, bem como o mercado de aluguel de roupas funciona, a forma como
a empresa Beleza Pura de Lins trabalha e sua história e por fim, a expectativa do
software desenvolvido.
Segundo Medeiros (2004), os documentos iniciais para um software são
documento visão, diagrama de caso de uso e Documento Nomenclatura (este último
não abordado no trabalho).
2.1 ANÁLISE DE MERCADO
Os SI são elaborados para agilizar os negócios e facilitar na tomada de
decisão, entretanto, há muitas lojas de aluguel de roupas que ainda recusam
softwares que facilitariam seus serviços. (BALBÉ, 2012)
Na própria rede internet é possível encontrar diversos programas para lojas
do ramo, mas alguns deles são um tanto ineficientes na questão de recursos. Por
exemplo: às vezes a proprietária da loja deseja relatórios mensais de aluguéis de
vestidos organizados pelas clientes, porém, o sistema somente emite relatórios
organizados por vestido. Por isso é importante antes de elaborar um sistema,
levantar os requisitos por meio de entrevistas com o stakeholder, filtrando as
informações passadas por este a fim de identificar o que ele realmente precisa.
(MEDEIROS, 2004)
É altamente aconselhável desenvolver sistemas próprios ao invés de pegar
prontos na internet ou comprar softwares que foram desenvolvidos para outros
negócios.
2.2 HISTÓRICO DA EMPRESA
Em entrevista com a proprietária da loja, foram adquiridas informações úteis
para elaboração de um histórico empresarial.
A loja Beleza Pura situada em sua própria residência na Rua Antônio Garbi,
número 200 no Bairro Alto de Fátima em Lins/SP, surgiu do chamado Culto das
Prosperidades, na Igreja do Segundo Evangelho Quadrangular.
23
Nesta época, a atual proprietária do negócio passava por grandes
dificuldades familiares, após encerrar uma sociedade que possuía com sua mãe e
trocar de religião.
Ela passou a frequentar a nova igreja e, espelhando-se na Bíblia, teve a ideia
de criar o negócio em sua própria moradia, iniciando suas atividades em dezenove
de agosto de dois mil e oito. Desde então, a loja cresce cada vez mais, tal como sua
popularidade.
Figura 2.1 - Imagem da Loja.
Fonte: Elaborado pelos autores, 2012.
2.3 LEVANTAMENTO DE REQUISITOS
É certo que os preços do aluguel dos vestidos variam de acordo com suas
características e quantidade de vezes que foi alugado, salientando que é importante
que a reserva do vestido seja feita com antecedência, para evitar problemas.
Na hora da escolha do vestido é preciso ficar atento a alguns detalhes, como
por exemplo, estilo da festa, horário, biotipo de quem vai usá-lo, tendências, etc.
A cliente chega à loja e escolhe um vestido para alugar. Ela verifica com a
funcionária se a peça está disponível para locação. Se estiver, a interessada em
alugar a veste informa a data da festa, assina o contrato, deixa um sinal de R$20,00
24
e agenda uma data para prová-lo, na mesma semana em que o evento ocorrerá, a
fim de que sejam feitos ajustes no manequim.
A cliente pode efetuar o pagamento em dinheiro, o que deve ser feito no dia
da retirada do traje, já a devolução é feita dois dias após a celebração. Outras
possibilidades de pagamento são cheque (pagamento que pode ser efetuado em
trinta ou sessenta dias) ou cartão de crédito (pagamento em até duas vezes).
O valor da locação é baseado nos definidos por diversas lojas do ramo. Há
também a possibilidade da compra do vestido por parte da cliente, uma vez que se a
roupa nunca foi alugada, ela pode ser vendida com uma porcentagem a mais sobre
o seu valor real.
Sem dúvida, os problemas começam na hora de verificar se o vestido está
disponível ou não. A pesquisa é realizada em meio aos contratos escritos ou
planilhas eletrônicas, gerando atraso no atendimento.
Também são feitos relatórios mensais das locações realizadas. Para tanto é
contratado um contador particular que fica responsável por efetuar os cálculos da
folha.
Por fim, a loja necessita de um software próprio para solucionar os problemas
acima citados, diminuindo as despesas da loja e melhorando o atendimento e
tomada de decisões por parte dos funcionários.
A seguir será abordado o documento visão, organizando os problemas acima
citados.
2.4 DOCUMENTO VISÃO
O documento visão é formado pelos principais assuntos que o negócio a ser
informatizado
deve
fornecer.
Geralmente
ele
vem
junto
ao
contrato
de
desenvolvimento do software. (MEDEIROS, 2004)
2.4.1 Introdução do problema
A loja Beleza Pura situada em Lins, atualmente enfrenta problemas com
relação ao controle de aluguel de vestidos, precisa ser informatizada para gerar uma
melhor organização e controlar os aluguéis, nas seguintes questões: falha ao
25
controlar os vestidos locados; deficiência no controle de manutenção dos vestidos;
desorganização no agendamento dos horários de prova dos vestidos; dificuldade
para verificar se um vestido já está locado; falta de informações pessoais das
clientes; perda de dados; inadimplência; ineficiência na geração dos relatórios.
Estes problemas afetam toda a equipe da loja e suas clientes, dificultando o
atendimento, causando a perda de clientela para os concorrentes próximos, falha no
controle das locações e impaciência das clientes.
Uma solução para as ocorrências seria a criação de um sistema de controle de
aluguéis, acelerando o processo de locação e facilitando o processo de cobrança.
2.4.2 Instrução sobre a posição do produto
O produto desenvolvido será destinado à loja Beleza Pura, que assim como
algumas outras locadoras de vestidos, carecem de uma solução integrada que atinja
todos os seus processos no controle de aluguel dos vestidos.
Com a criação do produto, busca-se integrar todas as ações de processos de
locação da loja, a menos que os funcionários da empresa não aceitem mudar e
atualizar os dados de cada locação que são chave. Dessa forma, é esperado que o
sistema atinja os objetivos de forma concisa.
2.4.3 Resumo dos envolvidos
Há apenas dois envolvidos no sistema, a proprietária e a atendente.
A proprietária é a pessoa responsável pela empresa e administração do
sistema. Ela será o usuário principal do sistema, responsável pelos processos de
cadastro, atualização e exclusão de usuários e clientes.
Já a atendente é a pessoa responsável pela recepção às clientes e por
efetuar as locações.
Será a usuária secundária do sistema, responsável pelos processos de
cadastro de clientes, atualização, exclusão de cadastro, bem como, é responsável
por efetuar a locação e a devolução dos vestidos e ainda a cobrança das locações
26
pendentes.
2.4.4 Ambiente do usuário
A empresa Beleza Pura de Lins conta hoje com a proprietária da loja que
trabalha em todos os turnos e uma atendente que trabalha em turnos de oito horas
de segunda a sexta, efetuando as locações solicitadas. Todo controle é manual, feito
por meio de fichas catalográficas.
A verificação dos trajes já locados é feito manualmente em meio aos
contratos após a solicitação da cliente. Caso o traje já esteja locado para o dia que a
cliente solicitou, fica a gosto de a cliente escolher outra roupa. Após a escolha do
vestido, é preenchido o contrato de locação e é agendada a data da prova do
vestido para a mesma semana do evento.
2.4.5 Perspectiva do produto
O desenvolvimento deste sistema pode ser considerado uma oportunidade no
mercado que até então está sendo mal explorada. O mercado linense, hoje, neste
segmento, não possui um produto específico capaz de atender as necessidades da
proprietária. Capaz também de integrar os diversos setores de negócios de uma
locadora de vestidos para festas podendo ser a oportunidade para customização do
programa desenvolvido e lançamento de uma ferramenta de prateleira.
A utilização de um software para controle de aluguel de roupas para festas
agilizará e controlará cada locação, com isso a presteza, eficiência e qualidade do
atendimento será muito melhor.
Certamente o usuário poderá realizar cadastro de clientes para autorizar
locações, também será possível fazer consultas e verificar se o vestido está
disponível para a data solicitada pela cliente, lançar no sistema a retirada da roupa,
devolução, agendamento da prova do vestido e pagamento, facilitando o
atendimento e ganhando tempo em cada locação, consequentemente, o sistema
poderá pesquisar preços, conceder descontos à cliente, adicionar um novo vestido,
emitir relatórios de vendas periódicas e controlar o estoque.
27
2.4.6 Premissas e dependências
A empresa pretende investir apenas no software próprio para o negócio, não
desejando investir em novos hardwares e softwares básicos como sistemas
operacionais e sistemas gerenciadores de banco de dados.
2.4.6.1 Necessidades e recursos
A primeira necessidade a ser citada é sobre o cadastro de clientes. A cliente
poderá ser cadastrada no momento da locação, tem prioridade alta e os recursos
utilizados são análise, arquitetura e Sistema Gerenciador de Banco de Dados
(SGBD).
Outra necessidade é sobre o cadastro de usuários. Poderá ser cadastrado
como usuário o(a) atendente da loja, o usuário será cadastrado pela proprietária do
sistema, tem prioridade alta e os recursos utilizados são análise, arquitetura e
SGBD.
E mais uma necessidade é a geração de locação. A locação do vestido
poderá ser feita no local, pela atendente a pedido da cliente cadastrada, sendo que,
nesse caso, a locação deverá ser confirmada in loco pela atendente. Tem prioridade
alta e os recursos utilizados são: análise arquitetura e SGBD.
2.4.6.2 Outros Requisitos do Produto
Uso de um SGBD confiável, que forneça fácil implementação, que ofereça
fácil manutenção e, de preferência, que seja gratuito e uso de interface amigável e
intuitiva.
2.5 Diagrama de casos de uso
Levando em consideração os conhecimentos de Silva (2007), o diagrama de
casos de uso é feito com os casos de uso, atores, e relacionamentos que os
envolvem.
Casos de uso são tarefas executadas para realização de outras atividades.
Estas são atividades maiores que encerram outras menores. (MEDEIROS, 2004)
28
Eles são executados por Stick Man ou atores, que nada mais são como eram
chamados
em
análise
estruturada,
Entidades
Externas.
Eles
não
são
necessariamente pessoas físicas, podem ser máquinas, bancos etc. (MEDEIROS,
2004)
A seguir, encontra-se o diagrama de casos de uso do software desenvolvido.
Figura 2.2 - Diagrama de Casos de Uso
Fonte: Elaborado pelos autores, 2012.
29
3 CASOS DE USO E SUAS ESPECIFICAÇÕES
Este capítulo é composto dos casos de uso e suas especificações para
elaboração do Sistema de Informação proposto.
Assim como Medeiros (2004) cita, Silva (2006) também explana que um caso
de uso é uma funcionalidade atômica de um programa. Um caso de uso representa
uma funcionalidade e não faz referência de como é executado.
No capítulo anterior pode ser encontrado o diagrama de caso de uso e a
seguir, há o detalhamento de cada uma das funcionalidades dos casos de uso
especificados.
Especificação de Caso de Uso: Efetuar Login
Este caso de uso tem como principal objetivo efetuar o login de um usuário no
sistemae.
Dois
atores
podem
atuar
neste
caso
de
uso:
PROPRIETÁRIA/FUNCIONÁRIO.
Fluxo Básico de Eventos
FB1 – INICIAR CASO DE USO – Esse caso de uso é iniciado quando o
PROPRIETÁRIA /FUNCIONÁRIO seleciona a opção EFETUAR LOGIN.
FB2 – INSERIR DADOS – A(O) PROPRIETÁRIA /FUNCIONÁRIO adiciona o
login e senha.
FB3 – CONFIRMAR LOGIN/SENHA – Se os dados forem válidos a(o)
PROPRIETÁRIA /FUNCIONÁRIO, terá acesso ao sistema.
FB4 – ENCERRAR CASO DE USO – Esse caso de uso é encerrado
normalmente.
Fluxos Alternativos
Área de Funcionalidade
FB3 – CONFIRMAR LOGIN
Primeiro Fluxo Alternativo
LOGIN/SENHA INVÁLIDO – Ao adicionar os dados no sistema, caso o
login/senha não forem válidos o sistema emitirá uma mensagem informando o
usuário.
30
Cenários Chaves
CnC1 – Fluxo Básico
Esse fluxo básico é composto pelos passos FB1 a FB4 do Fluxo Básico.
CnC2 – LOGIN/ SENHA INVÁLIDO
FB1 – INICIAR CASO DE USO
FB2- INSERIR DADOS
FB3 – CONFIRMAR LOGIN/SENHA
LOGIN/SENHA INVÁLIDO
FB4 – ENCERRAR CASO DE USO
Pontos de Extensão
Login/Senha inválido
No fluxo básico FB3 – CONFIRMAR LOGIN/SENHA, caso o usuário não
possui acesso ao sistema a proprietária irá cadastrá-lo para o acesso, executar o
Ponto de Extensão <<Cadastrar Usuário>>
Especificação de Caso de Uso: Efetuar Locação
Este caso de uso tem como principal objetivo efetuar a locação de vestidos à
cliente.
Dois
atores
podem
atuar
neste
caso
de
uso:
PROPRIETÁRIA/FUNCIONÁRIO.
Fluxo Básico (FB) de Eventos
FB1 – INICIAR CASO DE USO – Esse caso de uso é iniciado quando a
PROPRIETÁRIA ou o FUNCIONÁRIO seleciona a opção EFETUAR LOCAÇÃO no
sistema.
FB2 – INSERIR DADOS – A PROPRIETÁRIA ou o FUNCIONÁRIO começa o
cadastro do formulário, inserindo os dados necessários para gerar a locação do
vestido.
FB3 – CONFIRMAR LOCAÇÃO – A PROPRIETÁRIA ou o FUNCIONÁRIO
conclui o cadastro do formulário e o sistema verifica a validade dos dados.
FB4 – ENCERRAR CASO DE USO – Esse caso de uso é encerrado
normalmente.
31
Fluxos Alternativos
Área de Funcionalidade
FB3 – CONFIRMAR LOCAÇÃO
Primeiro Fluxo Alternativo
CLIENTE INADIMPLENTE - Ao efetuar o cadastro do formulário, caso a
cliente selecionada possua contas não pagas, o sistema emitirá uma mensagem de
aviso ao usuário do sistema informando sua situação.
Primeiro Subfluxo
ATUALIZAR LOCAÇÃO – Esse caso de uso é atualizado quando a
PROPRIETÁRIA ou o FUNCIONÁRIO seleciona a opção ATUALIZAR no sistema,
podendo alterar e acrescentar qualquer dado ao formulário.
Segundo Subfluxo
CONSULTAR LOCAÇÃO – esta funcionalidade é iniciada quando a
PROPRIETÁRIA ou o FUNCIONÁRIO seleciona a opção CONSULTAR no sistema e
este apresenta um histórico com todas as locações.
Terceiro Subfluxo
CANCELAR LOCAÇÃO – Esse caso de uso é cancelado quando a
PROPRIETÁRIA ou o FUNCIONÁRIO seleciona a opção CANCELAR no sistema.
Cenários Chaves
CnC1 – Fluxo Básico
Esse fluxo básico é composto pelos passos FB1 a FB4 do Fluxo Básico.
CnC2 – CLIENTE INADIMPLENTE
FB1 – INICIAR CASO DE USO
FB2 – INSERIR DADOS
FB3 – CONFIRMAR LOCAÇÃO
CLIENTE INADIMPLENTE
FB4 – ENCERRAR CASO DE USO
32
CnC3 – ATUALIZAR LOCAÇÃO
FB1 – INICIAR CASO DE USO
ATUALIZAR LOCAÇÃO
FB3 – CONFIRMAR LOCAÇÃO
FB4 – ENCERRAR CASO DE USO
CnC4 – CONSULTAR LOCAÇÃO
FB1 – INICIAR CASO DE USO
CONSULTAR LOCAÇÃO
FB3 – CONFIRMAR LOCAÇÃO
FB4 – ENCERRAR CASO DE USO
CnC5 – CANCELAR LOCAÇÃO
FB1 – INICIAR CASO DE USO
CANCELAR LOCAÇÃO
FB4 – ENCERRAR CASO DE USO
Pontos de Extensão
Cadastrar Cliente
No fluxo básico FB3 – SELECIONAR CLIENTE, caso a cliente não esteja
cadastrada, executar o Ponto de Extensão <<Cadastrar Cliente>>
Cadastrar Vestido
No fluxo básico FB3 – SELECIONAR VESTIDOS, caso o vestido não esteja
cadastrado, executar o Ponto de Extensão <<Cadastrar Vestido>>
Especificação de Caso de Uso: Efetuar Venda
Este caso de uso tem como principal objetivo efetuar a venda de algum
vestido
à
cliente.
Dois
atores
podem
atuar
neste
caso
de
uso:
PROPRIETÁRIA/FUNCIONÁRIO.
Fluxo Básico de Eventos
FB1 – INICIAR CASO DE USO – Esse caso de uso é iniciado quando a
PROPRIETÁRIA ou o FUNCIONÁRIO seleciona a opção EFETUAR VENDA.
33
FB2 – INSERIR DADOS – A PROPRIETÁRIA ou o FUNCIONÁRIO começa o
cadastro do formulário, inserindo os dados necessários para a venda do produto.
FB3 – CONFIRMAR VENDA – A PROPRIETÁRIA ou o FUNCIONÁRIO
conclui o cadastro do formulário e o sistema verifica a validade dos dados.
FB4 – ENCERRAR CASO DE USO – Caso de uso é encerrado normalmente.
Fluxos Alternativos
Área de Funcionalidade
FB3 – CONFIRMAR VENDA
Primeiro Fluxo Alternativo
CLIENTE INADIMPLENTE – Ao efetuar o cadastro do formulário, caso a
cliente selecionada possua contas não pagas, o sistema emitirá uma mensagem de
aviso ao usuário do sistema.
Primeiro Subfluxo
ATUALIZAR VENDA – Esse caso de uso é atualizado quando a
PROPRIETÁRIA ou o FUNCIONÁRIO seleciona a opção ATUALIZAR no sistema,
podendo alterar e acrescentar qualquer dado ao formulário.
Segundo Subfluxo
CONSULTAR
VENDA
–
esta
funcionalidade
é
iniciada
quando
a
PROPRIETÁRIA ou o FUNCIONÁRIO seleciona a opção CONSULTAR no sistema e
este apresenta um histórico com todas as vendas.
Terceiro Subfluxo
CANCELAR VENDA – Caso de uso cancelado quando a PROPRIETÁRIA ou
o FUNCIONÁRIO seleciona a opção CANCELAR, então a venda é desativada.
Cenários Chaves (CnC)
CnC1 – Fluxo Básico
Esse fluxo básico é composto pelos passos FB1 a FB4 do Fluxo Básico.
34
CnC2 – CLIENTE INADIMPLENTE
FB1 – INICIAR CASO DE USO
FB2 – INSERIR DADOS
FB3 – CONFIRMAR VENDA
CLIENTE INADIMPLENTE
FB4 – ENCERRAR CASO DE USO
CnC3 – ATUALIZAR VENDA
FB1 – INICIAR CASO DE USO
ATUALIZAR VENDA
FB3 – CONFIRMAR VENDA
FB4 – ENCERRAR CASO DE USO
CnC4 – CONSULTAR VENDA
FB1 – INICIAR CASO DE USO
CONSULTAR VENDA
FB3 – CONFIRMAR VENDA
FB4 – ENCERRAR CASO DE USO
CnC5 – CANCELAR VENDA
FB1 – INICIAR CASO DE USO
CANCELAR VENDA
FB4 – ENCERRAR CASO DE USO
Pontos de Extensão
Cadastrar Cliente
No fluxo básico FB3 – SELECIONAR CLIENTE, caso a cliente não esteja
cadastrada, executar o Ponto de Extensão <<Cadastrar Cliente>>
Cadastrar Vestido
No fluxo básico FB3 – SELECIONAR VESTIDO, caso o vestido não esteja
cadastrado, executar o Ponto de Extensão <<Cadastrar Vestido>>
35
Especificação de Caso de Uso: Lançar Pagamento
Este caso de uso tem como principal objetivo lançar o pagamento efetuado
por
uma
cliente.
Dois
atores
podem
atuar
neste
caso
de
uso:
PROPRIETÁRIA/FUNCIONÁRIO.
Fluxo Básico de Eventos
FB1 – INICIAR CASO DE USO – Esse caso de uso é iniciado quando a
PROPRIETÁRIA ou o FUNCIONÁRIO seleciona a opção LANÇAR PAGAMENTO.
FB2 – INSERIR DADOS – A PROPRIETÁRIA ou o FUNCIONÁRIO começa o
cadastro do formulário de pagamento, inserindo o valor pago pela cliente e
selecionando a locação que está sendo paga.
FB3 – CONFIRMAR PAGAMENTO – A PROPRIETÁRIA ou o FUNCIONÁRIO
conclui o preenchimento do formulário e o sistema verifica a validade dos dados.
FB4 – ENCERRAR CASO DE USO – Esse caso de uso é encerrado
normalmente.
Fluxos Alternativos
Área de Funcionalidade
FB3 – CONFIRMAR PAGAMENTO
Primeiro Fluxo Alternativo
LOCAÇÕES ANTERIORES ATRASADAS - Ao confirmar o formulário, caso
haja formulários anteriores não pagos pela cliente, o sistema emitirá uma mensagem
de aviso ao usuário do sistema.
Segundo Fluxo Alternativo
RECIBO ATRASADO - Ao confirmar o formulário, caso o recibo esteja sendo
pago com atraso, o sistema emitirá uma mensagem de aviso ao usuário do sistema.
Cenários Chaves
CnC1 – Fluxo Básico
Esse fluxo básico é composto pelos passos FB1 a FB4 do Fluxo Básico.
36
CnC2 – RECIBOS ANTERIORES ATRASADOS
FB1 – INICIAR CASO DE USO
FB2 - INSERIR DADOS
FB3 – CONFIRMAR VENDA
RECIBOS ANTERIORES ATRASADOS
FB4 – ENCERRAR CASO DE USO
CnC3 – RECIBO ATRASADO
FB1 – INICIAR CASO DE USO
FB2 - INSERIR DADOS
FB3 – CONFIRMAR PRONTUÁRIO
RECIBO ATRASADO
FB4 – ENCERRAR CASO DE USO
Pontos de Extensão
Efetuar Pagamento
No fluxo básico FB3 - CONFIRMAR PAGAMENTO, caso a locação seja paga
em atraso, o sistema emitirá uma mensagem para o(a) FUNCIONÁRIO, 9em
seguida executar o ponto de extensão <<Efetuar Pagamento>>
Especificação de Caso de Uso: Manter Cliente
Este caso de uso tem como principais objetivos o cadastro, atualizar, excluir e
selecionar dados de determinada cliente. Os atores utilizados são: FUNCIONÁRIO e
ADMINSTRADOR o qual será o ator responsável pelo uso direto do sistema.
Fluxo Básico de Eventos
FB1 – INICIAR CASO DE USO – Esse caso de uso é iniciado quando o/a
ADMINSTRADOR/FUNCIONÁRIO
seleciona
a
opção
MANTER
CLIENTE/CADASTRAR.
FB2 – INSERIR DADOS – Esse caso de uso é iniciado quando o/a
ADMINSTRADOR /FUNCIONÁRIO começa o cadastro da Cliente. (ex.: nome, CPF,
RG etc.).
FB3 – CONFIRMAR CADASTRO – Esse caso de uso é iniciado quando o/a
ADMINSTRADOR /FUNCIONÁRIO conclui o cadastro da Cliente.
FB4 – ENCERRAR CASO DE USO – Caso de uso é encerrado normalmente.
37
Fluxos Alternativos
Área de Funcionalidade
FB3 – CONFIRMAR CADASTRO
Primeiro Fluxo Alternativo
CADASTRO EXISTENTE – Ao efetuar o cadastro caso este já exista, o
sistema emitirá uma mensagem de erro para o/a ADMINSTRADOR/ FUNCIONÁRIO.
Primeiro Subfluxo
ATUALIZAR CADASTRO – Esse caso de uso é editado quando o/a
ADMINSTRADOR/ FUNCIONÁRIO seleciona a opção ATUALIZAR no sistema,
podendo alterar qualquer dado da Cliente.
Segundo Subfluxo
EXCLUIR CADASTRO – Esse caso de uso é excluído quando o/a
ADMINSTRADOR/ FUNCIONÁRIO seleciona a opção EXCLUIR no sistema,
podendo eliminar o cadastro da Cliente.
Terceiro Subfluxo
SELECIONAR CADASTRO – esse caso de uso é iniciado quando o/a
ADMINSTRADOR/ FUNCIONÁRIO seleciona a opção SELECIONAR no sistema,
então este apresenta um histórico das locações da Cliente realçada.
Cenários Chaves
CnC1 – Fluxo Básico
Esse fluxo básico é composto pelos passos FB1 a FB4 do Fluxo Básico
CnC2 – CADASTRO EXISTENTE
FB1 – INICIAR CASO DE USO
FB2 – INSERIR DADOS
FB3 – CONFIRMAR CADASTRO
CADASTRO EXISTENTE
FB4 – ENCERRAR CASO DE USO
38
CnC3 – ATUALIZAR CADASTRO
FB1 – INICIAR CASO DE USO
SELECIONAR CADASTRO
ATUALIZAR CADASTRO
FB3 – CONFIRMAR CADASTRO
FB4 – ENCERRAR CASO DE USO
CnC4 – SELECIONAR CADASTRO
FB1 – INICIAR CASO DE USO
SELECIONAR CADASTRO
FB4 – ENCERRAR CASO DE USO
CnC5 – EXCLUIR CADASTRO
FB1 – INICIAR CASO DE USO
SELECIONAR CADASTRO
FB3 – EXCLUIR CADASTRO
FB4 – ENCERRAR CASO DE USO
Pontos de Extensão
Cadastrar Cliente
No fluxo básico FB3 – SELECIONAR CADASTRO, caso a cliente não esteja
cadastrada, executar o Ponto de Extensão <<Cadastrar Cliente>>
Especificação de Caso de Uso: Manter Usuário
Este caso de uso tem como principal objetivo iniciar o cadastro, atualizar,
excluir e selecionar os dados de uma determinada cliente. Um único ator é utilizado
nesse caso de uso, o ADMINSTRADOR, o qual será o ator responsável pelo uso
direto do sistema.
Fluxo Básico de Eventos
FB1 – INICIAR CASO DE USO – Esse caso de uso é iniciado quando o/a
ADMINSTRADOR seleciona a opção MANTER USUÁRIO/CADASTRAR.
FB2 – INSERIR DADOS – Esse caso de uso é iniciado quando o/a
ADMINSTRADOR começa o cadastro do Usuário. (ex.: nome, CPF, RG e etc.).
FB3 – CONFIRMAR CADASTRO – Esse caso de uso é iniciado quando o/a
39
ADMINSTRADOR conclui o cadastro do Usuário.
FB4 – ENCERRAR CASO DE USO – Esse caso de uso é encerrado
normalmente.
Fluxos Alternativos
Área de Funcionalidade
FB3 – CONFIRMAR CADASTRO
Primeiro Fluxo Alternativo
CADASTRO EXISTENTE – Ao efetuar o cadastro caso ele já exista, o
sistema emitirá uma mensagem de erro para o/a ADMINSTRADOR.
Primeiro Subfluxo
ATUALIZAR CADASTRO – Esse caso de uso é editado quando o/a
ADMINSTRADOR seleciona a opção ATUALIZAR no sistema, podendo alterar
qualquer dado do Usuário.
Segundo Subfluxo
EXCLUIR CADASTRO - Esse caso de uso é excluído quando o/a
ADMINSTRADOR seleciona a opção EXCLUIR e elimina o cadastro do Usuário.
Terceiro Subfluxo
SELECIONAR CADASTRO – esse caso de uso é iniciado quando o/a
ADMINSTRADOR seleciona a opção SELECIONAR no sistema e este apresenta um
histórico com as informações do Usuário realçado.
Cenários Chaves
CnC1 – Fluxo Básico
Esse fluxo básico é composto pelos passos FB1 a FB4 do Fluxo Básico
CnC2 – CADASTRO EXISTENTE
FB1 – INICIAR CASO DE USO
FB2 – INSERIR DADOS
FB3 – CONFIRMAR CADASTRO
CADASTRO EXISTENTE
40
FB4 – ENCERRAR CASO DE USO
CnC3 – ATUALIZAR CADASTRO
FB1 – INICIAR CASO DE USO
SELECIONAR CADASTRO
ATUALIZAR CADASTRO
FB3 – CONFIRMAR CADASTRO
FB4 – ENCERRAR CASO DE USO
CnC4 – SELECIONAR CADASTRO
FB1 – INICIAR CASO DE USO
SELECIONAR CADASTRO
FB4 – ENCERRAR CASO DE USO
CnC5 – EXCLUIR CADASTRO
FB1 – INICIAR CASO DE USO
SELECIONAR CADASTRO
EXCLUIR CADASTRO
FB4 – ENCERRAR CASO DE USO
Pontos de Extensão
Cadastrar Usuário
No fluxo básico FB3 – SELECIONAR USUÁRIO, caso o usuário não esteja
cadastrado, executar o Ponto de Extensão <<Cadastrar Usuário>>
Especificação de Caso de Uso: Manter Vestido
Este caso de uso tem como principal objetivo iniciar o cadastro, verificar e
atualizar os dados dos vestidos no sistema. Dois atores podem executar este caso
de uso: a PROPRIETÁRIA e o FUNCIONÁRIO que terá acesso ao sistema.
Fluxo Básico de Eventos
FB1 – INICIAR CASO DE USO – Esse caso de uso é iniciado quando a
PROPRIETÁRIA ou o FUNCIONÁRIO seleciona a opção VESTIDOS.
41
FB2 – INSERIR DADOS – A PROPRIETÁRIA ou o FUNCIONÁRIO começa o
preenchimento do formulário de dados do vestido.
FB3 – CONFIRMAR DADOS – A PROPRIETÁRIA ou o FUNCIONÁRIO
conclui o preenchimento do formulário e o sistema verifica a validade dos dados.
FB4 – ENCERRAR CASO DE USO – O caso de uso é encerrado
normalmente.
Fluxos Alternativos
Área de Funcionalidade
FB3 – CONFIRMAR DADOS
Primeiro Fluxo Alternativo
CADASTRO EXISTENTE – Ao confirmar o formulário, caso haja um vestido já
com esse nome, o sistema emitirá uma mensagem de aviso ao usuário do sistema.
Primeiro Subfluxo
EDITAR CADASTRO – A PROPRIETÁRIA ou o FUNCIONÁRIO seleciona a
opção EDITAR no sistema, podendo alterar qualquer dado do vestido.
Segundo Subfluxo
CONSULTAR CADASTRO – A PROPRIETÁRIA ou o FUNCIONÁRIO
seleciona a opção CONSULTAR no sistema e este apresenta os dados dos vestidos
já cadastrados.
Cenários Chaves
CnC1 – CADASTRO EXISTENTE
FB1 – INICIAR CASO DE USO
FB2 – INSERIR DADOS
FB3 – CONFIRMAR CADASTRO
CADASTRO EXISTENTE
FB4 – ENCERRAR CASO DE USO
CnC2 – EDITAR CADASTRO
FB1 – INICIAR CASO DE USO
42
EDITAR CADASTRO
FB3 – CONFIRMAR CADASTRO
FB4 – ENCERRAR CASO DE USO
CnC3 – CONSULTAR CADASTRO
FB1 – INICIAR CASO DE USO
CONSULTAR CADASTRO
FB4 – ENCERRAR CASO DE USO
Pontos de Extensão
Cadastrar Vestido
No fluxo básico FB3 – SELECIONAR VESTIDO, caso o vestido não esteja
cadastrado, executar o Ponto de Extensão <<Cadastrar Vestido>>
Especificação de Caso de Uso: Emitir Relatório
Este caso de uso tem como principal objetivo emitir relatórios personalizados
pelo usuário do sistema. Dois atores podem atuar neste caso de uso:
PROPRIETÁRIA/FUNCIONÁRIO.
Fluxo Básico de Eventos
FB1 – INICIAR CASO DE USO – Este caso de uso é iniciado quando a
PROPRIETÁRIA ou o FUNCIONÁRIO seleciona a opção EMITIR RELATÓRIO.
FB2 – SELECIONAR TIPO DE FORMULÁRIO – A PROPRIETÁRIA ou o
FUNCIONÁRIO seleciona o tipo de formulário (Vestido, Cliente, etc.).
FB3 – SELECIONAR FORMA DE ORGANIZAÇÃO – A PROPRIETÁRIA ou o
FUNCIONÁRIO seleciona por qual dado ele quer a organização dos formulários.
FB4 – CONFIRMAR FORMA DE ORGANIZAÇÃO - A PROPRIETÁRIA ou o
FUNCIONÁRIO confirma os dados selecionados.
FB5 – ENCERRAR CASO DE USO – Caso de uso é encerrado normalmente.
43
4 DIAGRAMAS E MODELAGEM DOS DADOS
No decorrer deste capítulo, serão explicados e apresentados todos os
diagramas necessários para a elaboração e desenvolvimento do software proposto
pelo trabalho. Os diagramas apresentados são: Diagrama de Atividade, Classes,
MVC, Sequência, e por fim, o MER-EX.
4.1 DIAGRAMAS DE ATIVIDADE
Diagramas de Atividade descrevem passo a passo cada um dos casos de uso
e suas funcionalidades. Ao fazer uma breve abordagem dos diagramas de atividade,
Medeiros (2004) explica que estes diagramas não são imprescindíveis e que mesmo
sem sua confecção, o desenvolvimento do software pode ter continuidade com base
apenas nos diagramas de casos de uso.
Seguindo os pensamentos de Silva (2007), um diagrama de atividade
representa uma parte do comportamento do sistema modelado. Um conjunto de
atividade e um conjunto de ações pode ser descrito como uma atividade.
O diagrama possui além dos elementos que compõem o conjunto da
modelagem, os fluxos de controle que conduzem da execução de um elemento
expositor de comportamento para um outro, de forma que envolve repetição,
execução condicional e concorrência com nodos que estabelecem mais de um
recurso de execução. (SILVA, 2007)
De acordo com Silva (2007), a aplicabilidade do diagrama de atividade vai
desde modelagem com o mais alto nível, como por exemplo a dinâmica do sistema
ou a sagacidade de caso de uso, até mesmo a modelagem de mais baixo nível,
como a de algoritmo de método da classe.
Com o objetivo de deixar este trabalho completo e bem elaborado, optou-se
pelo desenvolvimento e exposição dos diagramas de atividades baseados em todos
os casos de uso, apesar de Medeiros (2004) recomendar o uso destes diagramas
apenas com os cenários mais complexos.
Na figura 4.1 encontra-se o diagrama de atividade Emitir Relatório. Ele
demonstra passo a passo como o usuário gera relatórios no sistema. Para ser
gerado o relatório os dados passados pelo usuário devem estar segundo o padrão
pré-estabelecido. O funcionário ou a proprietária primeiro deve selecionar qual tipo
44
de relatório deseja (de produtos vendidos ou produtos locados), depois seleciona os
dados que o relatório conterá. Ao final da operação o sistema retorna uma
mensagem com o relatório ocorrido no período solicitado.
Figura 4.1 - Diagrama de Atividade Emitir Relatório
Fonte: Elaborado pelos autores, 2012.
Seguindo nas análises dos diagramas deste capítulo, a figura 4.2 demonstra o
diagrama de atividade Lançar Pagamento, o qual tem por objetivo salvar os
pagamentos efetuados pelos clientes aos funcionários.
Figura 4.2 - Diagrama de Atividade Lançar Pagamento
Fonte: Elaborado pelos autores, 2012.
45
É demonstrado na figura 4.3 o diagrama de atividade Manter Usuário que diz
respeito às operações possíveis de serem feitas com os usuários, desde criar novos
usuários, recuperá-los, alterá-los e excluí-los. Quem executa este diagrama é
somente a proprietária do software.
Figura 4.3 - Diagrama de Atividade Manter Usuário
Fonte: Elaborado pelos autores, 2012.
O diagrama presente na figura 4.4 é o Manter Cliente. Neste caso de uso, o
46
usuário do sistema (que pode ser a proprietária ou o funcionário) executa as
operações de criação, exclusão, alteração e recuperação dos clientes cadastrados
no sistema.
Figura 4.4 - Diagrama de Atividade Manter Cliente
Fonte: Elaborado pelos autores, 2012.
A figura 4.5 é representa o diagrama de atividade Efetuar Locação, tem como
principal objetivo mostrar cada passo que o funcionário deve respeitar para gerar
uma locação a uma cliente, inserindo os dados deste e do vestido que será locado.
47
Figura 4.5 - Diagrama de Atividade Efetuar Locação
Fonte: Elaborado pelos autores, 2012.
Na figura 4.6 encontra-se o diagrama Efetuar Venda. Assim como o diagrama
de Efetuar Locação, ele mostra todos os passos que o usuário do sistema deve
respeitar para gerar uma venda de algum vestido para a cliente.
48
Figura 4.6 - Diagrama de Atividade Efetuar Venda
Fonte: Elaborado pelos autores, 2012.
A figura 4.7 demonstrada o diagrama Efeguar Login. Esse diagrama é um dos
principais do sitema, ele tem por finalidade realizar o login do usuário para que ele
tenha acesso ao sistema.
49
Figura 4.7 - Diagrama de Atividade Efetuar Login
Fonte: Elaborado pelos autores, 2012.
E por fim, mas não menos importante, a figura 4.8 é representada pelo
diagrama de atividade Manter Vestido. Ele mostra as operações de criação,
exclusão, recuperação e alteração que o usuário do sistema pode fazer com relação
aos vestidos.
50
Figura 4.8 - Diagrama de Atividade Manter Vestido
Fonte: Elaborado pelos autores, 2012.
4.2 DIAGRAMA DE CLASSES
Como Medeiros (2004) afirma, um Diagrama de Classes pode ser usado para
mais de um caso de uso. Neste trabalho, há apenas um diagrama de classes para
todos os casos de uso.
Nele encontra-se as classes usadas para implementar o software. Medeiros
(2004) ainda salienta que a esta altura da fase de modelagem, não é necessário que
o diagrama contenha todos os dados do software para a implementação, uma vez
que durante a programação outros atributos, métodos e classes podem surgir de
acordo com a necessidade.
Em uma explicação rápida e sucinta para entendimento do diagrama, é
possível dizer que as classes são os quadrados maiores. Seus nomes estão em
51
negrito na parte superior. Os atributos são os dados que estão dentro delas. Cada
classe relaciona-se com outras e isso está exemplificado ao lado de cada uma.
Figura 4.9 - Diagrama de Classes
Fonte: Elaborado pelos autores, 2012.
52
4.3 DIAGRAMAS DE MVC
Diagramas de MVC seguem a mesma ideia do Padrão MVC. Esse padrão,
segundo Oliveira e Leandro (2007) estabelece uma arquitetura de software que
possui o objetivo de separar a interface que o usuário tem acesso do código que
vem por baixo da aplicação. O Modelo diz respeito às entidades ou classes do
software, Visão tem a ver com o que o usuário visualiza no programa e o Controle é
o intermediário que comanda todas as camadas do software.
Assim como os diagramas de Atividade, para cada caso de uso, um diagrama
de MVC é elaborado.
O primeiro diagrama de MVC exibido é o de Manter Vestido, é mostrado na
figura 4.10. Este diagrama exemplifica a relação entre a camada Visão Manter
Vestido e a camada Modelo Vestido.
Figura 4.10 - Diagrama de MVC Manter Vestido
Fonte: Elaborado pelos autores, 2012.
Seguindo com as análises dos diagramas, a figura 4.11 demonstra o
diagrama de MVC Manter Usuário no qual há a relação entre as camadas Visão
Manter Usuário e Modelo Usuário.
53
Figura 4.11 - Diagrama de MVC Manter Usuário
Fonte: Elaborado pelos autores, 2012.
Ainda observando os diagramas de MVC, é exibido na figura 4.12 as classes
de Visão Manter Cliente e de Modelo Cliente e suas relações, tal como suas classes
de Controle e de Acesso ao banco de dados.
Figura 4.12 - Diagrama de MVC Manter Cliente
Fonte: Elaborado pelos autores, 2012.
54
Na figura 4.13 é mostrado o MVC de Lançar Pagamento com as relações
entre as camadas Visão Lançar Pagamento, Visão Selecionar Locação, Modelo
Pagamento e Modelo Locação.
Figura 4.13 - Diagrama de MVC Lançar Pagamento
Fonte: Elaborado pelos autores, 2012.
Na figura 4.14 encontra-se o diagrama de MVC para o caso de uso Emitir
Relatório. Talvez este seja um dos mais complexos, uma vez que a maioria das
entidades será utilizada, apesar de não usar muitas classes Visões. A única classe
Visão observada aqui é a de Emissão de Relatório, mas as de Modelo são sete:
Cliente, Locação, Itens de Locação, Pagamento, Vestido, Funcionário, Venda e Itens
de Venda.
A figura 4.15 mostra o diagrama de MVC Efetuar Venda. Que mostra as
relações entre as classes de Modelo e de Visão utilizadas no momento em que o
usuário efetua uma venda no sistema.
A figura 4.16 exibe o diagrama de MVC Efetuar Locação que é bem
semelhante ao de Efetuar Venda. As classes de Modelo usadas são todas aquelas
relacionadas à locação e as de Visão são três: Visão Efetuar Locação, Visão
Selecionar Vestido e Visão Selecionar Cliente.
55
Figura 4.14 - Diagrama de MVC Emitir Relatório
Fonte: Elaborado pelos autores, 2012.
56
Figura 4.15 - Diagrama de MVC Efetuar Venda
Fonte: Elaborado pelos autores, 2012.
57
Figura 4.16 - Diagrama de MVC Efetuar Locação
Fonte: Elaborado pelos autores, 2012.
58
E por fim, o diagrama de MVC Efetuar Login figura 4.17, exibe a classe de
Visão Manter Login e de Modelo Usuário e suas relações, tal como suas classes de
Controle e de Acesso ao banco de dados.
Figura 4.17 - Diagrama de MVC Efetuar Login
Fonte: Elaborado pelos autores, 2012.
4.4 DIAGRAMAS DE SEQUÊNCIA
Segundo Medeiros (2004), os diagramas de Sequência são usados para
diversas coisas, como mostrar a colaboração entre duas ou mais classes, mostrar a
evolução de uma situação em determinado momento do software ou até mesmo a
tradução de um Caso de Uso desde a interação do usuário até o final de um
processo.
Todos os diagramas de Sequência deste trabalho foram elaborados a partir
dos diagramas de MVC, sendo assim, para cada um destes diagramas há outro de
Sequência que mostrará passo a passo os passos que o sistema e o usuário
59
efetuam para concluir a operação iniciada.
A figura 4.18 é representada pela sequência dos eventos ocorridos no Caso
de Uso Manter Vestido. Ele vai desde o momento que o sistema entra na tela de
vestidos até quando a classe Controle solicita o registro dos dados no banco e
encerra a operação iniciada.
Figura 4.18 - Diagrama de Sequência Manter Vestido
Fonte: Elaborado pelos autores, 2012.
Na figura 4.19 é exibido o diagrama de Sequência Efetuar Login. A figura 4.20
mostra as operações do diagrama de Sequência Manter Usuário. Já na figura 4.21,
encontra-se o diagrama de Sequência Manter Cliente. Na figura 4.22, há o diagrama
de Lançar Pagamento. Na figura 4.23 pode ser visualizado o diagrama de Sequência
Emitir Relatório. Ainda seguindo com os diagramas que podem ser encontrados
neste capítulo, na figura 4.24, é visível o diagrama de Efetuar Venda e em seguida,
na figura 4.25, encontra-se o diagrama de Efetuar Locação, que é bem semelhante
ao anterior.
60
Figura 4.19 Diagrama de Sequência Efetuar Login
Fonte: Elaborado pelos autores, 2012.
Figura 4.20 - Diagrama de Sequência Manter Usuário
Fonte: Elaborado pelos autores, 2012.
61
Figura 4.21 - Diagrama de Sequência Manter Cliente
Fonte: Elaborado pelos autores, 2012.
Figura 4.22 - Diagrama de Sequência Lançar Pagamento
Fonte: Elaborado pelos autores, 2012.
62
Figura 4.23 - Diagrama de Sequência Emitir Relatório
Fonte: Elaborado pelos autores, 2012.
Figura 4.24 - Diagrama de Sequência Efetuar Venda
Fonte: Elaborado pelos autores, 2012.
63
Figura 4.25 - Diagrama de Sequência Efetuar Locação
Fonte: Elaborado pelos autores, 2012.
4.5 MER-EX
O MER-EX é o último diagrama apresentado neste trabalho. Segundo
Nogueira (2012), ele diz respeito ao mapeamento do mundo real em um modelo
gráfico representativo de modelo e relacionamento existente entre os dados do
banco. Ele foi desenvolvido com o intuito de facilitar o projeto do banco de dados e
permite a especificação de um esquema que represente a estrutura lógica do Banco
de Dados.
Este Modelo de Entidade e Relacionamento mostra os relacionamentos
existentes no banco entre as entidades. Ele é bem semelhante ao Diagrama de
Classes, mas diferentemente deste que é composto das classes da aplicação, ele é
formado das tabelas do banco de dados.
64
Figura 4.26 - Modelo de Entidade e Relacionamento
Fonte: Elaborado pelos autores, 2012.
65
Com este diagrama, conclui-se este capitulo e a modelagem dos dados. No
capítullo seguinte, pode ser conferida a implementação dos dados observados e
produção do software proposto.
66
5 PROTÓTIPO E DESENVOLVIMENTO DO SISTEMA
O protótipo de telas tem por função auxiliar tanto o desenvolvedor, quanto o
cliente, a ter uma visão prévia da preparação, divisão e disposição dos recursos que
estão presentes no sistema.
Este capítulo mostrará e explicará as telas que existem no sistema
desenvolvido para a loja Beleza Pura, com o objetivo de facilitar o entendimento do
sistema para o usuário (proprietária).
A tela inicial de acesso ao sistema, como representado pela Figura 5.1,
solicita ao usuário que sejam fornecidos, identificação (login) e senha. A primeira vez
que abrir a tela de login do sistema, ao apertar o botão “Ok” o usuário será
direcionado para a tela de cadastro de funcionário (Figura 5.6), pois será o primeiro
ao acessar o sistema. O controle de acesso ao sistema tem por finalidade auxiliar a
garantir a privacidade dos dados dos clientes, locação, venda, relatório e etc.
permitindo o acesso somente a pessoas autorizadas. Após autenticar-se no sistema,
é possível navegar entre as funcionalidades do sistema por meio da tela de serviços.
Figura 5.1 - Tela de Login
Fonte: Elaborado pelos autores, 2012.
67
Caso esses dados não forem validados, o sistema retorna uma mensagem de
erro informando que o “login/senha não confere” e é retornado para a mesma tela
(Figura 5.1). Mas, se o usuário digitar nome e senha válidos e selecionar a opção
"Ok", o sistema valida o acesso e direciona o usuário para a seguinte tela (Figura
5.2), que mostra o menu principal de serviços do sistema com todas as opções, do
lado esquerdo: Cadastrar Vestido, Cadastrar Funcionário, Efetuar Locação, do lado
direito: Cadastrar Cliente, Registrar Pagamento, Gerar Relatório e ao centro Efetuar
Venda. Essa tela de serviço pode possuir vários usuários, um deles é a própria
proprietária da loja que possui acesso a todos os campos do sistema e outro(s)
usuário(s) seria(m) o(s) funcionário(s).
Figura 5.2 - Tela de Serviços - Proprietária
Fonte: Elaborado pelos autores, 2012.
Se o usuário que estiver acessando o sistema for um funcionário da loja a tela
de serviços (Figura 5.3) conterá a maioria dos campos citados anteriormente,
apenas a opção de Cadastrar Funcionário ficará oculta, pois só quem tem acesso a
esse campo e pode cadastrar novos funcionários é a proprietária da loja.
68
Figura 5.3 - Tela de Serviços - Funcionário
Fonte: Elaborado pelos autores, 2012.
Ao clicar na opção Cadastrar Vestido (Figura 5.2), uma nova tela é aberta
como pode ser observado a figura 5.4.
Figura 5.4- Tela de Cadastro de Vestido
Fonte: Elaborado pelos autores, 2012.
69
A tela de Cadastro de Vestido possui os campos que correspondem aos
dados de um vestido, são eles: Código, valor, status, valor do aluguel, valor da
venda e descrição. O usuário tem como opção, inserir, excluir, selecionar e atualizar
os dados do vestido. Possui alguns campos obrigatórios que se não forem
preenchidos o sistema emitira uma mensagem de erro.
A tela Cadastro de Cliente (Figura 5.5) apresenta um formulário contendo
campos para cadastro das informações básicas de um cliente, compostas pela
identificação (código). Cada cliente é cadastrado uma única vez no sistema,
recebendo um registro único. Esta e outras telas possuem o campo “Pesquisar por
nome“, é possível buscar o cliente pelo nome, ao digitar aparece na tabela o nome
desejado, depois que apagar todos os dados da tabela voltam normalmente. Após o
preenchimento do formulário, o botão inserir envia a requisição para que os dados
sejam armazenados no banco de dados. Os outros botões trabalham da mesma
forma citados anteriormente (Figura 5.4).
Figura 5.5- Tela de Cadastro de Cliente
Fonte: Elaborado pelos autores, 2012.
A figura 5.6 representa o cadastro de um novo funcionário, essa função como
mostra a figura 5.2, só pode ocorrer se o usuário do sistema for a proprietária, um
outro funcionário que ja esteja cadastrado não possui esse acesso.
70
O cadastro de funcionário possui informações básicas, contendo também um
único código, nome, endereço, dois tipos de telefones, email, salário, e etc. Há
também dois campos importantes, Login e Senha, para ao final do cadastro o
funcionário acessar o sistema com esses dados criados.
Figura 5.6 - Tela de Cadastro de Funcionário
Fonte: Elaborado pelos autores, 2012.
A tela de pagamento representada pela figura 5.7 possui os seguintes dados,
código único, código do cliente, código locação, valor da parcela, data do pagamento
e tipo de pagamento. O tipo de pagamento está sendo representado por Cheque,
Cartão de Crédito e Dinheiro.
O usuário do sistema ao selecionar a opção Cheque, habilita apenas os
campos que são destinados ao cheque, com as seguintes informações, Banco,
Conta Corrente e Número do Cheque.
O Cliente tem a opção de pagar a locação com Cartão de Crédito, o usuário
seleciona a opção cartão no sistema e habilita os seguintes campos, Bandeira,
Dígitos e Operação.
A última opção de pagamento é em forma de Dinheiro, ao selecionar essa
opção é habilitado o campo Moeda (Real, Dólar etc.).
71
Figura 5.7 - Tela Registrar Pagamento Cheque
Fonte: Elaborado pelos autores, 2012.
A Figura 5.8 ér epresentado o pagamento em cartão de crédito.
Figura 5.8 - Tela Registrar Pagamento Cartão
Fonte: Elaborado pelos autores, 2012.
72
Na Figura 5.9 é apresentado a tela de pagamento em Dinheiro.
Figura 5.9 - Tela Registrar Pagamento Dinheiro
Fonte: Elaborado pelos autores, 2012.
A principal tela do sistema é a de locação (Figura 5.10).
Figura 5.10 - Tela Locação
Fonte: Elaborado pelos autores, 2012.
73
A figura 5.10 tela de locação é mostrado os dados que uma locação precisa
ter, código único, data de locação, data de prova do vestido, data do evento, data da
retirada do vestido da loja, valor total, local do evento e o nome do cliente. O usuário
tem como opção, inserir, excluir, selecionar e atualizar os dados da locação.
Há também no sistema a opção de gerar relatório (Figura 5.11), o usuário
coloca no sistema o período desejado e o tipo de relatório como Venda ou Locação.
E relatório geral de vestido, funcionário e Cliente. O sistema irá retornar os dados
solicitados pelo usuário.
Figura 5.11 - Tela Relatório
Fonte: Elaborado pelos autores, 2012.
Por fim, a última tela do sistema, tela de venda representada pela figura 5.12.
Essa tela tem por finalidade registrar a venda de um vestido solicitado por um
cliente.
Antes de registrar a venda é preciso que o usuário cadastre o cliente. Após o
cadastro do Cliente os campos da tela venda são preenchidos automaticamente pois
os dados são recuperados do próprio sistema. O botão inserir envia a requisição
para que os dados sejam armazenados no banco de dados. Nesta tela também é
possível excluir uma venda e atualizar.
74
Figura 5.12 - Tela Venda
Fonte: Elaborado pelos autores, 2012.
Este capítulo explicou os componentes de cada tela existentes no sistema da
Beleza Pura abordando as especificações dos campos e funcionalidades dos
botões.
75
CONCLUSÃO
Ao observar o mercado de aluguel de roupas local, nota-se uma carência de
recursos tecnológicos na questão do gerenciamento de suas atividades. De acordo
com os dados do Serviço Brasileiro de Apoio às Micro e Pequenas Empresas –
SEBRAE (2006), o sucesso de qualquer empresa depende de várias decisões a
serem tomadas. Com base nestes dados, acredita-se que estabelecimentos com
mais recursos tecnológicos tenham uma organização mais rápida, então se chega à
proposta da elaboração de um sistema informatizado próprio para cada loja.
A loja Beleza Pura de Lins apresentava vários problemas de gerência, como a
falta de controle das locações, vendas de vestidos, cadastros de clientes,
pagamento das locações, relatórios em geral, entre outros problemas.
Com o objetivo de sanar esses problemas, pensou-se no desenvolvimento de
um sistema para controlar todos os processos da loja Beleza Pura, buscando agilizar
e facilitar todos os serviços prestados pela loja.
Com base nisso, neste trabalho foram utilizadas e estudadas as tecnologias
básicas para o desenvolvimento do software como: Java, UML e banco de dados
Oracle. A aplicação foi desenvolvida no padrão MVC, possuindo classes com os
atributos necessários e outras com os métodos de persistência e interface gráfica.
Verificaram-se também as necessidades da loja Beleza Pura, apontando possíveis
soluções; a análise dos diagramas, base para a construção do sistema e as técnicas
utilizadas para o desenvolvimento do software.
A utilização de um software para controle de aluguel de roupas para festas
pode agilizar e ajudar a controlar cada locação, com isso a presteza, eficiência e
qualidade do atendimento será muito melhor.
Com o software o usuário pode realizar cadastro de clientes para autorizar
locações, também pode fazer consultas e verificar se o vestido está disponível para
a data solicitada pelo cliente, lançar no sistema a retirada da roupa, devolução,
agendamento da prova do vestido e pagamento, facilitando o atendimento e
ganhando tempo em cada locação, consequentemente, o sistema poderá pesquisar
preços, conceder descontos à cliente, adicionar um novo vestido, emitir relatórios de
vendas periódicas e controlar o estoque.
Fazer pesquisas teóricas antes de iniciar a implementação do software,
76
ajudou a conhecer um pouco mais a origem das ferramentas utilizadas vieram e
para quê elas servem, tal como se eram realmente adequadas para desenvolver o
trabalho.
O desenvolvimento de um trabalho monográfico e a possibilidade prática de
aplicá-lo, decididamente traz maturidade para quem o desenvolve, tanto pessoal
como profissional e ajuda a reforçar os conteúdos estudados durante o curso.
Para trabalhos futuros sugere-se adicionar recursos para a visualização de
fotos de vestidos, desenolvimento de novos relatórios gerenciais com utilização de
gráficos e recursos de backup.
77
REFERÊNCIAS BIBLIOGRÁFICAS
BALBÉ, M.; Como gerenciar a Tecnologia da Informação? 2012. Disponível em:
<http://mariliabalbe.com/como-gerenciar-a-tecnologia-da-informacao-2/>. Acesso em
19 de dez. 2012.
DEITEL, H. M.; DEITEL, P. J. Java: Como Programar. Tradução: Edson
Furmankiewicz. 6 ed. São Paulo: Pearson Prentice Hall, 2005.
FARIAS,
A.
R.
História
do
Oracle.
2007.
Disponível
em
<http://www.devmedia.com.br/historia-da-oracle/4685>. Acesso em: 17 de mar.
2012.
GONÇALVES, E. Dominando NetBeans. 1 ed. Rio de Janeiro: Ciência Moderna
Ltda., 2006.
HAMMERSCHMIDT, R. O que são máquinas virtuais? 2012. Disponível em:
<http://www.tecmundo.com.br/maquina-virtual/232-o-que-sao-maquinas-virtuais.htm>. Acesso em: 11 de jul. 2012.
IBM CORPORATION. Rational Unified Process. 2007. Disponível em
<http://www.wthreex.com/rup/portugues/index.htm>. Acesso em: 17 de dez. 2012.
LOYOLA,
M.
Astah
–
Modelagem
UML.
2012.
Disponível
em
<http://www.mloyola.com.br/astah-ferramenta-para-projetos-em-uml/>Acesso em: 02
de abr. 2012.
MEDEIROS, E. Desenvolvendo software com UML 2.0 definitivo. 1 ed. São
Paulo: Makron Books, 2004.
MORIMOTO.C. E. HyperThreading no Pentium 4? 2007.Disponível em
<http://www.hardware.com.br/artigos/hyperthreading/>. Acesso em: 17 de mar. 2012.
NOGUEIRA, M. Modelo de Entidade e Relacionamento (MER). 2012. Disponível
em <http://www.noginfo.com.br/arquivos/CC_MDados_07.pdf>. Acesso em: 11 de
nov. 2012.
OFICINA DA NET. O que é NetBeans? 2008. Disponível em
<http://www.oficinadanet.com.br/artigo/1061/o_que_e_o_netbeans>. Acesso em: 31
de mar. 2012.
OLIVEIRA, J. M.; LEANDRO, J. L. C. Desenvolvimento de sistema eletrônico de
protocolo com framework prado. 2007. Trabalho de Conclusão de Curso
(Bacharelado em Ciência da Computação) - Universidade Católica de Goiás,
Goiânia.
ORACLE. Applets. 2012. Disponível em: <http://java.sun.com/applets/>. Acesso em:
11 de jul. 2012.
78
_______________.
Glossary.
2005.
Disponível
em:
<http://docs.oracle.com/cd/B19306_01/server.102/b14220/glossary.htm#sthref4184>
. Acesso em: 18 de dez 2012.
PAIVA,
L.
O
que
é
Stakeholder?
2007.
Disponível
em
<http://ogerente.com/stakeholder/2007/02/23/o-que-e-um-stakeholder/>. Acesso em:
10 de mar. 2012.
POLONE, B. S.; REAL, L. G. S.; SOUZA J. R. A. Uso do JSF na construção de
software: estudo de caso – um sistema para consulta de notas. 2010. Trabalho
de Conclusão de Curso (Tecnologia em Sistemas para Internet) – Centro
Universitário Católico Salesiano Auxilium – Unisalesiano, Lins, São Paulo.
RAMALHO, J. A. Oracle 10g: Ideal para quem deseja iniciar o aprendizado do
Oracle. 8 ed. São Paulo: Thomson, 2005.
ROSA, B. E. O que é Sistemas de Informação. 2010. Disponível em
<http://www.artigonal.com/tecnologias-artigos/o-que-e-sistemas-de-informacao3711240.html>. Acesso em: 03 de mar. 2012.
SEBRAE ME. Ponto de Partida Para Início de Negócio: Loja de Roupa. 2006.
Disponível
em
<http://www.dce.sebrae.com.br/bte/bte.nsf/CB23D2E31383112C032572130051E8B1
/$File/NT000B5696.pdf>. Acesso em: 02 de ago. 2012.
SILVA, R. P. UML2 em modelagem orientada a objetos. 1 ed. Florianópolis: Visual
Books, 2007.
79
ANEXO A – CONTRATO PARA LOCAÇÃO DE VESTIDOS