TCC - Monografia Engenharia de Software - Iuri

8/3/2019 TCC - Monografia Engenharia de Software - Iuri

1/48

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


2/48

FUNDAO UNIVERSIDADE FEDERAL DE RONDNIA

NCLEO DE CINCIA E TECNOLOGIA

DEPARTAMENTO DE INFORMTICA




ORIENTADORA:MS LILIANE DA SILVA COELHO JACON

MONOGRAFIA SUBMETIDA FUNDAO UNIVERSIDADE FEDERAL DE RONDNIA

COMO REQUISITO PARCIAL OBTENO DO TTULO DELICENCIATURA/BACHAREL EM INFORMTICA.

Porto Velho

2010


3/48

1




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

EMINFORMTICA.

APROVADA POR:

______________________________

Prof, Msc. Liliane da Silva Coelho Jacon

______________________________

Prof. Msc. Marcello Batista Ribeiro

______________________________Prof, Msc. Carolina Veludo Watanabe

Porto Velho

2010


4/48

2

Dedicatria

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


5/48

3

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.


6/48

4

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


7/48

5

RESUMO

Este trabalho apresenta o desenvolvimento de um software para atender snecessidades de um mercado de vendas de produtos variados. O estudo do desenvolvimentovisa entender as facilidades de se trabalhar com a Prototipao, que um dos ciclos de vida daEngenharia de Software, e algumas documentaes da UML 2.0. Neste trabalhoprimeiramente vemos as definies de Engenharia de Software explicando os ciclos de vidas eposteriormente 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.


8/48

6

ABSTRACT

This work presents the development of software to meet the needs of a market forsales of various products. The study aims to understand the development of facilities to workwith prototyping, which is a life-cycle of software engineering, and some documentation fromUML 2.0. In this work we see the definitions of Software Engineering explaining the cyclesof 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.


9/48

7

LISTA DE FIGURAS

Figura 1 - Desenvolvimento em Queda d'gua. ...................................................................... 15Figura 2 - O ciclo de vida clssico. .......................................................................................... 20Figura 3 - Prototipao. ............................................................................................................ 20Figura 4 - O modelo espiral. ..................................................................................................... 21Figura 5 - Tcnicas de quarta gerao. ..................................................................................... 22Figura 6 - A natureza mutante do desenvolvimento de software. ............................................ 23Figura 7 - Diagrama de Caso de Uso nvel 0 ............................................................................ 33Figura 8Diagrama de Caso de uso nvel 1Venda. ............................................................ 34Figura 9Diagrama de Caso de uso nvel 1Login. ............................................................. 34

Figura 10Diagrama de Classes. ............................................................................................ 35Figura 11Diagrama do MER. ............................................................................................... 36Figura 12 - Tela de Login. ........................................................................................................ 37Figura 13 - Tela de Vendas do Caixa. ...................................................................................... 37Figura 14 - Tela de Buscas de Produtos e Cdigos. ................................................................. 38Figura 15 - Tela inicial do Administrador. ............................................................................... 39Figura 16 - Tela de cadastro e edio dos usurios. ................................................................. 39Figura 17 - Tela de edio de preo e quantidade dos Produtos. ............................................. 40Figura 18 - Tela de cadastro de novos Produtos. ...................................................................... 41Figura 19 - Tela de cadastro de novas Marcas. ........................................................................ 41Figura 20 - Janela de Estorno de Produtos ............................................................................... 42Figura 21 - Modelo do Cupom Fiscal ....................................................................................... 42
http://../Desktop/Projeto%20II/Monografia-Iuri%20-%20RC.doc#_Toc279410243http://../Desktop/Projeto%20II/Monografia-Iuri%20-%20RC.doc#_Toc279410243http://../Desktop/Projeto%20II/Monografia-Iuri%20-%20RC.doc#_Toc279410243


10/48

8

LISTA DE ABREVIATURAS E SIGLAS

UMLUnified Modeling Language.

MERModelo Entidade Relacionamento.

BDBanco de dados.

RADDesenvolvimento Rpido de Aplicaes.


11/48

9

SUMRIO

INTRODUO ...................................................................................................................... 101. ENGENHARIA DE SOFTWARE E UML ...................................................................... 13

1.1. Engenharia de Software: uma viso geral. ............................................................ 131.2. Ciclo de vida de um Software ................................................................................ 19

1.2.1. Os vrios tipos de ciclos de vida. .................................................................... 191.2.2. Prototipao .................................................................................................... 23

1.3. UML e seus diagramas .......................................................................................... 251.3.1. Documento Viso ........................................................................................... 261.3.2. Diagrama de Caso de Uso ............................................................................... 271.3.3. Diagrama de Classes ....................................................................................... 271.3.4. Banco de dados - MER Modelo Entidade Relacionamento ........................... 28

1.4. Consideraes Finais ............................................................................................. 292. DESENVOLVIMENTO DA APLICAO. .................................................................... 30

2.1. Descrio breve do ramo de negcio da empresa. ................................................. 302.2. As pessoas envolvidas (usurios). ......................................................................... 302.3. Tecnologias utilizadas. .......................................................................................... 31

2.3.1. Linguagem de programao. .......................................................................... 312.3.2. Servidor e banco de dados. ............................................................................. 31

2.4. UML. ..................................................................................................................... 322.4.1. Documento Viso. .......................................................................................... 322.4.2. Diagrama de Caso de Uso. .............................................................................. 332.4.3. Diagrama de Classes ....................................................................................... 352.4.4. O MERModelo Entidade Relacionamento. ................................................ 352.3.5. Interfaces do Sistema. ..................................................................................... 36

2.5. Status do sistema e funcionalidades. ..................................................................... 432.6. Dificuldades encontradas. ...................................................................................... 432.7. Consideraes finais. ............................................................................................. 44

3. CONCLUSO E TRABALHOS FUTUROS. .................................................................. 45

4. REFERNCIAS BIBLIOGRFICAS ............................................................................. 46


12/48

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 irabrir, apenas sabe que tem algum banheiro em algum lugar, quartos, sala e cozinha.


13/48

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.

JustificativaA 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 empresarequisitante 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


14/48

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.


15/48

13

1.ENGENHARIADESOFTWAREEUML

Engenharia de software uma rea do conhecimento da computao voltada para a

especificao, desenvolvimento e manuteno de sistemas de software aplicando tecnologiase 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

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


16/48

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 asdiferenas 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 inciopelo 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 aconstruo 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


17/48

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

se alguma comemorao, simplesmente escuta-se no era isso que eu queria realmente, ou

est muito bom, mas poderia mudar isso e isso...

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.

Tempo

Risco

Requerimentos

Anlise e Design

Implementao

Testes

Implantao

Risco

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


18/48

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 umrascunho 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 estudoser 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 queerrado.

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


19/48

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 aempresa 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 procurao qudeve ser feito. Assim, o analista deveria definir ascaractersticas 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 ocomo. 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


20/48

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 emmudanas que ocorrero ao longoda 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 iridentificar 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 certosmeios, 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


21/48

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


22/48

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:


23/48

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 onmero 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:


24/48

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 astcnicas 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 maisser 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)


25/48

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


26/48

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


27/48

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; Diagramacombinado 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 dedocumentar. Dentro da apresentao deste trabalho especificadamente sero utilizados apenas


28/48

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 Stakeholdere 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 SistemaModelo Conceitual.

Aps a elaborao do documento Viso, ento ser elaborado o diagrama de Caso deUso.


29/48

27

1.3.2.DIAGRAMA DE CASO DE USO

Considerado um diagrama comportamental por Pender (2004, p. 47), este diagramamodela 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


30/48

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


31/48

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, utilizando-

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


32/48

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


33/48

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


34/48

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. Data: 26 de outubro de 2010.

Requisitante: Mercado de Venda de Produtos Variados.Principais contatos:

Contato 1e-mailfone; Contato 2e-mailfone.

Descrio:

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, constandouma 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)


35/48

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.


36/48

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 9Diagrama de Caso de uso nvel 1 Login.


37/48

35

2.4.3.DIAGRAMA DE CLASSES

Figura 10Diagrama 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 deLogins e o Administrador faz o cadastro dos usurios.

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


38/48

36

Figura 11Diagrama 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.


39/48

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,


40/48

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.


41/48

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.


42/48

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 asmodificaes, 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


43/48

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.


44/48

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


45/48

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


46/48

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.


47/48

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


48/48

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. UMLUma 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.
http://www.novateceditora.com.br/http://www.novateceditora.com.br/http://www.novateceditora.com.br/http://www.bookman.com.br/http://www.bookman.com.br/http://www.pearson.com.br/http://www.pearson.com.br/http://www.pearson.com.br/http://www.wiley.com/compbooks/penderhttp://www.wiley.com/compbooks/penderhttp://www.wiley.com/compbooks/penderhttp://www.bradsport.com.br/http://www.bradsport.com.br/http://www.bradsport.com.br/http://www.bradsport.com.br/http://www.wiley.com/compbooks/penderhttp://www.pearson.com.br/http://www.bookman.com.br/http://www.novateceditora.com.br/

Documents

TCC - Monografia Engenharia de Software - Iuri