CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA PAULA SOUZA

Transcrição

1 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

2 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

3 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

4 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

5 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

6 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.

7 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.

8 LISTA DE ILUSTRAÇÕES Figura Imagem da Loja Figura Diagrama de Casos de Uso Figura Diagrama de Atividade Emitir Relatório Figura Diagrama de Atividade Lançar Pagamento Figura Diagrama de Atividade Manter Usuário Figura Diagrama de Atividade Manter Cliente Figura Diagrama de Atividade Efetuar Locação Figura Diagrama de Atividade Efetuar Venda Figura Diagrama de Atividade Efetuar Login Figura Diagrama de Atividade Manter Vestido Figura Diagrama de Classes Figura Diagrama de MVC Manter Vestido Figura Diagrama de MVC Manter Usuário Figura Diagrama de MVC Manter Cliente Figura Diagrama de MVC Lançar Pagamento Figura Diagrama de MVC Emitir Relatório Figura Diagrama de MVC Efetuar Venda Figura Diagrama de MVC Efetuar Locação Figura Diagrama de MVC Efetuar Login Figura Diagrama de Sequência Manter Vestido Figura 4.19 Diagrama de Sequência Efetuar Login Figura 4.20 Diagrama de Sequência Manter Usuário Figura 4.21 Diagrama de Sequência Manter Cliente Figura 4.22 Diagrama de Sequência Lançar Pagamento Figura Diagrama de Sequência Emitir Relatório Figura Diagrama de Sequência Efetuar Venda Figura Diagrama de Sequência Efetuar Locação Figura Modelo de Entidade e Relacionamento Figura Tela de Login Figura Tela de Serviços - Proprietária Figura Tela de Serivços - Funcionário... 68

9 Figura Tela de Cadastro de Vestido Figura Tela de Cadastro de Cliente Figura Tela de Cadastro de Funcionário Figura Tela Registrar Pagamento Cheque Figura Tela Registrar Pagamento Cartão Figura Tela Registrar Pagamento Dinheiro Figura Tela Locação Figura Tela Relatório Figura Tela Venda... 74

10 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

11 SUMÁRIO INTRODUÇÃO FUNDAMENTOS CONCEITUAIS E TECNOLOGIAS UTILIZADAS JAVA UML Primeira fase: Concepção Segunda Fase: Elaboração Terceira Fase: Construção Quarta Fase: Transição BANCO DE DADOS ORACLE Estrutura do banco de dados Estrutura Física Estrutura Lógica Arquitetura de Processos Processos de Usuário Processos do Oracle DOCUMENTOS INICIAIS DE UM SOFTWARE ANÁLISE DE MERCADO HISTÓRICO DA EMPRESA LEVANTAMENTO DE REQUISITOS DOCUMENTO VISÃO Introdução do problema Instrução sobre a posição do produto Resumo dos envolvidos Ambiente do usuário Perspectiva do produto Premissas e dependências Necessidades e recursos Outros Requisitos do Produto Diagrama de casos de uso CASOS DE USO E SUAS ESPECIFICAÇÕES... 29

12 4 DIAGRAMAS E MODELAGEM DOS DADOS DIAGRAMAS DE ATIVIDADE DIAGRAMA DE CLASSES DIAGRAMAS DE MVC DIAGRAMAS DE SEQUÊNCIA MER-EX PROTÓTIPO E DESENVOLVIMENTO DO SISTEMA CONCLUSÃO REFERÊNCIAS BIBLIOGRÁFICAS ANEXO A CONTRATO PARA LOCAÇÃO DE VESTIDOS... 79

13 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

14 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 (MER- EX) 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.

15 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

16 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

17 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

18 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 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)

19 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) 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) 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

20 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 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) 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

21 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) 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 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

22 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) 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) 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.

23 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.

24 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 Imagem da Loja. Fonte: Elaborado pelos autores, 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

25 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) 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

26 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 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 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

27 26 pendentes 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 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.

28 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 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 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)

29 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 Diagrama de Casos de Uso Fonte: Elaborado pelos autores, 2012.

30 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.

31 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.

32 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

33 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.

34 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.

35 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>>

36 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.

37 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.

38 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

39 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

40 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

41 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.

42 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

43 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.

44 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

45 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 Diagrama de Atividade Emitir Relatório Fonte: Elaborado pelos autores, 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 Diagrama de Atividade Lançar Pagamento Fonte: Elaborado pelos autores, 2012.

46 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 Diagrama de Atividade Manter Usuário Fonte: Elaborado pelos autores, O diagrama presente na figura 4.4 é o Manter Cliente. Neste caso de uso, o

47 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 Diagrama de Atividade Manter Cliente Fonte: Elaborado pelos autores, 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.

48 47 Figura Diagrama de Atividade Efetuar Locação Fonte: Elaborado pelos autores, 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.

49 48 Figura Diagrama de Atividade Efetuar Venda Fonte: Elaborado pelos autores, 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.

50 49 Figura Diagrama de Atividade Efetuar Login Fonte: Elaborado pelos autores, 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.

51 50 Figura Diagrama de Atividade Manter Vestido Fonte: Elaborado pelos autores, 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

52 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 Diagrama de Classes Fonte: Elaborado pelos autores, 2012.

53 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 Este diagrama exemplifica a relação entre a camada Visão Manter Vestido e a camada Modelo Vestido. Figura Diagrama de MVC Manter Vestido Fonte: Elaborado pelos autores, 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.

54 53 Figura Diagrama de MVC Manter Usuário Fonte: Elaborado pelos autores, 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 Diagrama de MVC Manter Cliente Fonte: Elaborado pelos autores, 2012.

55 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 Diagrama de MVC Lançar Pagamento Fonte: Elaborado pelos autores, 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.

56 Figura Diagrama de MVC Emitir Relatório Fonte: Elaborado pelos autores,

57 Figura Diagrama de MVC Efetuar Venda Fonte: Elaborado pelos autores,

58 Figura Diagrama de MVC Efetuar Locação Fonte: Elaborado pelos autores,

59 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 Diagrama de MVC Efetuar Login Fonte: Elaborado pelos autores, 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

60 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 Diagrama de Sequência Manter Vestido Fonte: Elaborado pelos autores, 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.

61 60 Figura 4.19 Diagrama de Sequência Efetuar Login Fonte: Elaborado pelos autores, Figura Diagrama de Sequência Manter Usuário Fonte: Elaborado pelos autores, 2012.

62 61 Figura Diagrama de Sequência Manter Cliente Fonte: Elaborado pelos autores, Figura Diagrama de Sequência Lançar Pagamento Fonte: Elaborado pelos autores, 2012.

63 62 Figura Diagrama de Sequência Emitir Relatório Fonte: Elaborado pelos autores, Figura Diagrama de Sequência Efetuar Venda Fonte: Elaborado pelos autores, 2012.

64 63 Figura Diagrama de Sequência Efetuar Locação Fonte: Elaborado pelos autores, 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.

65 Figura Modelo de Entidade e Relacionamento Fonte: Elaborado pelos autores,

66 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.

67 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 Tela de Login Fonte: Elaborado pelos autores, 2012.

68 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 Tela de Serviços - Proprietária Fonte: Elaborado pelos autores, 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.

69 68 Figura Tela de Serviços - Funcionário Fonte: Elaborado pelos autores, 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.

70 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, 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.

71 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, , 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 Tela de Cadastro de Funcionário Fonte: Elaborado pelos autores, 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.).

72 71 Figura Tela Registrar Pagamento Cheque Fonte: Elaborado pelos autores, A Figura 5.8 ér epresentado o pagamento em cartão de crédito. Figura Tela Registrar Pagamento Cartão Fonte: Elaborado pelos autores, 2012.

73 72 Na Figura 5.9 é apresentado a tela de pagamento em Dinheiro. Figura Tela Registrar Pagamento Dinheiro Fonte: Elaborado pelos autores, A principal tela do sistema é a de locação (Figura 5.10). Figura Tela Locação Fonte: Elaborado pelos autores, 2012.

74 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 Tela Relatório Fonte: Elaborado pelos autores, Por fim, a última tela do sistema, tela de venda representada pela figura 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.

75 74 Figura Tela Venda Fonte: Elaborado pelos autores, 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.