FUNDAO UNIVERSIDADE FEDERAL DE RONDNIA NCLEO DE CINCIA E TECNOLOGIA DEPARTAMENTO DE INFORMTICA

IURI MANDELA SIMO BATISTA

PROTOTIPAO DE SOFTWARE: UM ESTUDO DE CASO PARA UM MERCADO DE VENDA

DE PRODUTOS VARIADOS.

Porto Velho 2010

FUNDAO UNIVERSIDADE FEDERAL DE RONDNIA NCLEO DE CINCIA E TECNOLOGIA DEPARTAMENTO DE INFORMTICA

PROTOTIPAO DE SOFTWARE: UM ESTUDO DE CASO PARA UM MERCADO DE VENDA

DE PRODUTOS VARIADOS.

IURI MANDELA SIMO BATISTA

ORIENTADORA: MS LILIANE DA SILVA COELHO JACON

MONOGRAFIA SUBMETIDA FUNDAO UNIVERSIDADE FEDERAL DE RONDNIA

COMO REQUISITO PARCIAL OBTENO DO TTULO DE

LICENCIATURA/BACHAREL EM INFORMTICA.

Porto Velho 2010

IURI MANDELA SIMO BATISTA

PROTOTIPAO DE SOFTWARE: UM ESTUDO DE CASO PARA UM MERCADO DE VENDA

DE PRODUTOS VARIADOS.

MONOGRAFIA SUBMETIDA AO CORPO DOCENTE DO CURSO DE BACHARELADO E LICENCIATURA EM INFORMTICA DA FUNDAO UNIVERSIDADE FEDERAL DE RONDNIA COMO PARTE DOS REQUISITOS NECESSRIOS PARA OBETENO DO GRAU DE LICENCIATURA/BACHAREL EM INFORMTICA.

APROVADA POR:

______________________________ Prof, Msc. Liliane da Silva Coelho Jacon

______________________________ Prof. Msc. Marcello Batista Ribeiro

______________________________ Prof, Msc. Carolina Veludo Watanabe

Porto Velho 2010

Dedicatria Ao meu pai que me confia a fazer aquilo que gosto e que a felicidade e satisfao em fazer o que prazeroso o que nos torna mais completos.

Agradecimentos Aos meus amigos que me suportam todos os dias, minha namorada que me apia e me empurra aos estudos todos os dias. minha me que gosta de estudar e acredita da vida acadmica.

Dez mil dificuldades no constituem uma dvida. (Isaac Newton)

RESUMO

Este trabalho apresenta o desenvolvimento de um software para atender s necessidades de um mercado de vendas de produtos variados. O estudo do desenvolvimento visa entender as facilidades de se trabalhar com a Prototipao, que um dos ciclos de vida da Engenharia de Software, e algumas documentaes da UML 2.0. Neste trabalho primeiramente vemos as definies de Engenharia de Software explicando os ciclos de vidas e posteriormente as documentaes escolhidas para o desenvolvimento do Sistema. Ao final apresentado o estado do Sistema e a concluso sobre desenvolvimento desta aplicao.

Palavras-Chave: Prototipao. UML. Engenharia de Software. Sistema. Cliente.

ABSTRACT

This work presents the development of software to meet the needs of a market for sales of various products. The study aims to understand the development of facilities to work with prototyping, which is a life-cycle of software engineering, and some documentation from UML 2.0. In this work we see the definitions of Software Engineering explaining the cycles of life and the documentation subsequently chosen for the development of the system. At the end status is displayed on the system development and completion of this application. Keywords: Prototyping. UML. Software Engineering. System. Customer.

LISTA DE FIGURAS

Figura 1 - Desenvolvimento em Queda d'gua. ...................................................................... 15 Figura 2 - O ciclo de vida clssico. .......................................................................................... 20 Figura 3 - Prototipao. ............................................................................................................ 20 Figura 4 - O modelo espiral. ..................................................................................................... 21 Figura 5 - Tcnicas de quarta gerao. ..................................................................................... 22 Figura 6 - A natureza mutante do desenvolvimento de software. ............................................ 23 Figura 7 - Diagrama de Caso de Uso nvel 0 ............................................................................ 33 Figura 8 Diagrama de Caso de uso nvel 1 Venda. ............................................................ 34 Figura 9 Diagrama de Caso de uso nvel 1 Login. ............................................................. 34 Figura 10 Diagrama de Classes. ............................................................................................ 35 Figura 11 Diagrama do MER. ............................................................................................... 36 Figura 12 - Tela de Login. ........................................................................................................ 37 Figura 13 - Tela de Vendas do Caixa. ...................................................................................... 37 Figura 14 - Tela de Buscas de Produtos e Cdigos. ................................................................. 38 Figura 15 - Tela inicial do Administrador. ............................................................................... 39 Figura 16 - Tela de cadastro e edio dos usurios. ................................................................. 39 Figura 17 - Tela de edio de preo e quantidade dos Produtos. ............................................. 40 Figura 18 - Tela de cadastro de novos Produtos....................................................................... 41 Figura 19 - Tela de cadastro de novas Marcas. ........................................................................ 41 Figura 20 - Janela de Estorno de Produtos ............................................................................... 42 Figura 21 - Modelo do Cupom Fiscal ....................................................................................... 42

LISTA DE ABREVIATURAS E SIGLAS UML Unified Modeling Language. MER Modelo Entidade Relacionamento. BD Banco de dados. RAD Desenvolvimento Rpido de Aplicaes.

SUMRIO

INTRODUO ...................................................................................................................... 10 1. ENGENHARIA DE SOFTWARE E UML ...................................................................... 13 1.1. Engenharia de Software: uma viso geral. ............................................................ 13 1.2. Ciclo de vida de um Software ................................................................................ 19 1.2.1. Os vrios tipos de ciclos de vida. .................................................................... 19 1.2.2. Prototipao .................................................................................................... 23 1.3. UML e seus diagramas .......................................................................................... 25 1.3.1. Documento Viso ........................................................................................... 26 1.3.2. Diagrama de Caso de Uso............................................................................... 27 1.3.3. Diagrama de Classes ....................................................................................... 27 1.3.4. Banco de dados - MER Modelo Entidade Relacionamento ........................... 28 1.4. Consideraes Finais ............................................................................................. 29 2. DESENVOLVIMENTO DA APLICAO..................................................................... 30 2.1. Descrio breve do ramo de negcio da empresa. ................................................. 30 2.2. As pessoas envolvidas (usurios). ......................................................................... 30 2.3. Tecnologias utilizadas. .......................................................................................... 31 2.3.1. Linguagem de programao. .......................................................................... 31 2.3.2. Servidor e banco de dados. ............................................................................. 31 2.4. UML. ..................................................................................................................... 32 2.4.1. Documento Viso. .......................................................................................... 32 2.4.2. Diagrama de Caso de Uso............................................................................... 33 2.4.3. Diagrama de Classes ....................................................................................... 35 2.4.4. O MER Modelo Entidade Relacionamento. ................................................ 35 2.3.5. Interfaces do Sistema. ..................................................................................... 36 2.5. Status do sistema e funcionalidades. ..................................................................... 43 2.6. Dificuldades encontradas. ...................................................................................... 43 2.7. Consideraes finais. ............................................................................................. 44 3. CONCLUSO E TRABALHOS FUTUROS. .................................................................. 45 4. REFERNCIAS BIBLIOGRFICAS ............................................................................. 46

10

INTRODUO O desenvolvimento de um software exige vrios planejamentos, anlises e o uso de tcnicas de programao. Dependendo da complexidade, um software pode levar mais de um ano para que o mesmo seja desenvolvido. Entretanto, na maioria das vezes, os softwares no so criados com o objetivo simples de suprir uma necessidade de mercado ou acrescentar uma nova tecnologia, a maioria dos softwares so para pequenas e mdias empresas, onde h necessidade de armazenamento de dados especficos e pequenas funcionalidades que devem ser automatizadas para agilizar na tomada de decises. s vezes, uma empresa de mdio porte pode no esperar por um trimestre, ou at por um bimestre para que um software apresente algum retorno de seu investimento. O empresrio gosta de ver resultados, funcionalidades e de saber que o pagamento para o desenvolvimento do sistema pedido est norteado para o que sua empresa precisa. Mesmo com essa pressa toda, um sistema precisa de planejamento, diagramao e tabelas, modelagem do banco de dados e estudo adequado de como o sistema ir funcionar na empresa. Aps a criao dos diagramas e modelos mais bsicos, o sistema comea a ser codificado (em qualquer que seja a linguagem), seguindo os passos anteriormente estabelecidos. Entretanto todo sistema susceptvel falhas e por isso, a primeira vez que o usurio usar o programa, provvel que este encontre dificuldades. Isto acarretar em falhas e situaes ainda no pensadas durante a bateria de testes feita pelos desenvolvedores. O fato que a maneira como o desenvolvedor caminha pelo seu programa o mesmo que uma pessoa caminha pela sua casa: conhece todas as portas e sabe o que cada porta deve abrir, um usurio leigo um primeiro visitante, este no sabe onde cada corredor vai dar e o que cada porta ir abrir, apenas sabe que tem algum banheiro em algum lugar, quartos, sala e cozinha.

11

Dessa maneira, mesmo que o programa atenda aos requisitos estabelecidos pelo projeto, algumas funcionalidades podem estar em lugares no funcionais, ou seja, so de difcil acesso, coisas de pouco uso ficam muito aparentes, dados inteis podem estar sendo repetidos desnecessariamente. Com o objetivo de minimizar este tipo de dificuldade, tem-se na engenharia de software um tipo de desenvolvimento especfico chamado Prototipao, que busca encontrar uma soluo aceitvel para este tipo de problema. A prototipao utiliza-se da habilidade do desenvolvedor de software para apresentar de maneira rpida um prottipo para o usurio, que servir como base para norteamento das prximas implementaes.

Justificativa A razo para o desenvolvimento deste projeto que o mercado de trabalho traz como desafio atendimento rpido das necessidades do cliente. Muitas vezes o cliente no quer esperar muito para obter resultados, nem quer saber de planilhas e tabelas. Este deseja ver resultados, ou seja, o sistema funcionando. claro que a prototipao tem suas vantagens e desvantagens, mas se bem dosado com os modelos de diagramao UML, possvel trazer muitos benefcios e resultados curto prazo, tanto para a empresa desenvolvedora do software, quanto para a empresa requisitante do sistema.

Objetivo Este trabalho tem como objetivo aplicar a prototipao da Engenharia de Software, no desenvolvimento de uma aplicao para a um mercado de venda de produtos variados. O objetivo foi desenvolver o sistema de forma rpida e estrutural, sem se delongar em papis e diagramao, mas tambm sem se perder no meio de cdigos sem documentao. Utilizando da idia da Prototipao, em Engenharia de Software, desenvolveu-se um sistema e foi realizada a documentao atravs da UML.

Estrutura da monografia Esta monografia foi estruturada em captulos assim redigidos: O captulo 1 apresenta os principais conceitos de Engenharia de Software, detalha os diagramas a serem elaborados atravs da UML e o modelo entidade-relacionamento no

12

projeto do Banco de dados. Tambm apresenta os ciclos de vida de um sistema, com destaque para a Prototipao. O captulo 2 descreve a aplicao desenvolvida para o mercado de venda de produtos variados. Apresenta o Documento Viso, o Diagrama de Classes com as funcionalidades exigidas e o MER (Modelo Entidade Relacionamento) da aplicao. Neste captulo tambm so abordadas algumas tecnologias utilizadas na elaborao do software. Ao final do captulo esto apresentadas e descritas as principais interfaces do sistema. No captulo 3 tem-se a concluso e sugesto para trabalhos futuros.

13

1. ENGENHARIA DE SOFTWARE E UML Engenharia de software uma rea do conhecimento da computao voltada para a especificao, desenvolvimento e manuteno de sistemas de software aplicando tecnologias e prticas de gerncia de projetos, objetivando organizao, produtividade e qualidade1. Ela possui trs fases, segundo Pressman (1995 p. 46), definio, desenvolvimento e manuteno. Todo o desenvolvimento estaria envolvido dentro dessas trs grandes fases. A UML (Unified Modeling Language) surgiu na necessidade de um padro dentro do mundo da engenharia de software, sendo um modelo de anlise orientado objeto. O Processo Unificado, segundo Medeiros (2004 p. 11) dirigido por Casos de Usos. Pressman (1995 p. 41,42) cita sobre as tcnicas de quarta gerao, onde o desenvolvimento de software precisa de planejamento e documentao significativa. A Prototipao, um dos ciclos de vida da engenharia de software, trabalha de maneira mais simples, com RAD (Rapid Application Development), que usa aplicaes de rpido desenvolvimento para mostrar prottipos para o cliente e constantes correes e adaptaes. A UML ento serve como base para documentao e modelagem de todas as etapas do desenvolvimento do software, ajudando na definio, no desenvolvimento e na manuteno. A Prototipao, como ciclo de vida, traz rapidez em software de baixa escala, para desenvolvimento especfico de pequenas empresas. A seguir, ambas sero mais detalhadas.

1.1. ENGENHARIA DE SOFTWARE: UMA VISO GERAL. Medeiros (2004, p. 2) sugere que a construo de um software possui seis estgios: 1) Concepo: a idia inicial formada na mente do idealizador de forma ainda meio obscura, onde este identifica necessidades que precisam ser supridas por algum advento tecnolgico. Talvez por falta de conhecimento tcnico, este no seja capaz de especificar solues e mtodos que atendam as necessidades. Medeiros (2004, p. 2) faz comparao construo civil, onde o cliente tem uma idia e quem vai dizer se esta idia pode ou no ser construda seria o engenheiro civil, de acordo com as especificaes do idealizador e das possibilidades da engenharia. 2) Aprovao da concepo: nesta parte o interessado deve aprovar uma primeira idia para soluo das suas necessidades. So entregues os detalhes de diagramao esboos

http://pt.wikipedia.org/wiki/Engenharia_de_software. acesso em 18 de outubro de 2010.

14

no papel, que requerem algum conhecimento avanado para entendimento e compreenso. Como a viso do interessado de alto nvel, este no possui nada palpvel para apresentao no projeto, e como neste estgio so apresentados modelos tcnicos, claro que algumas especificaes e detalhes sero alterados de acordo com as experincias e conhecimentos dos especialistas envolvidos. Mais uma vez fazendo referncia construo civil, o cliente depois de ver as plantas faz suas crticas e ento decide conforme suas vontades e recusas de mudanas. neste estgio que so decididos todas as propostas que esto no projeto o modelo idealizado anteriormente. 3) Detalhamento completo das necessidades do software: aqui so realizados todos os detalhamentos do software, ou seja, nada prtico ainda, mas novamente so discutidas as diferenas entre as especificaes e a idia, dessa vez de forma mais amadurecida, tanto a idia inicial agora com mais esclarecimentos e o especialista com melhor conhecimento das especificaes, iro apresentar argumentos mais significativos e menos triviais para aperfeioamento do sistema. Em nova comparao com a construo civil, este estgio no sofre grandes mudanas aparentes, mas reafirma as decises sobre as diferenas. 4) Incio da construo: ento se inicia a codificao do sistema, que tem seu incio pelo modelo de Entidades e Relacionamentos. Assim que o interessado observa a primeira idia de interface, as necessidades serem atendidas sofrem mudanas, agora vendo algo mais concreto e com a idia cada vez mais madura. Na construo civil, o interessado visualiza sua idia de uma forma conhecida e forma uma imagem preliminar, e apesar de ser diferente do sonhado, este apenas apresentar objees se a concepo for muito diferente dos requisitos apresentados. Nesta parte algumas coisas so diferentes no comparativo, pois trabalhando com a construo civil no possvel mudar algumas metragens, dimenses do quarto, pois estes acarretam em mudanas fsicas reais, enquanto ainda so possveis algumas mudanas no software, pois mesmo sendo especificado, ainda um modelo lgico de programao, portanto mudanas s acarretaro em novos dados de especificao, no em desastre fsico. 5) Construo e testes: nesta parte o interessado se distancia da parte de desenvolvimento, pois se entende que tudo foi especificado e esclarecido durante os estgios anteriores, portanto nesta etapa espera-se os resultados dos trabalhos anteriores. Este estgio crucial para estabilidade, pois se algum funcionrio for demitido ou desistir do projeto, este

15

perder caractersticas, devido individualidade durante a elaborao dos cdigos, tornando mais complicado dar continuidade ao sistema. O mesmo acontece na construo civil, a troca de um funcionrio pode trazer mudana no ritmo, ordem e prioridades da construo. Gostos diferentes por diferentes modelos podem causar diferenas quanto ao modelo de construo e trazer empecilhos quanto ao andamento da obra. 6) Entrega: quanto chega o momento de entregar o software ao cliente raramente temse alguma comemorao, simplesmente escuta-se no era isso que eu queria realmente, ou est muito bom, mas poderia mudar isso e isso...

Requerimentos
Risco

Anlise e Design
Risco

Implementao
Testes Implantao
Tempo

Figura 1 - Desenvolvimento em Queda d'gua. (Fonte: Desenvolvimento Software com UML 2.0 p. 8)

A Figura 1 mostra que durante o desenvolvimento do Software h um agravamento no risco do desenvolvimento, com o passar do tempo. Guedes (2004, p. 18) sugere que todo software deve ser modelado, pois existe uma grande diferena entre construir uma casa sem projeto e um prdio. preciso planejamento e documentao. Por mais simples que seja um software sempre preciso model-lo, por que como Guedes (2004, p. 18) explica: os sistemas de informao frequentemente costumam possuir a propriedade de crescer. Alguns afirmam que seja pelo fato de que cada software caracterstico, faz-se uma analogia com estar vivo, o mais correto seria dizer que o software dinmico, pois est sempre mudando e se adaptando s necessidades dos usurios e como cada desenvolvedor tem suas caractersticas para programar, este, na maioria das vezes, implica cdigos e algoritmos de prpria preferncia para o programa.

16

Guedes (2004, p. 19) separa em quatro partes o desenvolvimento de software dentro da Engenharia de Software. 1) Levantamento e Anlise de Requisitos: nesta etapa o engenheiro busca as necessidades do cliente dentro da empresa, levando em considerao todos os conhecimentos do engenheiro para que seja feito uma anlise concreta. necessrio dizer que s vezes nem o cliente sabe o que quer, por isso muito importante que a comunicao seja de confiana e mais simples possvel entre o analista e o cliente. neste primeiro estgio que o cliente ir expor suas necessidades e o analista ir relatando e anotando suas solues com base nos estudos e experincias. 2) Prototipao: Guedes (2004, p. 20) usa a prototipao aqui como ciclo de vida para melhor se desenvolver um software. Ele explica que a prototipao como poder escrever um rascunho do sistema e entregar vrios desses rascunhos para aprovao do cliente. Um prottipo apresentaria em sua maioria as interfaces do sistema e as partes onde seriam inseridos os dados e onde estes seriam recuperados, s vezes como listas, outras como relatrios, e o cliente ir dando seu parecer e opinio. Existem muitas plataformas que possibilitam o desenvolvimento com prottipos, elas so conhecidas como RAD ( Rapid Application Development ou Desenvolvimento Rpido de Aplicaes). Algumas so Delphi, C#, C++ Builder, Visual Basic e REALbasic. Neste estudo ser usado REALbasic 2007 para desenvolver o sistema. 3) Prazos e custos: esta uma parte complicada do desenvolvimento de software, pois est muito baseada em experincia de desenvolvimento, ou seja, caso a empresa, engenheiro, desenvolvedor ou programador no tenha nenhuma experincia com alguma ou todas as partes dos requisitos, estes no sero capazes de estabelecer um prazo com alguma preciso. muito importante lembrar que mesmo assim, como todos estes profissionais devem ter estudado para ter alguma noo sobre o assunto, devem apresentar algum prazo, mesmo que errado. O segredo da estimativa oferecer um prazo em que se estipula maior do que o necessrio, e aps algum tempo de desenvolvimento deve-se medir se a quantidade j desenvolvida est de acordo com os prazos estabelecidos, se esto atrasados ou adiantados na agenda. Caso haja atrasos, a empresa deve informar que houve engano no prazo e deve ser feito um novo acordo de prazo. Os custos geralmente so fceis de estabelecer, j que raramente tem-se aumento repentino de custos para um projeto de software, onde o nico grande gasto com tempo e

17

recursos humanos, ou seja, basta estipular o quanto de mo-de-obra ser necessrio para finalizar o projeto. 4) Manuteno: segundo Guedes (2004, p. 23) esta uma etapa muito importante, pois nela em que o custo do software ser gerado, alguns chegam a dizer que 40% 60% dos custos de um sistema est na manuteno. nesta parte que se torna importante a modelagem do sistema (diagramas) e toda a sua documentao, pois os documentos no iro somente ajudar a corrigir erros e melhorias, mas iro ajudar a localizar qualquer detalhe dentro do sistema, facilitando qualquer tipo de mudana que a empresa deseja fazer dentro do software. Lembrando sempre que preciso atualizar as modelagens e a documentao para que se possa confiar posteriormente nestes documentos para futuras consultas. Guedes (2004, p. 24) tambm leva em conta a Documentao Histrica, onde a empresa usaria todas as documentaes dos softwares j desenvolvidos para fazer anlises de crescimentos, administrativo e de produo, o que para este trabalho de desenvolvimento no se apresenta pertinente. Para Pressman (1995 p. 46) a engenharia de software teria apenas trs fases: definio, desenvolvimento e manuteno. Cada uma dessas fases tem as seguintes funes a serem exercidas: A fase de definio procura o qu deve ser feito. Assim, o analista deveria definir as caractersticas do software, como funcionalidades, propriedades, requisitos e limitaes do sistema. Dentro desta fase so identificadas trs etapas: a) Anlise do sistema: a parte onde so descritas as funes do sistema, atribuindo os requisitos que o software atender. b) Planejamento do projeto de software: depois de bem analisado os requisitos, so traados os riscos, recursos e custos para estabelecer os prazos e as atividades a serem exercidas. c) Anlise de requisitos: preciso que haja domnio sobre todas as funes do sistema, para isso analisam-se todos os requisitos necessrios para que as funes do sistema atendam os requisitos especificados. A fase de desenvolvimento procuraria o como. Aps a definio dos requisitos, onde o analista define a estrutura dos dados e a arquitetura que o sistema ter, os programadores e projetores iro transformar as anlises em projeto e cdigos. Os mtodos para se desenvolver podem ser vrios, mas trs passos sempre estaro presentes nesse estgio: a) Projeto de software: aqui o projetista define em conjunto de representaes desde a estrutura dos dados, a arquitetura e os procedimentos. traado um

18

planejamento para que o software siga uma linha de desenvolvimento de cdigo. b) Codificao: Depois do projeto do software, inicia-se a codificao numa linguagem de programao, ou seja, os programadores iro implementar as funcionalidades e propriedades de acordo com as necessidades do sistema. c) Realizao de testes do software: logo depois da implementao do software, devem ser realizados testes para verificar se as funes esto corretas, se no possuem defeitos de lgica e implementao. Esta primeira fase de testes meramente superficial, pois o verdadeiro teste feito com o usurio final, que ir especificar cada dificuldade ou erro encontrado. Por fim a fase de manuteno que se concentra em mudanas que ocorrero ao longo da implantao do software. Vrios aspectos levam um software a sofrer mudanas neste estgio. Nem sempre o cliente especifica aquilo que quer, o ambiente pode ter mudado e procedimentos serem alterados, e tambm, o usurio pode trabalhar de maneira diferente do esperado pelos projetistas. Mas sempre trs mudanas iro aparecer neste estgio: a) Correo: ocorre toda vez que o usurio acha um erro ou acha que o software possui algum erro. Como dito anteriormente, as correes realizadas pelos desenvolvedores so superficiais, assim somente o usurio final quem ir identificar os verdadeiros erros no sistema. b) Adaptao: depois de um tempo o ambiente de trabalho pode mudar, novas caractersticas so agregadas ao trabalho e outras funes podem aparecer ou se tornarem obsoletas. A manuteno adaptativa ir modificar o software em partes para que possa acomodar o software as novas exigncias do trabalho. c) Melhoramento funcional: a medida que o usurio vai aprendendo a lidar com o sistema, este identifica novas funes que podem ser aplicadas em certos meios, e tambm, a experincia com outros sistemas traz novas idias para o usurio. Em alguns casos onde o software alterado mais do que as exigncias solicitadas pelo cliente, chamado de manuteno perfectiva. Apesar de serem apresentadas vrias formas de etapas de desenvolvimento do software, todas elas apresentam basicamente a mesma estrutura de continuidade. O ciclo de vida que ir definir quais partes sero mais destacadas para o desenvolvimento do sistema, de acordo com as necessidades da empresa desenvolvedora e dos resultados esperados. A escolha de um ciclo de vida ir definir como cada estgio, fase ou estado do desenvolvimento de software ser trabalhado, de acordo com sua importncia para os

19

resultados. Ir influenciar tambm na escolha da documentao, definindo quais partes da UML sero necessrias para que o software possa ser desenvolvido no tempo previsto e quais os resultados esperados.

1.2. CICLO DE VIDA DE UM SOFTWARE Rezende (2005, p. 41) diz que normalmente um software tem um ciclo de vida de no mximo cinco anos, pois um software nunca est por acabado, sempre tm manutenes, correes e melhorias. Ele define algumas fases como sendo parte essencial do ciclo de vida natural do software: - concepo: quando a idia do software surge, ou seja, as suas necessidades; - construo: quando so feitas as especificaes, documentaes e a programao; - implantao: onde o software finalmente testado, corrigido e disponibilizado para o cliente; - maturidade e utilizao plena: quando o software tem suas melhorias, muda de aparncia para uma interface mais amigvel, agrega caractersticas e funcionalidades; - declnio: quando um software se torna difcil de ser continuado, adaptado ou restaurado. Quando um software chega a ser obsoleto; - manuteno: a ltima tentativa de sobrevivncia do software, com adaptaes, ajustes e mudanas. Rezende (2005, p. 41) tambm define que neste estado do software possvel que o ciclo de vida fique em espiral ou looping (girando), retardando a morte e o declnio total; - morte: quando um software finalmente abandonado pelos desenvolvedores e passa a se tornar um software finalizado e fechado. Existem sistemas que fogem essas regras, que nunca morrem, por estarem sempre a nvel operacional, como Folhas de pagamento, Contabilidade, Contas a pagar, pois esses sistemas esto baseados em outros sistemas que foram formados e formatados a muito tempo e no devem mudar to facilmente.

1.2.1. OS VRIOS TIPOS DE CICLOS DE VIDA. Pressman (1995, p. 32) define que podem existir vrios tipos de ciclos de vidas. No existe uma forma nica e padro para a resoluo dos problemas de se desenvolver um software, o que existe so vrios modelos, estudos e mtodos que abrangem todas as fases de desenvolvimento, que juntos e bem utilizados vo fazer a engenharia de software.

20

Figura 2 - O ciclo de vida clssico. (Fonte: Engenharia de Software, PRESSMAN p. 33)

Existe o ciclo de vida clssico, a prototipao, o modelo espiral, as tcnicas de quarta gerao e a combinao de paradigmas. O ciclo de vida clssico traz um modelo cascata (ilustrado na Figura 2), onde o ciclo de vida est em um modelo sequencial, um paradigma clssico em que uma fase de desenvolvimento vem aps a anterior ser concluda. As fases so: Anlise de engenharia de sistemas, anlise, projeto, codificao, teste e manuteno.

Figura 3 - Prototipao. (Fonte: Engenharia de Software, PRESSMAN p. 36)

A prototipao, que o modelo adotado neste trabalho (ilustrado na Figura 3), um modelo utilizado quando existe apenas uma idia primria de que o software deve fazer. Assim, o analista ou desenvolvedor no tem idia de como sero as funcionalidades, trazendo assim trs possveis solues:

21

a) um prottipo escrito em papel, com uma idia mais elaborada como resposta as idias iniciais; b) um prottipo em formato digital, apresentando pequenas funcionalidades possveis e um subconjunto de propriedades; c) um programa j existente que pode ter parte ou total das funes bsicas esperadas, mas com outras caractersticas que sero adaptadas pelo novo desenvolvedor para atender o cliente. A prototipao apresenta um ciclo de desenvolvimento no qual o analista coleta e refina os requisitos, elabora um projeto rpido e constri um prottipo. Em seguida o cliente avalia o prottipo, e novamente o prottipo refinado podendo voltar para a projeo do software ou continuar na engenharia. Quando o software sai do modo prottipo, ele recebe o nmero das verses (em termos atuais, sai da verso Alfa ou Beta). A seguir, neste captulo, tem-se um melhor aprofundamento sobre a prototipao.

Figura 4 - O modelo espiral. (Fonte: Engenharia de Software, PRESSMAN p. 39)

O modelo espiral uniu o ciclo de vida clssico com a prototipao, trazendo um novo paradigma de anlise. Ele possui quatro importantes atividades descritas na Figura 4:

22

Planejamento, anlise de riscos, engenharia e avaliao pelo cliente. Ou seja, nesse caso o cliente avalia o software somente aps o mesmo ter passado pela engenharia, e os testes preliminares so realizados pelos desenvolvedores. Este um paradigma usado em grandes sistemas, onde a experincia do grupo de desenvolvimento grande e a avaliao do cliente no resulta em grandes alteraes do software.

Figura 5 - Tcnicas de quarta gerao. (Fonte: Engenharia de Software, PRESSMAN p. 42)

Por fim as tcnicas de quarta gerao ilustradas na Figura 5, que abrange um grande conjunto de ferramentas que possuem uma coisa em comum: a possibilidade do desenvolvedor especificar suas caractersticas e seu modelo de desenvolvimento. Usando as tcnicas de quarta gerao possvel que o desenvolvedor possa gerar resultados com o software sem ter que gerar novos cdigos. Entretanto esse tipo de tcnica de difcil controle e precisa de descries detalhadas. As tcnicas de quarta gerao segue um ciclo de coleta de requisitos, estratgia de projeto, implementao usando as tcnicas de quarta gerao e finalmente os testes. Pressman (1995, p. 43) ainda faz uma previso sobre o uso dessas novas tcnicas, acertando de forma brilhante quando nos deparamos com os modelos UML. Ele diz que cada vez mais ser preciso utilizar dessa nova gerao de modelos, documentao e especificao, com o crescimento acelerado das necessidades de software. A Figura 6 apresenta a dinmica do crescimento acelerado de desenvolvimento de software, prevista por Pressman (pag. 33)

23

Figura 6 - A natureza mutante do desenvolvimento de software. (Fonte: Engenharia de Software, p. 33)

A previso foi feita para at o fim da dcada de 90, quando j estamos entrando na dcada de 20 do sculo 21, onde impossvel no ter sistemas de controles com alta demanda de comunicao com banco de dados, algoritmos mais especialistas e interfaces altamente desenvolvidas.

1.2.2. PROTOTIPAO A Prototipao um ciclo de vida para o desenvolvimento de um software. Um sistema precisa ser encaixado em um ciclo de vida, uma maneira de identificar seus estados dentro do desenvolvimento, para que cada ao seja tomada de acordo com os requisitos especificados pelo seu estado. Uma das vantagens de se trabalhar com esse ciclo de vida que possui uma sequncia de eventos simples e tambm um paradigma eficiente dentro da engenharia de software. Entretanto preciso que tanto o cliente quanto o engenheiro estejam de acordo que a prototipao ser o modelo a ser seguido para o desenvolvimento do software, e que este servir como mecanismo para a elaborao do software final. Segundo Pressman (1995, p. 37), a prototipao comea com a anlise e coleta dos requisitos. Nesta parte muito importante definir os pontos principais e requisitos a serem atendidos para o cliente, pois a Prototipao destina-se a desenvolver um sistema em curto prazo e que atenda especificadamente as necessidades do cliente. No adianta fazer uma grande anlise e um planejamento demorado, pois a prototipao s atrasar o desenvolvimento neste caso.

24

Aps a anlise dever ser feito um projeto rpido, observando apenas os pequenos aspectos em que o cliente tenha ao, como entras e sadas bsicas, interface primria e de alguma forma amigvel, mas ainda no se preocupando com aparncia e aspectos finais. O cliente dever ter um primeiro contato com os resultados primrios e dever apresentar todas as dificuldades, diferentes necessidades, novas idias e tudo que necessitar que mude, pois o prottipo nortear at que ponto o cliente pode pedir e vai ajud-lo a entender como a aplicao ir trabalhar. Depois do cliente ter sua primeira experincia com o prottipo do sistema, o programa sofrer um refinamento, que seria o atendimento de todas as necessidades pedidas pelo cliente, alteraes e melhorias. O refinamento serve como ajuste que mostrar at que ponto o software pode melhorar o trabalho e atender as necessidades, pois nem tudo computvel. Este ciclo se repete at que o prottipo esteja funcionando de modo a atender praticamente todas as necessidades do cliente e operar de maneira agradvel. Aps vrios refinamentos e reprogramaes, o prottipo deve ser finalmente descartado. Esta uma parte constrangedora tanto para o desenvolvedor quanto para o cliente. O cliente no ficar satisfeito em ouvir que ter de ser feito um novo programa, e o engenheiro de software no tem tanta pacincia para ficar desenvolvendo tudo duas vezes. Mas esse o objetivo da prototipao, estabelecer todas as necessidades do cliente e achar as solues de forma prtica ao mostrar resultados e facilitar no entendimento para o programador e o engenheiro. A necessidade de se jogar fora o prottipo que este sofreu tantas modificaes no cdigo que provavelmente est com algumas funes instveis, propriedades sem formatao, estrutura desorganizada e gambiarras por todas as conexes. O fato que no ser jogado fora o software, mas apenas ser construdo um novo a partir do prottipo, mas dessa vez j sabendo os resultados esperados, quais implementaes sero feitas em cada etapa e ter um padro em seu cdigo, de modo a ficar fcil para fazer manutenes a longo prazo. A importncia de acordo entre o cliente e o engenheiro se mostra totalmente necessria, pois aps tanto tempo de uso do sistema funcionando, este ter de mudar e finalmente adquirir caracterstica prpria. A prototipao no tira a necessidade de documentar o sistema, mas ele d a oportunidade de se fazer tanto as documentaes necessrias quanto o desenvolvimento ao mesmo tempo, ganhando em resultados a curto prazo e a realizao de um melhor trabalho entre a rea de anlise de sistema, engenharia de software e programao.

25

1.3. UML E SEUS DIAGRAMAS Medeiros (2004, p. 11) explica que UML no um processo de desenvolvimento, logo, este no norteia como deve ser desenvolvido e para onde vai cada etapa do desenvolvimento. UML simplesmente ajuda sendo uma forma de comunicao que um processo pode utilizar, ou seja, uma simples maneira de pelo menos padronizar a maneira como so feitas as anlises de requisitos, as diagramaes, as modelagens do bando de dados. Assim como no sistema mtrico, existe uma ordem e uma medida certa para cada unidade, s que cada um gosta de usar a medida que lhe parece mais prtica. A UML 2.0 trabalha com vrios modelos de documentao que ajudam ao desenvolvimento no momento de apresentar suas especificaes e diagramaes. Medeiros (2004, p.11) cita os seguintes documentos/diagramas: Documento Viso; Diagrama de Caso de Uso; Diagramas de Componentes e Implantao; Diagrama de Interao Viso Geral e MER (Modelo de Entidade e Relacionamento). J Guedes (2004, p. 26) apresenta vrios diagramas: Diagrama de Caso de Uso; Diagrama de Classes; Diagrama de Objetos; Diagrama de Estrutura Composta; Diagrama de Sequncia; Diagrama de Colaborao (Comunicao na UML 2.0); Diagrama de Grfico de Estados (Mquina de Estados na UML 2.0); Diagrama de Atividades; Diagrama de Componentes; Diagrama de Implantao; Diagrama de Pacotes; Diagrama de Interao Geral; Diagrama de Tempo. Tom Pender (2004, p. 39) diz que os diagramas so separados em quatro grandes grupos, e dentro de cada grupo tem-se os seguintes modelos de diagramas: - Diagramas e produtos de trabalho da UML; - Diagramas de gerenciamento de modelo; - Diagramas estruturais: Diagrama de Classes; Diagrama de Objetos; Diagrama de Estrutura de Composio; Diagrama de Componentes; Diagrama de Implantao; Diagrama combinado de Componentes/Implantao; - Diagramas Comportamentais: Diagrama de Caso de Uso; Diagrama de Atividades; Diagrama de interao; Diagrama de Mquina de Estados; Diagrama de Mquina de Estados do Protocolos. Como se podem observar a UML nos apresenta um escopo completo e de todos os possveis casos de diagramaes e documentaes para os estgios de desenvolvimento de um software. No havendo necessidade de se utilizar algum destes, no h necessidade de documentar. Dentro da apresentao deste trabalho especificadamente sero utilizados apenas

26

quatro modelos: Documento viso, Diagrama de Caso de Uso, Diagrama de Classes e Banco de dados. O motivo que na maioria das vezes o desenvolvimento de um software deste porte (pequeno porte) fica sob a responsabilidade de apenas uma ou duas pessoas, ou seja, a comunicao extremamente facilitada e a necessidades de documentao apenas para dar uma idia especfica e nortear o desenvolvimento de tal modo que toda vez que seja necessrio uma mudana no sistema, a localizao da mudana seja facilmente encontrada e aplicada de acordo com as necessidades no momento de testes e correo de falhas do sistema.

1.3.1. DOCUMENTO VISO O documento Viso um tipo de contrato entre o contratado e o contratante. Nele especificado o que o cliente quer que seja feito, e o desenvolvedor ir se basear nessas especificaes para elaborar o sistema. Medeiros (2004, p. 22) diz que o Documento Viso um relato resumido com os principais requisitos que o software deve atender. Ele deve ser um documento que relata em linguagem de alto nvel, todo o escopo de funcionalidades em que o software ir planejado. Geralmente este documento est presente junto com o contrato de servios, pois neste contrato que iro se basear os prximos documentos. O diagrama de Caso de Uso de nvel 0 baseado neste documento. Este documento nasce na primeira reunio entre o cliente e o projetista. Enquanto o cliente diz sua idia de como o software dever agir quanto implantado, o projetista (com base em seu conhecimento e experincia) identificar quais so os reais requisitos e problemas que o software dever atender. Posteriormente o engenheiro dever analisar este documento, ainda em rascunhos e finalmente desenvolver o documento viso, que possui um modelos com os seguintes tpicos: Introduo; Escopo; Definies, Acrnimos e Abreviaturas; Referncias; Oportunidade de Negcio; Problema a ser solucionado; Descries de Stakeholder e Usurios; Stakeholder; Usurios; Ambiente Atual dos Clientes; Observao; Mdulos; Perspectivas do Produto; Precedncia e Prioridades; Requisitos no funcionais; Requisitos de Sistema e Ambientes; Sistema Operacional; Linguagem de Desenvolvimento; Banco de Dados; Requisitos de Documentao; Viso Geral UML do Sistema Modelo Conceitual. Aps a elaborao do documento Viso, ento ser elaborado o diagrama de Caso de Uso.

27

1.3.2. DIAGRAMA DE CASO DE USO Considerado um diagrama comportamental por Pender (2004, p. 47), este diagrama modela as expectativas que os usurios tm e que o sistema ir oferecer, ou seja, as funcionalidades que o sistema ir implementar para o uso. Os diagramas de Caso de Uso identificam as expectativas dos clientes para o sistema, apresentando um plano de curso para a parte de desenvolvimento, documento e especificando as necessidades do usurio. Identifica recursos especficos do sistema, para que cada detalhe no fuja de descrio, o diagrama de Caso de Uso tem vrios nveis para cada funcionalidade especfica. Identifica o comportamento compartilhado entre os recursos do sistema, facilitando em caso de redundncia, onde um mesmo recurso utilizado vrias vezes em outros casos, facilitando sua implementao e documentao. Oferece um modo simples e fcil de entender para que os clientes entendam os requisitos, fazendo com que a abstrao do conhecimento do especialista e a idia do cliente se formem no papel e haja concordncia entre as partes. Larman (2004, p. 67) considera os casos de uso como um mecanismo amplamente utilizado para descobrir e registrar requisitos. Um caso de uso vem a representar uma forma descrita de como usar o sistema para resolver os requisitos descritos pelo cliente. Os casos de usos seriam em termos simples, casos em que o sistema seria usado pelo usurio, um cenrio onde o usurio estaria se utilizando de todas as funcionalidades que o programa tem e todos os tipos de resultados esperados que o programa deva apresentar como resposta. Os casos de usos so feitos em duas formas, uma escrita, de acordo com os vrios padres existentes, como colunas de ao do usurio e reao do sistema, ou listas de aes e estados possveis com vrias aes do sistema. Posteriormente a diagramao, onde a UML possui um padro para ilustrar os nomes dos casos de usos, atores e seus relacionamentos. Guedes utiliza apenas um tipo de documentao de caso de uso, onde cada caso de uso documentado e separado por vrias etapas e caractersticas. Neste trabalho, ser utilizado este modelo de documentao.

1.3.3. DIAGRAMA DE CLASSES Segundo Pender (2004, p. 42) o diagrama de Classes a origem para a gerao de cdigo(...) e o destino para a engenharia reversa(..). O diagrama modela os recursos usados para montar e operar o sistema. Ou seja, neste diagrama que esto as caractersticas e

28

atribuio de valores de todos os campos do projeto, e como estaro organizados dentro de suas classes. Os diagramas de Classes so importantes, pois definem os recursos essenciais de um sistema, deixando claro onde esto localizadas as funcionalidades que o sistema ir exercer. Define relacionamentos entre os recursos, especificando quais interfaces e caminhos cada recurso se comunica com outro. So gerados cdigos a partir de suas classes, definindo propriedades e como cada propriedade ser trabalhada. Modela-se o cdigo para a engenharia reversa, e toda vez que for necessrio mudar um cdigo, muda-se no diagrama de classes as propriedades e os modos de trabalhos. Alm de oferecer uma direo para os outros diagramas, pois a partir da organizao do diagrama de Classes que sero definidas quais necessidades os outros diagramas iro cobrir.

1.3.4. BANCO DE DADOS - MER MODELO ENTIDADE RELACIONAMENTO Antes de definir a estrutura geral do banco de dados, preciso primeiro fazer o Modelo Entidade Relacionamento, o MER, pois a partir dele que iro ser identificados como o banco de dados ir ser organizado, a propriedade de cada dado, quais colunas tero vnculos, as chaves primrias, as chaves estrangeiras, o relacionamento entre as tabelas, etc. Muitas pessoas confundem as classes com tabelas de banco de dados, mas no so, pois as classes so modelos de objetos para o desenvolvimento do software, e a tabela de banco de dados so repositrios de dados que podem ser usados de qualquer classe ou qualquer parte do sistema. Medeiros (2004, p. 182) sugere alguns passos para desenvolver o MER. A primeira identificar as entidades no banco de dados. Depois um dicionrio de entidades. Em terceiro um registro de entidades. Em seguida o dicionrio de dados e o relacionamento entre entidades. Ento dever ser feita uma normalizao para ento, por fim, realizar o relacionamento do MER. Banco de dados possui toda uma extenso e vrias teorias que precisam de amplas explicaes, mas no o objetivo deste trabalho e nem da UML explicar essas teorias, e sim us-las de maneira correta para a elaborao do software.

29

1.4. CONSIDERAES FINAIS A UML trs vrios modelos de documentao que proporcionam um amplo escopo de definies e fcil comunicao entre as partes de um projeto para o desenvolvimento de software. A engenharia de software define o caminho para a construo de software, utilizandose das experincias e comparaes com outras engenharias e formando um prprio conceito, trazendo os passos necessrios para se alcanar a qualidade de software. O uso dos ciclos de vida ir determinar a qualidade final esperada e quais tipos de documentaes sero necessrios para que possa chegar um produto final que atenda todos os requisitos iniciais. A combinao entre a Prototipao, o documento Viso, os diagramas de Caso de Uso e Classes, e o MER para o banco de dados, foi a proposta utilizada para o desenvolvimento deste software, atendendo aos requisitos e aderindo qualidade ao produto final.

30

2. DESENVOLVIMENTO DA APLICAO. O objetivo deste captulo apresentar um breve histrico do ramo de negcio da empresa e tambm todos os documentos e diagramas elaborados, baseados nas especificaes da UML e na prototipao de sistemas. Tambm apresenta algumas interfaces da aplicao desenvolvida.

2.1. DESCRIO BREVE DO RAMO DE NEGCIO DA EMPRESA. A empresa de mdio porte, onde apenas os vendedores sero os usurios mais freqentes do sistema e os repositores de estoque sero a outra parte de usurios do sistema. A empresa concentra-se principalmente na venda de alimentos. A empresa vende todos os tipos de alimentos: enlatados, ensacados, frescos, bebidas, frios e quentes. Tambm com pequenas vendas de utenslios para o dia a dia, a empresa procura sempre vender produtos de consumo, mesmo no sendo alimentos, produtos que sero consumidos ao longo do tempo e de pequena a mdia durao. Por isso existe uma grande quantidade de produtos sendo vendidos a todo momento em todos os caixas do mercado. Para agilizar o tempo, cada caixa ter o sistema implantado de forma a calcular a quantidade de cada produto e seu preo automaticamente para que o cliente da empresa fique menos tempo possvel no caixa. A empresa tambm ter grandes estoques de produtos chegando todos os dias, os repositores so responsveis por contar a quantidade do produto, verificar e ento dar entrada no sistema com a quantidade, nome e descrio do produto. A distribuio dos produtos nas prateleiras fica a cargo da prpria empresa.

2.2. AS PESSOAS ENVOLVIDAS (USURIOS). Os usurios do sistema so de dois tipos: 1) Os caixas: vendedores que devero passar cada produto e sua quantidade no ato da venda, estes sero os usurios que apenas iro retirar quantidades de produtos do sistema. 2) Os repositores: estes iro receber as remessas de produtos, fazer a contagem e dar entrada no sistema, alimentando-o com novos produtos e quantidades ou apenas a aumentando a quantidade de produtos j registrados. 3) Os administradores: estes controlam os logins e senhas de todos os usurios, alm de serem responsveis pelas devolues dos produtos e controle de acesso ao sistema. O primeiro usurio precisa sempre saber o cdigo de cada produto (seu cdigo de identificao), em casos de erro em cdigo de barras ou produtos mal registrados. O segundo

31

usurio simplesmente adiciona de acordo com o cdigo de barras, caso o produto no tenha um comparativo ou cadastro, o sistema gerar um cdigo automaticamente. Apenas o segundo usurio poder adicionar um preo ao produto, sempre unidades simples, como 1 item ou 1kg, 1 pacote, 1 caixa, etc.

2.3. TECNOLOGIAS UTILIZADAS. Para desenvolver e implantar o sistema sero necessrias algumas tecnologias j existentes. Sero estas o tipo de linguagem de programao que ser usado, o servidor de dados, onde os todos os dados sero guardados e o tipo de banco de dados que ser utilizado para modelar e organizar os dados.

2.3.1. LINGUAGEM DE PROGRAMAO. A linguagem de programao escolhida para desenvolver este sistema foi o REALbasic. Baseado na linguagem basic e um melhoramento do Visual Basic, o REALbasic uma plataforma de desenvolvimento Orientada a Objeto em que podem ser aplicadas os modelos UML para anlise de sistema e tambm a Prototipao, pois uma plataforma que pode mostrar prottipos com poucas linhas de programao. uma plataforma de desenvolvimento rpida, porm com muitas funcionalidades e totalmente multi-plataforma, ou seja, pode rodar em quaisquer dos trs grandes sistemas operacionais, Windows, MAC ou Linux. Alm de ser a plataforma de desenvolvimento que o autor deste trabalho est habituado a desenvolver seus programas.

2.3.2. SERVIDOR E BANCO DE DADOS. O SGBD (sistema gerenciador de Banco de Dados) utilizado neste trabalho foi o MySQL. O servidor pode ser qualquer da escolha do cliente, e o servidor utilizado pela empresa foi o Windows Server 98. A porta aberta para comunicao, por padro, foi a 3306. O MySQL um SGBD livre, e aconselhado que se use algum servidor baseado em Linux para que o custo do sistema seja baixo, entretanto, isto no obrigatrio. A escolha pelo MySQL foi por ser um SGBD muito conhecido, que atende todas as necessidades de insero e recuperao de dados de modo simples e prtico, alm de gratuito.

32

2.4. UML. A seguir so apresentados os documentos e diagramas elaborados segundo a UML.

2.4.1. DOCUMENTO VISO. O documento viso, como foi descrito anteriormente, deve dar uma perspectiva do que o software deve fazer, um contrato inicial das coisas que o cliente precisa que sejam feitas pelo software e do que o desenvolvedor vai fazer para que o mesmo atenda s necessidades do cliente.

Software: SISTEMA PARA VENDAS EM CAIXA. Requisitante: Mercado de Venda de Produtos Variados. Principais contatos: Contato 1 e-mail fone; Descrio:

Data: 26 de outubro de 2010.

Contato 2 e-mail fone.

O software tem por objetivo agilizar a venda de produtos no caixa de vendas da empresa, automatizando a quantidade, nome, preo e valor total das compras. O sistema tambm dever aceitar o cadastro de novos produtos, as quantidades cadastradas e sua marca, juntamente com a descrio do produto e da marca. Toda vez que um usurio for usar o sistema, este dever fazer o login para utiliz-lo. Cada marca dever ser cadastrada e dever ter um nome e descrio. A cada venda, o software ir gerar um cupom fiscal de acordo com os padres estabelecidos com todas as mercadorias e informaes da venda, juntamente com o valor total, o valor pago e o troco. Cada venda acarretar em diminuio no estoque das mercadorias. Cada venda dever ter um cdigo que ser mantido no histrico do banco de dados, constando uma lista com os cdigos dos produtos vendidos e quantidade, alm da data e hora, nome do balconista e nmero do caixa em que ocorreu a venda. Qualquer devoluo s poder ser feita durante o ato de venda, aps o pagamento no ser possvel estornar ou apagar qualquer transao. Somente os administradores devero fazer estorno durante o ato de venda e isto no ser descrito no cupom fiscal.

________________________ (assinatura do cliente)

____________________________ (assinatura do desenvolvedor)

33

2.4.2. DIAGRAMA DE CASO DE USO. O diagrama de Caso de Uso - Nvel 0 foi elaborado aps o documento viso. Diferente do desenvolvimento de outros diagramas, o diagrama nvel 0 foi desenvolvido antes dos primeiros testes. J os diagramas nvel 1 e nvel 2 foram feitos aps alguns testes. Ficou estabelecido que o sistema tambm um ator, pois o mesmo realiza funes automaticamente a partir de certos pontos de deciso. Apesar deste ator (sistema) no atuar sozinho, depender de eventos externos e tambm de no ser disparador de eventos, mas ele quem estabelece caractersticas de padronizao aplicao. Ento como o sistema quem estabelece os padres e toma algumas decises, ficou estabelecido que ele ator de algumas funes.

Figura 7 - Diagrama de Caso de Uso nvel 0

A Figura 7 apresenta o Diagrama de Caso de Uso nvel 0. Todo usurio antes de executar alguma ao no sistema dever passar pela Gerencia de Login, que depende da Autenticao do Sistema.

34

O Caixa ir efetuar a venda e, aps finaliz-la, o Sistema ir Gerar o Cupom Fiscal. O Gerente de Estoque ir acessar apenas a rea de Controle de Estoque. O Administrador ir Gerenciar as Devolues de produtos.

Figura 8 Diagrama de Caso de uso nvel 1 Venda.

A Figura 8 apresenta o Diagrama de Caso de uso nvel 1 - Venda. O Caixa, quando efetua a venda, registra a sada dos produtos (o Sistema verifica a existncia do cadastro de cada produto). Aps a finalizao da venda, o sistema gera e imprime o Cupom Fiscal. A Figura 9 abaixo apresenta o Diagrama de Caso de uso nvel 1 - Login. Toda vez que o Gerente de estoque, o Caixa e o Administrador forem entrar no sistema, estes devero inserir seus logins e senhas. O Sistema ento verificar a permisso de acesso.

Figura 9 Diagrama de Caso de uso nvel 1 Login.

35

2.4.3. DIAGRAMA DE CLASSES

Figura 10 Diagrama de Classes.

A Figura 10 mostra o Diagrama de Classes. Aps algumas visitas ao cliente este diagrama foi aperfeioado e representa a organizao do sistema no desenvolvimento do primeiro prottipo. Na Figura 10, a classe Pessoa tem trs subclasses que herdam seus atributos: Administrador, o Gerente de Estoque e o Caixa. O Gerente de Estoque pode adicionar vrios produtos e um produto pode ser adicionado por vrios Gerentes de Estoque. Cada produto s tem uma marca, mas uma marca pode estar em vrios produtos. O Caixa pode fazer vrias vendas, e cada venda s tem um caixa. Cada venda possui vrios produtos e um produto pode aparecer em vrias vendas. A classe do sistema cuida da Gerencia de Logins e o Administrador faz o cadastro dos usurios. 2.4.4. O MER MODELO ENTIDADE RELACIONAMENTO. O MER servir para que se possa limpar, zerar e formatar o banco de dados de forma que os dados de testes sumam e no haja perigo de se perder campos ou tabelas, ou informaes importantes quanto s configuraes de base.

36

Figura 11 Diagrama do MER.

Na Figura 11 tem-se o MER (Modelo Entidade Relacionamento). Um funcionrio pode realizar vrias vendas. Cada venda contm vrios itens (venda de produtos). Cada item (venda de produtos) est relacionado a um produto. No processo de entrada de produtos, tem-se uma lgica parecida com a venda. Um funcionrio pode dar entrada de vrios produtos (tabela entrada produtos). Um produto pode ser introduzido por diferentes funcionrios.

2.3.5. INTERFACES DO SISTEMA. Na figura 12 a seguir tem-se o prottipo da tela de login, onde o usurio ir digitar um login, previamente cadastrado pelo administrador, e uma senha tambm j cadastrada. O Sistema comear sempre com esta janela e sempre sair com esta janela.

37

Figura 12 - Tela de Login.

Figura 13 - Tela de Vendas do Caixa.

A janela de vendas (Figura 13) possui um campo para a insero do cdigo que pode ser manual ou automtica com algum leitor de cdigo de barras. O campo de quantidade pode ser alterado assim que pressionado a tecla F1 do teclado. Para finalizar a compra o caixa dever apertar a tela F4 e ento o campo de recebimento ficar em evidncia, para que seja digitado o valor pago, ento o usurio apertar o Enter e ser impresso o Cupom fiscal e ser finalizada a venda. Na parte esquerda da janela (em branco) tem-se o relatrio atual das vendas. Sempre que um produto for adicionado ou inserido pelo leitor de cdigo de barras, este ser adicionado lista. A lista contm a ordem do item, seu nome com a marca, a quantidade,

38

preo por unidade e total. No final da venda esta lista ir mostrar o valor total da compra, o valor pago e o troco. O troco tambm ficar evidente abaixo do campo do valor pago. A partir desta janela, pressionando-se a tecla F5, obtm-se a janela de busca de produtos.

Figura 14 - Tela de Buscas de Produtos e Cdigos.

Esta janela, ilustrada na Figura 14, permite buscar todos os produtos do sistema, mostrando a sua quantidade no estoque, seu nome e o cdigo, e no campo superior poder ser digitado o nome ou o cdigo do produto para busca. A cada dgito pressionado, a lista de busca atualizada mostrando apenas os produtos que tem algum relacionamento com a parte escrita no campo. Ao finalizar a busca basta apertar Tab e ento selecionar o produto, pressionando Enter o cdigo retornado para a janela de venda e ento adicionado a lista de vendas.

39

Figura 15 - Tela inicial do Administrador.

Esta a janela do Administrador (Figura 15). Aps efetuar o login, o Administrador ter listado todos os usurios do sistema e o tipo de usurio. Dela, ele poder procurar algum usurio, digitando algo no campo superior e ento pressionando o boto Buscar. Para editar algum usurio este poder selecionar na lista e ento pressionar o boto Editar. E para adicionar um novo basta pressionar o boto Adicionar.

Figura 16 - Tela de cadastro e edio dos usurios.

40

A Figura 16 ilustra a janela para adicionar um novo usurio, onde devero ser preenchidos o nome completo do usurio, um login nico, uma senha de conhecimento apenas do prprio usurio. Logo abaixo deve ser confirmada a senha, para que seja verificado se o usurio digitou aquilo que queria. Em seguida o Administrador dever selecionar o tipo de usurio, se ser um Caixa, um Administrador ou um Controlador de estoque. Aps preencher todos os campos basta pressionar o boto Salvar para salvar o contedo e criar um novo usurio ou pressionar Cancelar para cancelar a operao e voltar a tela inicial do Administrador. Esta tela tambm serve para editar o login, senha ou tipo do usurio, entretanto quando esta tela aparecer para edio o campo de nome e login viro automaticamente preenchidos, assim como o tipo. O campo senha dever ser escrito novamente caso deseje salvar as modificaes, e tambm possvel alterar o tipo do usurio, modificando o campo Tipo.

Figura 17 - Tela de edio de preo e quantidade dos Produtos.

A janela de edio de produtos ilustrada na Figura 17. Aps o Controlador de estoque fazer seu login, esta sua janela principal. Nela tm-se os campos inalterveis dos produtos: Nome, Cdigo e Quantidade atual. Em seguida tem-se o Preo e Quantidade que se deseja adicionar. Para editar o Preo e Quantidade de um produto, basta selecion-lo no primeiro campo Produto, onde estaro relacionados todos os produtos cadastrados no sistema. Aps a seleo o preo poder ser alterado no campo Preo e quantidade adicionada no campo

41

Quantidade, depois pressionar o boto Atualizar para apenas atualizar ou OK para salvar a modificao e ento fechar a janela. Caso queria adicionar um novo produto basta pressionar o boto Novo e a janela de cadastro de um novo produto aparecer.

Figura 18 - Tela de cadastro de novos Produtos.

A janela de cadastro de um novo produto apresentada na Figura 18. Todo produto deve ter uma marca. Devero ser preenchidos os campos Nome do produto, Descrio, Cdigo (cdigo de barras), o Preo e Quantidade. Para apenas adicionar um novo produto basta pressionar o boto Adicionar, seno, poder salvar e sair ao pressionar o boto OK. Caso a marca tambm no esteja cadastrada basta pressionar o boto Nova que a janela de marcas aparecer para cadastro.

Figura 19 - Tela de cadastro de novas Marcas.

42

A janela de marcas tem uma lista contendo o nome de todas as marcas j cadastradas (Figura 19). Para adicionar uma nova marca basta escrever o nome da marca no campo superior e ento pressionar o boto Adicionar, aps adicionar a nova marca ela aparecer na lista e ento para sair basta pressionar o boto OK.

Figura 20 - Janela de Estorno de Produtos

Na figura 20 tem-se a janela de devolues (estorno). Quando o Caixa deseja devolver algum produto, este dever selecionar o produto na lista de venda e pressionar a tecla F6 durante a venda. Na janela tem-se o nome do produto selecionado, a quantidade de devoluo e por fim o Administrador dever entrar com login e senha para que seja autorizado o estorno do produto.

Figura 21 - Modelo do Cupom Fiscal

43

A Figura 21 ilustra o Cupom Fiscal gerado pelo Sistema. Nele tem-se os dados iniciais do Mercado de Vendas e o endereo. Depois tem-se o nmero da emisso e a venda realizada. Os dados da venda so: ordem do produto, o cdigo no sistema, a descrio contendo o nome e marca, a quantidade vendida, o valor unitrio e o total por produto. No final tem-se o valor total da venda, o valor pago e o troco dado ao comprador.

2.5. STATUS DO SISTEMA E FUNCIONALIDADES. O sistema encontra-se pronto para a implementao, ou seja, ele j pode entrar em fase de testes e funcionamento para que o cliente possa model-lo de acordo com as suas necessidades prticas. Mesmo o cliente e o engenheiro tendo negociado vrias vezes as funcionalidades, as especificaes e testes singulares, s depois de implementado que o sistema pode ser realmente testado e analisado. Esta a primeira verso de testes, chamada geralmente de verso Beta entre os profissionais de T.I. (Tecnologia da Informao), e o produto agora est aberto para todos os tipos de testes prticos. Cada usurio (caixa/estoquista/ administrador) d um feedback (retorno) contendo opinies, erros, melhorias e dificuldades encontradas num perodo estipulado pela equipe de desenvolvimento. Este sistema atualmente j conta com o cadastro dos produtos e informaes bsicas, como preo, nome e quantidade. As marcas so cadastradas normalmente. Cada usurio j pode testar a sua rea cadastrada. O Administrador pode cadastrar novos usurios e especificar suas funcionalidades. A venda j est funcionando, buscando e listando os produtos, fazendo os clculos de venda, pagamento e troco, e no final emitindo um Cupom Fiscal padronizado. As funcionalidades implementadas so bsicas, como clculo de venda, busca dos cdigos e nomes no banco de dados, como verificao de login e senha. Para fins de estudo, o sistema foi desenvolvido conforme planejado, seguindo o ciclo de vida da Prototipao. Sua documentao bsica e necessria est toda de acordo com os padres para que se possa dar continuao ao sistema. Como este um trabalho de durao estipulada, o projeto se encerra aqui, mas mesmo assim com o objetivo de testes e demonstrao cumpridos.

2.6. DIFICULDADES ENCONTRADAS. Durante o desenvolvimento do sistema a grande dificuldade foi entender como o cliente desejava algumas partes do mesmo e como atender dentro do tempo estipulado. Os

44

erros e incompatibilidades estavam dentro do esperado, mas o tempo pr-definido para a concluso do projeto foi o agravante. Durante a elaborao da documentao UML surgiram algumas dvidas, que foram sanadas no decorrer do tempo aps algumas trocas de experincia com colegas e professores. O MER apresenta a modelagem do banco de dados, segundo Medeiros (p. 186).

2.7. CONSIDERAES FINAIS. Como este foi um trabalho com tempo delimitado e curto, a continuidade do mesmo pode ser repassada para um prximo candidato interessado sobre o tema. A documentao bsica est documentada e, alm disso, um primeiro prottipo foi implementado na linguagem REALBasic. O trabalho com Prototipao foi muito prtico e os diagramas UML escolhidos foram muito teis e serviram como base de estudos futuros.

45

3. CONCLUSO E TRABALHOS FUTUROS. O propsito deste projeto foi acompanhar o trabalho de um desenvolvedor no seu cotidiano. Como autor deste trabalho, e empregado numa empresa que desenvolve aplicaes (software) para terceiros, foi de grande valia para o aprendizado profissional. A escolha da Prototipao para o desenvolvimento deste trabalho foi devido a sua flexibilidade e praticidade. A prototipao um modelo de desenvolvimento muito usado no mercado e bastante eficiente para pequenas aplicaes. A Prototipao no antecipa o desenvolvimento e a implementao do software, mas sim ajuda a demonstrar ao cliente o andamento do seu produto e do seu investimento. Tambm ajuda o desenvolvedor a entender as reais necessidades do cliente e o que o sistema dever resolver dentro do ambiente que est inserido. Dentro do ciclo de vida de um Software, foram utilizados apenas a idealizao, criao e implementao. Faltaram as seguintes etapas: os testes, depois a implantao no qual o Prottipo passa a ser um produto mais completo e finalmente entra no ciclo de correo e manuteno. Os trabalhos com os diagramas UML deram os resultados esperados, especificando de forma clara e simples as funes e propriedades bsicas do sistema. Dentro da Engenharia de Software, escolher um ciclo de vida no apenas afeta em como o sistema dever ser desenvolvido, mas tambm afeta nos resultados esperados. s vezes o tempo o fator determinante, outras vezes so os recursos aplicados no desenvolvimento. A implantao deste sistema tambm poderia ser objeto de estudo futuro, para observar se a prtica da Prototipao se encaixa neste tipo de aplicao. Estudos de relacionamento entre o cliente e o desenvolvedor tambm pode ser estudado, pois ainda existe uma grande barreira entre o mundo de T.I. e os negcios. Facilitar o entendimento, as relaes, negociaes e conversas entre os profissionais da rea de tecnologia e os leigos so importantes para o trabalho de desenvolvimento, no somente na rea de engenharia de software, mas tambm de comunicaes de dados e armazenamento. Os diagramas UML padronizaram vrias partes dessa comunicao e facilitam muito na hora de conversar e exemplificar para o cliente.

46

4. REFERNCIAS BIBLIOGRFICAS

CUNHA, Fulvio Alexandre da Cunha. Prototipao De Software. Publicado em 27/06/2007. Disponvel em: http://www.webartigos.com/articles/1896/1/Prototipacao-De-

Software/pagina1.html. Acessado em: 29/09/2010. GUEDES, Gilleanes T.A. UML Uma Abordagem Prtica 2 edio. Editora novatec. Web site: www.novateceditora.com.br. Ano: 2004. LARMAN, Craig. Utilizando UML e Padres Uma introduo anlise e ao projeto orientados a objetos e ao Processo Unificado. Editora Bookman, 2 edio. Web site: www.bookman.com.br. Ano: 2004.

MEDEIROS, Ernani. Desenvolvendo Software com UML 2.0 Definitivo. Editora PEARSON Makron Books. Web site: www.pearson.com.br. Ano: 2004. PENDER, Tom.UML a Bblia. Editora WILEY. Traduzido pelas editoras CAMPUS, ELSEVIER. Web site: www.wiley.com/compbooks/pender. Ano: 2004.

PRESSMAN, Roger S. Engenharia de Software. Editora MAKRON Books. 1 Edio. Ano: 1995.

REZENDE, Denis Alcides. Engenharia de Software e Sistema de Informao. Editora BRADSPORT, 3 edio. Web site: www.bradsport.com.br. Ano: 2005.