FUNDAÇÃO UNIVERSIDADE FEDERAL DE RONDÔNIA NÚCLEO DE CIÊNCIA E TECNOLOGIA DEPARTAMENTO DE INFORMÁTICA

IURI MANDELA SIMÃO BATISTA

PROTOTIPAÇÃO DE SOFTWARE: UM ESTUDO DE CASO PARA UM MERCADO DE VENDA
DE PRODUTOS VARIADOS.

Porto Velho 2010

FUNDAÇÃO UNIVERSIDADE FEDERAL DE RONDÔNIA NÚCLEO DE CIÊNCIA E TECNOLOGIA DEPARTAMENTO DE INFORMÁTICA

PROTOTIPAÇÃO DE SOFTWARE: UM ESTUDO DE CASO PARA UM MERCADO DE VENDA
DE PRODUTOS VARIADOS.

IURI MANDELA SIMÃO BATISTA

ORIENTADORA: MS LILIANE DA SILVA COELHO JACON

MONOGRAFIA SUBMETIDA À FUNDAÇÃO UNIVERSIDADE FEDERAL DE RONDÔNIA
COMO REQUISITO PARCIAL À OBTENÇÃO DO TÍTULO DE

LICENCIATURA/BACHAREL EM INFORMÁTICA.

Porto Velho 2010

1

IURI MANDELA SIMÃO BATISTA

PROTOTIPAÇÃO 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 INFORMÁTICA DA FUNDAÇÃO UNIVERSIDADE FEDERAL DE RONDÔNIA COMO PARTE DOS REQUISITOS NECESSÁRIOS PARA OBETENÇÃO DO GRAU DE LICENCIATURA/BACHAREL EM INFORMÁTICA.

APROVADA POR:

______________________________ Profª, Msc. Liliane da Silva Coelho Jacon

______________________________ Prof. Msc. Marcello Batista Ribeiro

______________________________ Profª, Msc. Carolina Veludo Watanabe

Porto Velho 2010

2

Dedicatória Ao meu pai que me confia a fazer aquilo que gosto e que a felicidade e satisfação em fazer o que é prazeroso é o que nos torna mais completos.

3

Agradecimentos Aos meus amigos que me suportam todos os dias, à minha namorada que me apóia e me empurra aos estudos todos os dias. À minha mãe que gosta de estudar e acredita da vida acadêmica.

4

“Dez mil dificuldades não constituem uma dúvida.” (Isaac Newton)

5

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 Prototipação, que é um dos ciclos de vida da Engenharia de Software, e algumas documentações da UML 2.0. Neste trabalho primeiramente vemos as definições de Engenharia de Software explicando os ciclos de vidas e posteriormente as documentações escolhidas para o desenvolvimento do Sistema. Ao final é apresentado o estado do Sistema e a conclusão sobre desenvolvimento desta aplicação.

Palavras-Chave: Prototipação. UML. Engenharia de Software. Sistema. Cliente.

6

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.

7

LISTA DE FIGURAS

Figura 1 - Desenvolvimento em Queda d'Água. ...................................................................... 15 Figura 2 - O ciclo de vida clássico. .......................................................................................... 20 Figura 3 - Prototipação. ............................................................................................................ 20 Figura 4 - O modelo espiral. ..................................................................................................... 21 Figura 5 - Técnicas de quarta geração. ..................................................................................... 22 Figura 6 - A natureza mutante do desenvolvimento de software. ............................................ 23 Figura 7 - Diagrama de Caso de Uso nível 0 ............................................................................ 33 Figura 8 – Diagrama de Caso de uso nível 1 – Venda. ............................................................ 34 Figura 9 – Diagrama de Caso de uso nível 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 Códigos. ................................................................. 38 Figura 15 - Tela inicial do Administrador. ............................................................................... 39 Figura 16 - Tela de cadastro e edição dos usuários. ................................................................. 39 Figura 17 - Tela de edição de preço 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

8

LISTA DE ABREVIATURAS E SIGLAS UML – Unified Modeling Language. MER – Modelo Entidade Relacionamento. BD – Banco de dados. RAD – Desenvolvimento Rápido de Aplicações.

9

SUMÁRIO

INTRODUÇÃO ...................................................................................................................... 10 1. ENGENHARIA DE SOFTWARE E UML ...................................................................... 13 1.1. Engenharia de Software: uma visão geral. ............................................................ 13 1.2. Ciclo de vida de um Software ................................................................................ 19 1.2.1. Os vários tipos de ciclos de vida. .................................................................... 19 1.2.2. Prototipação .................................................................................................... 23 1.3. UML e seus diagramas .......................................................................................... 25 1.3.1. Documento Visão ........................................................................................... 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. Considerações Finais ............................................................................................. 29 2. DESENVOLVIMENTO DA APLICAÇÃO..................................................................... 30 2.1. Descrição breve do ramo de negócio da empresa. ................................................. 30 2.2. As pessoas envolvidas (usuários). ......................................................................... 30 2.3. Tecnologias utilizadas. .......................................................................................... 31 2.3.1. Linguagem de programação. .......................................................................... 31 2.3.2. Servidor e banco de dados. ............................................................................. 31 2.4. UML. ..................................................................................................................... 32 2.4.1. Documento Visão. .......................................................................................... 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. Considerações finais. ............................................................................................. 44 3. CONCLUSÃO E TRABALHOS FUTUROS. .................................................................. 45 4. REFERÊNCIAS BIBLIOGRÁFICAS ............................................................................. 46

10

INTRODUÇÃO O desenvolvimento de um software exige vários planejamentos, análises e o uso de técnicas de programação. Dependendo da complexidade, um software pode levar mais de um ano para que o mesmo seja desenvolvido. Entretanto, na maioria das vezes, os softwares não são criados com o objetivo simples de suprir uma necessidade de mercado ou acrescentar uma nova tecnologia, a maioria dos softwares são para pequenas e médias empresas, onde há necessidade de armazenamento de dados específicos e pequenas funcionalidades que devem ser automatizadas para agilizar na tomada de decisões. Às vezes, uma empresa de médio porte pode não esperar por um trimestre, ou até por um bimestre para que um software apresente algum retorno de seu investimento. O empresário 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, diagramação e tabelas, modelagem do banco de dados e estudo adequado de como o sistema irá funcionar na empresa. Após a criação dos diagramas e modelos mais básicos, o sistema começa a ser codificado (em qualquer que seja a linguagem), seguindo os passos anteriormente estabelecidos. Entretanto todo sistema é susceptível à falhas e por isso, a primeira vez que o usuário usar o programa, é provável que este encontre dificuldades. Isto acarretará em falhas e situações ainda não 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 usuário leigo é um primeiro visitante, este não 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 não funcionais, ou seja, são de difícil acesso, coisas de pouco uso ficam muito aparentes, dados inúteis podem estar sendo repetidos desnecessariamente. Com o objetivo de minimizar este tipo de dificuldade, tem-se na engenharia de software um tipo de desenvolvimento específico chamado „Prototipação‟, que busca encontrar uma solução aceitável para este tipo de problema. A prototipação utiliza-se da habilidade do desenvolvedor de software para apresentar de maneira rápida um protótipo para o usuário, que servirá como base para norteamento das próximas implementações.

Justificativa A razão para o desenvolvimento deste projeto é que o mercado de trabalho traz como desafio atendimento rápido das necessidades do cliente. Muitas vezes o cliente não 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 prototipação tem suas vantagens e desvantagens, mas se bem dosado com os modelos de diagramação UML, é possível trazer muitos benefícios 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 prototipação da Engenharia de Software, no desenvolvimento de uma aplicação para a um mercado de venda de produtos variados. O objetivo foi desenvolver o sistema de forma rápida e estrutural, sem se delongar em papéis e diagramação, mas também sem se perder no meio de códigos sem documentação. Utilizando da idéia da Prototipação, em Engenharia de Software, desenvolveu-se um sistema e foi realizada a documentação através da UML.

Estrutura da monografia Esta monografia foi estruturada em capítulos assim redigidos: O capítulo 1 apresenta os principais conceitos de Engenharia de Software, detalha os diagramas a serem elaborados através da UML e o modelo entidade-relacionamento no

12

projeto do Banco de dados. Também apresenta os ciclos de vida de um sistema, com destaque para a Prototipação. O capítulo 2 descreve a aplicação desenvolvida para o mercado de venda de produtos variados. Apresenta o Documento Visão, o Diagrama de Classes com as funcionalidades exigidas e o MER (Modelo Entidade Relacionamento) da aplicação. Neste capítulo também são abordadas algumas tecnologias utilizadas na elaboração do software. Ao final do capítulo estão apresentadas e descritas as principais interfaces do sistema. No capítulo 3 tem-se a conclusão e sugestão para trabalhos futuros.

13

1. ENGENHARIA DE SOFTWARE E UML Engenharia de software é uma área do conhecimento da computação voltada para a especificação, desenvolvimento e manutenção de sistemas de software aplicando tecnologias e práticas de gerência de projetos, objetivando organização, produtividade e qualidade1. Ela possui três fases, segundo Pressman (1995 p. 46), definição, desenvolvimento e manutenção. Todo o desenvolvimento estaria envolvido dentro dessas três grandes fases. A UML (Unified Modeling Language) surgiu na necessidade de um padrão dentro do mundo da engenharia de software, sendo um modelo de análise orientado à objeto. O Processo Unificado, segundo Medeiros (2004 p. 11) é dirigido por Casos de Usos. Pressman (1995 p. 41,42) cita sobre as técnicas de quarta geração, onde o desenvolvimento de software precisa de planejamento e documentação significativa. A Prototipação, um dos ciclos de vida da engenharia de software, trabalha de maneira mais simples, com RAD (Rapid Application Development), que usa aplicações de rápido desenvolvimento para mostrar protótipos para o cliente e constantes correções e adaptações. A UML então serve como base para documentação e modelagem de todas as etapas do desenvolvimento do software, ajudando na definição, no desenvolvimento e na manutenção. A Prototipação, como ciclo de vida, traz rapidez em software de baixa escala, para desenvolvimento específico de pequenas empresas. A seguir, ambas serão mais detalhadas.

1.1. ENGENHARIA DE SOFTWARE: UMA VISÃO GERAL. Medeiros (2004, p. 2) sugere que a construção de um software possui seis estágios: 1ª) Concepção: a idéia inicial é formada na mente do idealizador de forma ainda meio obscura, onde este identifica necessidades que precisam ser supridas por algum advento tecnológico. Talvez por falta de conhecimento técnico, este não seja capaz de especificar soluções e métodos que atendam as necessidades. Medeiros (2004, p. 2) faz comparação à construção civil, onde o cliente tem uma idéia e quem vai dizer se esta idéia pode ou não ser construída seria o engenheiro civil, de acordo com as especificações do idealizador e das possibilidades da engenharia. 2ª) Aprovação da concepção: nesta parte o interessado deve aprovar uma primeira idéia para solução das suas necessidades. São entregues os detalhes de diagramação esboços

1

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

14

no papel, que requerem algum conhecimento avançado para entendimento e compreensão. Como a visão do interessado é de alto nível, este não possui nada palpável para apresentação no projeto, e como neste estágio são apresentados modelos técnicos, é claro que algumas especificações e detalhes serão alterados de acordo com as experiências e conhecimentos dos especialistas envolvidos. Mais uma vez fazendo referência à construção civil, o cliente depois de ver as plantas faz suas críticas e então decide conforme suas vontades e recusas de mudanças. É neste estágio que são decididos todas as propostas que estão no projeto o modelo idealizado anteriormente. 3ª) Detalhamento completo das necessidades do software: aqui são realizados todos os detalhamentos do software, ou seja, nada prático ainda, mas novamente são discutidas as diferenças entre as especificações e a idéia, dessa vez de forma mais amadurecida, tanto a idéia inicial agora com mais esclarecimentos e o especialista com melhor conhecimento das especificações, irão apresentar argumentos mais significativos e menos triviais para aperfeiçoamento do sistema. Em nova comparação com a construção civil, este estágio não sofre grandes mudanças aparentes, mas reafirma as decisões sobre as diferenças. 4ª) Início da construção: então se inicia a codificação do sistema, que tem seu início pelo modelo de Entidades e Relacionamentos. Assim que o interessado observa a primeira idéia de interface, as necessidades à serem atendidas sofrem mudanças, agora vendo algo mais concreto e com a idéia cada vez mais madura. Na construção civil, o interessado visualiza sua idéia de uma forma conhecida e forma uma imagem preliminar, e apesar de ser diferente do „sonhado‟, este apenas apresentará objeções se a concepção for muito diferente dos requisitos apresentados. Nesta parte algumas coisas são diferentes no comparativo, pois trabalhando com a construção civil não é possível mudar algumas metragens, dimensões do quarto, pois estes acarretam em mudanças físicas reais, enquanto ainda são possíveis algumas mudanças no software, pois mesmo sendo especificado, ainda é um modelo lógico de programação, portanto mudanças só acarretarão em novos dados de especificação, não em desastre físico. 5ª) Construção e testes: nesta parte o interessado se distancia da parte de desenvolvimento, pois se entende que tudo foi especificado e esclarecido durante os estágios anteriores, portanto nesta etapa espera-se os resultados dos trabalhos anteriores. Este estágio é crucial para estabilidade, pois se algum funcionário for demitido ou desistir do projeto, este

15

perderá características, devido à individualidade durante a elaboração dos códigos, tornando mais complicado dar continuidade ao sistema. O mesmo acontece na construção civil, a troca de um funcionário pode trazer mudança no ritmo, ordem e prioridades da construção. Gostos diferentes por diferentes modelos podem causar diferenças quanto ao modelo de construção e trazer empecilhos quanto ao andamento da obra. 6ª) Entrega: quanto chega o momento de entregar o software ao cliente raramente temse alguma comemoração, simplesmente escuta-se “não era isso que eu queria realmente”, ou “está muito bom, mas poderia mudar isso e isso”...

Requerimentos
Risco

Análise e Design
Risco

Implementação
Testes Implantação
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 diferença entre construir uma casa sem projeto e um prédio. É preciso planejamento e documentação. Por mais simples que seja um software é sempre preciso modelá-lo, por que como Guedes (2004, p. 18) explica: “os sistemas de informação frequentemente costumam possuir a propriedade de crescer”. Alguns afirmam que seja pelo fato de que cada software é característico, faz-se uma analogia com „estar vivo‟, o mais correto seria dizer que o software é „dinâmico‟, pois está sempre mudando e se adaptando às necessidades dos usuários e como cada desenvolvedor tem suas características para programar, este, na maioria das vezes, implica códigos e algoritmos de própria preferência para o programa.

16

Guedes (2004, p. 19) separa em quatro partes o desenvolvimento de software dentro da Engenharia de Software. 1ª) Levantamento e Análise de Requisitos: nesta etapa o engenheiro busca as necessidades do cliente dentro da empresa, levando em consideração todos os conhecimentos do engenheiro para que seja feito uma análise concreta. É necessário dizer que às vezes nem o cliente sabe o que quer, por isso é muito importante que a comunicação seja de confiança e mais simples possível entre o analista e o cliente. É neste primeiro estágio que o cliente irá expor suas necessidades e o analista irá relatando e anotando suas soluções com base nos estudos e experiências. 2ª) Prototipação: Guedes (2004, p. 20) usa a prototipação aqui como ciclo de vida para melhor se desenvolver um software. Ele explica que a prototipação é como poder escrever um rascunho do sistema e entregar vários desses rascunhos para aprovação do cliente. Um protótipo 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 relatórios, e o cliente irá dando seu parecer e opinião. Existem muitas plataformas que possibilitam o desenvolvimento com protótipos, elas são conhecidas como RAD ( Rapid Application Development ou Desenvolvimento Rápido de Aplicações). Algumas são 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 experiência de desenvolvimento, ou seja, caso a empresa, engenheiro, desenvolvedor ou programador não tenha nenhuma experiência com alguma ou todas as partes dos requisitos, estes não serão capazes de estabelecer um prazo com alguma precisão. É muito importante lembrar que mesmo assim, como todos estes profissionais devem ter estudado para ter alguma noção 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 necessário, e após algum tempo de desenvolvimento deve-se medir se a quantidade já desenvolvida está de acordo com os prazos estabelecidos, se estão 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 são fáceis 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 mão-de-obra será necessário para finalizar o projeto. 4ª) Manutenção: 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 manutenção. É nesta parte que se torna importante a modelagem do sistema (diagramas) e toda a sua documentação, pois os documentos não irão somente ajudar a corrigir erros e melhorias, mas irão ajudar a localizar qualquer detalhe dentro do sistema, facilitando qualquer tipo de mudança que a empresa deseja fazer dentro do software. Lembrando sempre que é preciso atualizar as modelagens e a documentação para que se possa confiar posteriormente nestes documentos para futuras consultas. Guedes (2004, p. 24) também leva em conta a Documentação Histórica, onde a empresa usaria todas as documentações dos softwares já desenvolvidos para fazer análises de crescimentos, administrativo e de produção, o que para este trabalho de desenvolvimento não se apresenta pertinente. Para Pressman (1995 p. 46) a engenharia de software teria apenas três fases: definição, desenvolvimento e manutenção. Cada uma dessas fases tem as seguintes funções a serem exercidas: A fase de definição procura o quê deve ser feito. Assim, o analista deveria definir as características do software, como funcionalidades, propriedades, requisitos e limitações do sistema. Dentro desta fase são identificadas três etapas: a) Análise do sistema: é a parte onde são descritas as funções do sistema, atribuindo os requisitos que o software atenderá. b) Planejamento do projeto de software: depois de bem analisado os requisitos, são traçados os riscos, recursos e custos para estabelecer os prazos e as atividades a serem exercidas. c) Análise de requisitos: é preciso que haja domínio sobre todas as funções do sistema, para isso analisam-se todos os requisitos necessários para que as funções do sistema atendam os requisitos especificados. A fase de desenvolvimento procuraria o como. Após a definição dos requisitos, onde o analista define a estrutura dos dados e a arquitetura que o sistema terá, os programadores e projetores irão transformar as análises em projeto e códigos. Os métodos para se desenvolver podem ser vários, mas três passos sempre estarão presentes nesse estágio: a) Projeto de software: aqui o projetista define em conjunto de representações desde a estrutura dos dados, a arquitetura e os procedimentos. É traçado um

18

planejamento para que o software siga uma linha de desenvolvimento de código. b) Codificação: Depois do projeto do software, inicia-se a codificação numa linguagem de programação, ou seja, os programadores irão implementar as funcionalidades e propriedades de acordo com as necessidades do sistema. c) Realização de testes do software: logo depois da implementação do software, devem ser realizados testes para verificar se as funções estão corretas, se não possuem defeitos de lógica e implementação. Esta primeira fase de testes é meramente superficial, pois o verdadeiro teste é feito com o usuário final, que irá especificar cada dificuldade ou erro encontrado. Por fim a fase de manutenção que se concentra em mudanças que ocorrerão ao longo da implantação do software. Vários aspectos levam um software a sofrer mudanças neste estágio. Nem sempre o cliente especifica aquilo que quer, o ambiente pode ter mudado e procedimentos serem alterados, e também, o usuário pode trabalhar de maneira diferente do esperado pelos projetistas. Mas sempre três mudanças irão aparecer neste estágio: a) Correção: ocorre toda vez que o usuário acha um erro ou „acha‟ que o software possui algum erro. Como dito anteriormente, as correções realizadas pelos desenvolvedores são superficiais, assim somente o usuário final é quem irá identificar os verdadeiros erros no sistema. b) Adaptação: depois de um tempo o ambiente de trabalho pode mudar, novas características são agregadas ao trabalho e outras funções podem aparecer ou se tornarem obsoletas. A manutenção adaptativa irá modificar o software em partes para que possa acomodar o software as novas exigências do trabalho. c) Melhoramento funcional: a medida que o usuário vai aprendendo a lidar com o sistema, este identifica novas funções que podem ser aplicadas em certos meios, e também, a experiência com outros sistemas traz novas idéias para o usuário. Em alguns casos onde o software é alterado mais do que as exigências solicitadas pelo cliente, é chamado de manutenção perfectiva. Apesar de serem apresentadas várias 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 serão 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 estágio, fase ou estado do desenvolvimento de software será trabalhado, de acordo com sua importância para os

19

resultados. Irá influenciar também na escolha da documentação, definindo quais partes da UML serão necessárias 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 máximo cinco anos, pois um software nunca está por acabado, sempre têm manutenções, correções e melhorias. Ele define algumas fases como sendo parte essencial do ciclo de vida natural do software: - concepção: quando a idéia do software surge, ou seja, as suas necessidades; - construção: quando são feitas as especificações, documentações e a programação; - implantação: onde o software é finalmente testado, corrigido e disponibilizado para o cliente; - maturidade e utilização plena: quando o software tem suas melhorias, muda de aparência para uma interface mais amigável, agrega características e funcionalidades; - declínio: quando um software se torna difícil de ser continuado, adaptado ou restaurado. Quando um software chega a ser obsoleto; - manutenção: a última tentativa de sobrevivência do software, com adaptações, ajustes e mudanças. Rezende (2005, p. 41) também define que neste estado do software é possível que o ciclo de vida fique em espiral ou looping (girando), retardando a morte e o declínio 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 nível operacional, como Folhas de pagamento, Contabilidade, Contas a pagar, pois esses sistemas estão baseados em outros sistemas que foram formados e formatados a muito tempo e não devem mudar tão facilmente.

1.2.1. OS VÁRIOS TIPOS DE CICLOS DE VIDA. Pressman (1995, p. 32) define que podem existir vários tipos de ciclos de vidas. Não existe uma forma única e padrão para a resolução dos problemas de se desenvolver um software, o que existe são vários modelos, estudos e métodos que abrangem todas as fases de desenvolvimento, que juntos e bem utilizados vão fazer a engenharia de software.

20

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

Existe o ciclo de vida clássico, a prototipação, o modelo espiral, as técnicas de quarta geração e a combinação de paradigmas. O ciclo de vida clássico traz um modelo cascata (ilustrado na Figura 2), onde o ciclo de vida está em um modelo sequencial, um paradigma clássico em que uma fase de desenvolvimento vem após a anterior ser concluída. As fases são: Análise de engenharia de sistemas, análise, projeto, codificação, teste e manutenção.

Figura 3 - Prototipação. (Fonte: Engenharia de Software, PRESSMAN p. 36)

A prototipação, que é o modelo adotado neste trabalho (ilustrado na Figura 3), é um modelo utilizado quando existe apenas uma idéia primária de que o software deve fazer. Assim, o analista ou desenvolvedor não tem idéia de como serão as funcionalidades, trazendo assim três possíveis soluções:

21

a) um protótipo escrito em papel, com uma idéia mais elaborada como resposta as idéias iniciais; b) um protótipo em formato digital, apresentando pequenas funcionalidades possíveis e um subconjunto de propriedades; c) um programa já existente que pode ter parte ou total das funções básicas esperadas, mas com outras características que serão adaptadas pelo novo desenvolvedor para atender o cliente. A prototipação apresenta um ciclo de desenvolvimento no qual o analista coleta e refina os requisitos, elabora um projeto rápido e constrói um protótipo. Em seguida o cliente avalia o protótipo, e novamente o protótipo é refinado podendo voltar para a projeção do software ou continuar na engenharia. Quando o software sai do modo protótipo, ele recebe o número das versões (em termos atuais, sai da versão Alfa ou Beta). A seguir, neste capítulo, tem-se um melhor aprofundamento sobre a prototipação.

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

O modelo espiral uniu o ciclo de vida clássico com a prototipação, trazendo um novo paradigma de análise. Ele possui quatro importantes atividades descritas na Figura 4:

22

Planejamento, análise de riscos, engenharia e avaliação pelo cliente. Ou seja, nesse caso o cliente avalia o software somente após o mesmo ter passado pela engenharia, e os testes preliminares são realizados pelos desenvolvedores. Este é um paradigma usado em grandes sistemas, onde a experiência do grupo de desenvolvimento é grande e a avaliação do cliente não resulta em grandes alterações do software.

Figura 5 - Técnicas de quarta geração. (Fonte: Engenharia de Software, PRESSMAN p. 42)

Por fim as técnicas de quarta geração ilustradas na Figura 5, que abrange um grande conjunto de ferramentas que possuem uma coisa em comum: a possibilidade do desenvolvedor especificar suas características e seu modelo de desenvolvimento. Usando as técnicas de quarta geração é possível que o desenvolvedor possa gerar resultados com o software sem ter que gerar novos códigos. Entretanto esse tipo de técnica é de difícil controle e precisa de descrições detalhadas. As técnicas de quarta geração segue um ciclo de coleta de requisitos, estratégia de “projeto”, implementação usando as técnicas de quarta geração e finalmente os testes. Pressman (1995, p. 43) ainda faz uma previsão sobre o uso dessas novas técnicas, acertando de forma brilhante quando nos deparamos com os modelos UML. Ele diz que cada vez mais será preciso utilizar dessa nova geração de modelos, documentação e especificação, com o crescimento acelerado das necessidades de software. A Figura 6 apresenta a dinâmica 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 previsão foi feita para até o fim da década de 90, quando já estamos entrando na década de 20 do século 21, onde é impossível não ter sistemas de controles com alta demanda de comunicação com banco de dados, algoritmos mais especialistas e interfaces altamente desenvolvidas.

1.2.2. PROTOTIPAÇÃO A Prototipação é 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 ação 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 sequência de eventos simples e também um paradigma eficiente dentro da engenharia de software. Entretanto é preciso que tanto o cliente quanto o engenheiro estejam de acordo que a „prototipação‟ será o modelo a ser seguido para o desenvolvimento do software, e que este servirá como mecanismo para a elaboração do software final. Segundo Pressman (1995, p. 37), a prototipação começa com a análise e coleta dos requisitos. Nesta parte é muito importante definir os pontos principais e requisitos a serem atendidos para o cliente, pois a Prototipação destina-se a desenvolver um sistema em curto prazo e que atenda especificadamente as necessidades do cliente. Não adianta fazer uma grande análise e um planejamento demorado, pois a prototipação só atrasará o desenvolvimento neste caso.

24

Após a análise deverá ser feito um projeto rápido, observando apenas os pequenos aspectos em que o cliente tenha ação, como entras e saídas básicas, interface primária e de alguma forma amigável, mas ainda não se preocupando com aparência e aspectos finais. O cliente deverá ter um primeiro contato com os resultados primários e deverá apresentar todas as dificuldades, diferentes necessidades, novas idéias e tudo que necessitar que mude, pois o protótipo norteará até que ponto o cliente pode pedir e vai ajudá-lo a entender como a aplicação irá trabalhar. Depois do cliente ter sua primeira experiência com o protótipo do sistema, o programa sofrerá um refinamento, que seria o atendimento de todas as necessidades pedidas pelo cliente, alterações 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 é computável. Este ciclo se repete até que o protótipo esteja funcionando de modo a atender praticamente todas as necessidades do cliente e operar de maneira agradável. Após vários refinamentos e reprogramações, o protótipo deve ser finalmente descartado. Esta é uma parte constrangedora tanto para o desenvolvedor quanto para o cliente. O cliente não ficará satisfeito em ouvir que terá de ser feito um novo programa, e o engenheiro de software não tem tanta paciência para ficar desenvolvendo tudo duas vezes. Mas esse é o objetivo da prototipação, estabelecer todas as necessidades do cliente e achar as soluções de forma prática ao mostrar resultados e facilitar no entendimento para o programador e o engenheiro. A necessidade de se jogar fora o protótipo é que este sofreu tantas modificações no código que provavelmente está com algumas funções instáveis, propriedades sem formatação, estrutura desorganizada e gambiarras por todas as conexões. O fato é que não será jogado fora o software, mas apenas será construído um novo a partir do protótipo, mas dessa vez já sabendo os resultados esperados, quais implementações serão feitas em cada etapa e terá um padrão em seu código, de modo a ficar fácil para fazer manutenções a longo prazo. A importância de acordo entre o cliente e o engenheiro se mostra totalmente necessária, pois após tanto tempo de uso do sistema “funcionando”, este terá de mudar e finalmente adquirir característica própria. A prototipação não tira a necessidade de documentar o sistema, mas ele dá a oportunidade de se fazer tanto as documentações necessárias quanto o desenvolvimento ao mesmo tempo, ganhando em resultados a curto prazo e a realização de um melhor trabalho entre a área de análise de sistema, engenharia de software e programação.

25

1.3. UML E SEUS DIAGRAMAS Medeiros (2004, p. 11) explica que UML não é um processo de desenvolvimento, logo, este não norteia como deve ser desenvolvido e para onde vai cada etapa do desenvolvimento. UML simplesmente ajuda sendo uma forma de comunicação que um processo pode utilizar, ou seja, é uma simples maneira de pelo menos padronizar a maneira como são feitas as análises de requisitos, as diagramações, as modelagens do bando de dados. Assim como no sistema métrico, existe uma ordem e uma medida certa para cada unidade, só que cada um gosta de usar a medida que lhe parece mais prática. A UML 2.0 trabalha com vários modelos de documentação que ajudam ao desenvolvimento no momento de apresentar suas especificações e diagramações. Medeiros (2004, p.11) cita os seguintes documentos/diagramas: Documento Visão; Diagrama de Caso de Uso; Diagramas de Componentes e Implantação; Diagrama de Interação – Visão Geral e MER (Modelo de Entidade e Relacionamento). Já Guedes (2004, p. 26) apresenta vários diagramas: Diagrama de Caso de Uso; Diagrama de Classes; Diagrama de Objetos; Diagrama de Estrutura Composta; Diagrama de Sequência; Diagrama de Colaboração (Comunicação na UML 2.0); Diagrama de Gráfico de Estados (Máquina de Estados na UML 2.0); Diagrama de Atividades; Diagrama de Componentes; Diagrama de Implantação; Diagrama de Pacotes; Diagrama de Interação Geral; Diagrama de Tempo. Tom Pender (2004, p. 39) diz que os diagramas são 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 Composição; Diagrama de Componentes; Diagrama de Implantação; Diagrama combinado de Componentes/Implantação; - Diagramas Comportamentais: Diagrama de Caso de Uso; Diagrama de Atividades; Diagrama de interação; Diagrama de Máquina de Estados; Diagrama de Máquina de Estados do Protocolos. Como se podem observar a UML nos apresenta um escopo completo e de todos os possíveis casos de diagramações e documentações para os estágios de desenvolvimento de um software. Não havendo necessidade de se utilizar algum destes, não há necessidade de documentar. Dentro da apresentação deste trabalho especificadamente serão utilizados apenas

26

quatro modelos: Documento visão, 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 comunicação é extremamente facilitada e a necessidades de documentação é apenas para dar uma idéia específica e nortear o desenvolvimento de tal modo que toda vez que seja necessário uma mudança no sistema, a localização da mudança seja facilmente encontrada e aplicada de acordo com as necessidades no momento de testes e correção de falhas do sistema.

1.3.1. DOCUMENTO VISÃO O documento Visão é 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 especificações para elaborar o sistema. Medeiros (2004, p. 22) diz que o Documento Visão é um relato resumido com os principais requisitos que o software deve atender. Ele deve ser um documento que relata em linguagem de alto nível, todo o escopo de funcionalidades em que o software irá planejado. Geralmente este documento está presente junto com o contrato de serviços, pois é neste contrato que irão se basear os próximos documentos. O diagrama de Caso de Uso de nível 0 é baseado neste documento. Este documento nasce na primeira reunião entre o cliente e o projetista. Enquanto o cliente diz sua idéia de como o software deverá agir quanto implantado, o projetista (com base em seu conhecimento e experiência) identificar quais são 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 visão, que possui um modelos com os seguintes tópicos: Introdução; Escopo; Definições, Acrônimos e Abreviaturas; Referências; Oportunidade de Negócio; Problema a ser solucionado; Descrições de Stakeholder e Usuários; Stakeholder; Usuários; Ambiente Atual dos Clientes; Observação; Módulos; Perspectivas do Produto; Precedência e Prioridades; Requisitos não funcionais; Requisitos de Sistema e Ambientes; Sistema Operacional; Linguagem de Desenvolvimento; Banco de Dados; Requisitos de Documentação; Visão Geral UML do Sistema – Modelo Conceitual. Após a elaboração do documento Visão, então 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 usuários têm 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 usuário. Identifica recursos específicos do sistema, para que cada detalhe não fuja de descrição, o diagrama de Caso de Uso tem vários níveis para cada funcionalidade específica. Identifica o comportamento compartilhado entre os recursos do sistema, facilitando em caso de redundância, onde um mesmo recurso é utilizado várias vezes em outros casos, facilitando sua implementação e documentação. Oferece um modo simples e fácil de entender para que os clientes entendam os requisitos, fazendo com que a abstração do conhecimento do especialista e a idéia do cliente se formem no papel e haja concordância 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 usuário, um cenário onde o usuário 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 são feitos em duas formas, uma escrita, de acordo com os vários padrões existentes, como colunas de ação do usuário e reação do sistema, ou listas de ações e estados possíveis com várias ações do sistema. Posteriormente a diagramação, onde a UML possui um padrão para ilustrar os nomes dos casos de usos, atores e seus relacionamentos. Guedes utiliza apenas um tipo de documentação de caso de uso, onde cada caso de uso é documentado e separado por várias etapas e características. Neste trabalho, será utilizado este modelo de documentação.

1.3.3. DIAGRAMA DE CLASSES Segundo Pender (2004, p. 42) “o diagrama de Classes é a origem para a geração de código(...) e o destino para a engenharia reversa(..). O diagrama modela os recursos usados para montar e operar o sistema.” Ou seja, é neste diagrama que estão as características e

28

atribuição de valores de todos os campos do projeto, e como estarão organizados dentro de suas classes. Os diagramas de Classes são importantes, pois definem os recursos essenciais de um sistema, deixando claro onde estão localizadas as funcionalidades que o sistema irá exercer. Define relacionamentos entre os recursos, especificando quais interfaces e caminhos cada recurso se comunica com outro. São gerados códigos a partir de suas classes, definindo propriedades e como cada propriedade será trabalhada. Modela-se o código para a engenharia reversa, e toda vez que for necessário mudar um código, muda-se no diagrama de classes as propriedades e os modos de trabalhos. Além de oferecer uma direção para os outros diagramas, pois a partir da organização do diagrama de Classes é que serão definidas quais necessidades os outros diagramas irão 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 irão ser identificados como o banco de dados irá ser organizado, a propriedade de cada dado, quais colunas terão vínculos, as chaves primárias, as chaves estrangeiras, o relacionamento entre as tabelas, etc. Muitas pessoas confundem as classes com tabelas de banco de dados, mas não são, pois as classes são modelos de objetos para o desenvolvimento do software, e a tabela de banco de dados são repositórios 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 dicionário de entidades. Em terceiro um registro de entidades. Em seguida o dicionário de dados e o relacionamento entre entidades. Então deverá ser feita uma normalização para então, por fim, realizar o relacionamento do MER. Banco de dados possui toda uma extensão e várias teorias que precisam de amplas explicações, mas não é o objetivo deste trabalho e nem da UML explicar essas teorias, e sim usá-las de maneira correta para a elaboração do software.

29

1.4. CONSIDERAÇÕES FINAIS A UML trás vários modelos de documentação que proporcionam um amplo escopo de definições e fácil comunicação entre as partes de um projeto para o desenvolvimento de software. A engenharia de software define o caminho para a construção de software, utilizandose das experiências e comparações com outras engenharias e formando um próprio conceito, trazendo os passos necessários para se alcançar a qualidade de software. O uso dos ciclos de vida irá determinar a qualidade final esperada e quais tipos de documentações serão necessários para que possa chegar à um produto final que atenda todos os requisitos iniciais. A combinação entre a Prototipação, o documento Visão, 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 APLICAÇÃO. O objetivo deste capítulo é apresentar um breve histórico do ramo de negócio da empresa e também todos os documentos e diagramas elaborados, baseados nas especificações da UML e na prototipação de sistemas. Também apresenta algumas interfaces da aplicação desenvolvida.

2.1. DESCRIÇÃO BREVE DO RAMO DE NEGÓCIO DA EMPRESA. A empresa é de médio porte, onde apenas os vendedores serão os usuários mais freqüentes do sistema e os repositores de estoque serão a outra parte de usuários 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. Também com pequenas vendas de utensílios para o dia a dia, a empresa procura sempre vender produtos de consumo, mesmo não sendo alimentos, produtos que serão consumidos ao longo do tempo e de pequena a média duração. 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 preço automaticamente para que o cliente da empresa fique menos tempo possível no caixa. A empresa também terá grandes estoques de produtos chegando todos os dias, os repositores são responsáveis por contar a quantidade do produto, verificar e então dar entrada no sistema com a quantidade, nome e descrição do produto. A distribuição dos produtos nas prateleiras fica a cargo da própria empresa.

2.2. AS PESSOAS ENVOLVIDAS (USUÁRIOS). Os usuários do sistema são de dois tipos: 1º) Os caixas: vendedores que deverão passar cada produto e sua quantidade no ato da venda, estes serão os usuários que apenas irão retirar quantidades de produtos do sistema. 2º) Os repositores: estes irão 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 usuários, além de serem responsáveis pelas devoluções dos produtos e controle de acesso ao sistema. O primeiro usuário precisa sempre saber o código de cada produto (seu código de identificação), em casos de erro em código de barras ou produtos mal registrados. O segundo

31

usuário simplesmente adiciona de acordo com o código de barras, caso o produto não tenha um comparativo ou cadastro, o sistema gerará um código automaticamente. Apenas o segundo usuário poderá adicionar um preço 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 serão necessárias algumas tecnologias já existentes. Serão estas o tipo de linguagem de programação que será usado, o servidor de dados, onde os todos os dados serão guardados e o tipo de banco de dados que será utilizado para modelar e organizar os dados.

2.3.1. LINGUAGEM DE PROGRAMAÇÃO. A linguagem de programação 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 análise de sistema e também a Prototipação, pois é uma plataforma que pode mostrar protótipos com poucas linhas de programação. É uma plataforma de desenvolvimento rápida, porém com muitas funcionalidades e totalmente multi-plataforma, ou seja, pode rodar em quaisquer dos três grandes sistemas operacionais, Windows, MAC ou Linux. Além 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 comunicação, por padrão, 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 não é obrigatório. A escolha pelo MySQL foi por ser um SGBD muito conhecido, que atende todas as necessidades de inserção e recuperação de dados de modo simples e prático, além de gratuito.

32

2.4. UML. A seguir são apresentados os documentos e diagramas elaborados segundo a UML.

2.4.1. DOCUMENTO VISÃO. O documento visão, 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; Descrição:

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, preço e valor total das compras. O sistema também deverá aceitar o cadastro de novos produtos, as quantidades cadastradas e sua marca, juntamente com a descrição do produto e da marca. Toda vez que um usuário for usar o sistema, este deverá fazer o login para utilizá-lo. Cada marca deverá ser cadastrada e deverá ter um nome e descrição. A cada venda, o software irá gerar um cupom fiscal de acordo com os padrões estabelecidos com todas as mercadorias e informações da venda, juntamente com o valor total, o valor pago e o troco. Cada venda acarretará em diminuição no estoque das mercadorias. Cada venda deverá ter um código que será mantido no histórico do banco de dados, constando uma lista com os códigos dos produtos vendidos e quantidade, além da data e hora, nome do balconista e número do caixa em que ocorreu a venda. Qualquer devolução só poderá ser feita durante o ato de venda, após o pagamento não será possível estornar ou apagar qualquer transação. Somente os administradores deverão fazer estorno durante o ato de venda e isto não 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 - Nível 0 foi elaborado após o documento visão. Diferente do desenvolvimento de outros diagramas, o diagrama nível 0 foi desenvolvido antes dos primeiros testes. Já os diagramas nível 1 e nível 2 foram feitos após alguns testes. Ficou estabelecido que o sistema também é um ator, pois o mesmo realiza funções automaticamente a partir de certos pontos de decisão. Apesar deste ator (sistema) não atuar sozinho, depender de eventos externos e também de não ser disparador de eventos, mas é ele quem estabelece características de padronização à aplicação. Então como o sistema é quem estabelece os padrões e toma algumas decisões, ficou estabelecido que ele é ator de algumas funções.

Figura 7 - Diagrama de Caso de Uso nível 0

A Figura 7 apresenta o Diagrama de Caso de Uso nível 0. Todo usuário antes de executar alguma ação no sistema deverá passar pela Gerencia de Login, que depende da Autenticação do Sistema.

34

O Caixa irá efetuar a venda e, após 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 Devoluções de produtos.

Figura 8 – Diagrama de Caso de uso nível 1 – Venda.

A Figura 8 apresenta o Diagrama de Caso de uso nível 1 - Venda. O Caixa, quando efetua a venda, registra a saída dos produtos (o Sistema verifica a existência do cadastro de cada produto). Após a finalização da venda, o sistema gera e imprime o Cupom Fiscal. A Figura 9 abaixo apresenta o Diagrama de Caso de uso nível 1 - Login. Toda vez que o Gerente de estoque, o Caixa e o Administrador forem entrar no sistema, estes deverão inserir seus logins e senhas. O Sistema então verificará a permissão de acesso.

Figura 9 – Diagrama de Caso de uso nível 1 – Login.

35

2.4.3. DIAGRAMA DE CLASSES

Figura 10 – Diagrama de Classes.

A Figura 10 mostra o Diagrama de Classes. Após algumas visitas ao cliente este diagrama foi aperfeiçoado e representa a organização do sistema no desenvolvimento do primeiro protótipo. Na Figura 10, a classe Pessoa tem três subclasses que herdam seus atributos: Administrador, o Gerente de Estoque e o Caixa. O Gerente de Estoque pode adicionar vários produtos e um produto pode ser adicionado por vários Gerentes de Estoque. Cada produto só tem uma marca, mas uma marca pode estar em vários produtos. O Caixa pode fazer várias vendas, e cada venda só tem um caixa. Cada venda possui vários produtos e um produto pode aparecer em várias vendas. A classe do sistema cuida da Gerencia de Logins e o Administrador faz o cadastro dos usuários. 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 não haja perigo de se perder campos ou tabelas, ou informações importantes quanto às configurações de base.

36

Figura 11 – Diagrama do MER.

Na Figura 11 tem-se o MER (Modelo Entidade Relacionamento). Um funcionário pode realizar várias vendas. Cada venda contém vários itens (venda de produtos). Cada item (venda de produtos) está relacionado a um produto. No processo de entrada de produtos, tem-se uma lógica parecida com a venda. Um funcionário pode dar entrada de vários produtos (tabela entrada produtos). Um produto pode ser introduzido por diferentes funcionários.

2.3.5. INTERFACES DO SISTEMA. Na figura 12 a seguir tem-se o protótipo da tela de login, onde o usuário irá digitar um login, previamente cadastrado pelo administrador, e uma senha também já cadastrada. O Sistema começará 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 inserção do código que pode ser manual ou automática com algum leitor de código 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 então o campo de recebimento ficará em evidência, para que seja digitado o valor pago, então o usuário apertará o „Enter‟ e será impresso o Cupom fiscal e será finalizada a venda. Na parte esquerda da janela (em branco) tem-se o relatório atual das vendas. Sempre que um produto for adicionado ou inserido pelo leitor de código de barras, este será adicionado à lista. A lista contém a ordem do item, seu nome com a marca, a quantidade,

38

preço 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 também ficará evidente abaixo do campo do valor pago. A partir desta janela, pressionando-se a tecla „F5‟, obtém-se a janela de busca de produtos.

Figura 14 - Tela de Buscas de Produtos e Códigos.

Esta janela, ilustrada na Figura 14, permite buscar todos os produtos do sistema, mostrando a sua quantidade no estoque, seu nome e o código, e no campo superior poderá ser digitado o nome ou o código do produto para busca. A cada dígito 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 então selecionar o produto, pressionando „Enter‟ o código é retornado para a janela de venda e então adicionado a lista de vendas.

39

Figura 15 - Tela inicial do Administrador.

Esta é a janela do Administrador (Figura 15). Após efetuar o login, o Administrador terá listado todos os usuários do sistema e o tipo de usuário. Dela, ele poderá procurar algum usuário, digitando algo no campo superior e então pressionando o botão „Buscar‟. Para editar algum usuário este poderá selecionar na lista e então pressionar o botão „Editar‟. E para adicionar um novo basta pressionar o botão „Adicionar‟.

Figura 16 - Tela de cadastro e edição dos usuários.

40

A Figura 16 ilustra a janela para adicionar um novo usuário, onde deverão ser preenchidos o nome completo do usuário, um login único, uma senha de conhecimento apenas do próprio usuário. Logo abaixo deve ser confirmada a senha, para que seja verificado se o usuário digitou aquilo que queria. Em seguida o Administrador deverá selecionar o tipo de usuário, se será um „Caixa‟, um „Administrador‟ ou um „Controlador de estoque‟. Após preencher todos os campos basta pressionar o botão „Salvar‟ para salvar o conteúdo e criar um novo usuário ou pressionar „Cancelar‟ para cancelar a operação e voltar a tela inicial do Administrador. Esta tela também serve para editar o login, senha ou tipo do usuário, entretanto quando esta tela aparecer para edição o campo de nome e login virão automaticamente preenchidos, assim como o tipo. O campo senha deverá ser escrito novamente caso deseje salvar as modificações, e também é possível alterar o tipo do usuário, modificando o campo „Tipo‟.

Figura 17 - Tela de edição de preço e quantidade dos Produtos.

A janela de edição de produtos é ilustrada na Figura 17. Após o Controlador de estoque fazer seu login, esta é sua janela principal. Nela têm-se os campos inalteráveis dos produtos: Nome, Código e Quantidade atual. Em seguida tem-se o Preço e Quantidade que se deseja adicionar. Para editar o Preço e Quantidade de um produto, basta selecioná-lo no primeiro campo „Produto‟, onde estarão relacionados todos os produtos cadastrados no sistema. Após a seleção o preço poderá ser alterado no campo „Preço‟ e quantidade adicionada no campo

41

„Quantidade‟, depois pressionar o botão „Atualizar‟ para apenas atualizar ou „OK‟ para salvar a modificação e então fechar a janela. Caso queria adicionar um novo produto basta pressionar o botão „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. Deverão ser preenchidos os campos „Nome do produto‟, „Descrição‟, „Código‟ (código de barras), o „Preço‟ e „Quantidade‟. Para apenas adicionar um novo produto basta pressionar o botão „Adicionar‟, senão, poderá salvar e sair ao pressionar o botão „OK‟. Caso a marca também não esteja cadastrada basta pressionar o botão „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 então pressionar o botão „Adicionar‟, após adicionar a nova marca ela aparecerá na lista e então para sair basta pressionar o botão „OK‟.

Figura 20 - Janela de Estorno de Produtos

Na figura 20 tem-se a janela de devoluções (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 devolução 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 endereço. Depois tem-se o número da emissão e a venda realizada. Os dados da venda são: ordem do produto, o código no sistema, a descrição contendo o nome e marca, a quantidade vendida, o valor unitário 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 implementação, 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 práticas. Mesmo o cliente e o engenheiro tendo negociado várias vezes as funcionalidades, as especificações e testes singulares, só depois de implementado é que o sistema pode ser realmente testado e analisado. Esta é a primeira versão de testes, chamada geralmente de versão „Beta‟ entre os profissionais de T.I. (Tecnologia da Informação), e o produto agora está aberto para todos os tipos de testes práticos. Cada usuário (caixa/estoquista/ administrador) dá um feedback (retorno) contendo opiniões, erros, melhorias e dificuldades encontradas num período estipulado pela equipe de desenvolvimento. Este sistema atualmente já conta com o cadastro dos produtos e informações básicas, como preço, nome e quantidade. As marcas são cadastradas normalmente. Cada usuário já pode testar a sua área cadastrada. O Administrador pode cadastrar novos usuários e especificar suas funcionalidades. A venda já está funcionando, buscando e listando os produtos, fazendo os cálculos de venda, pagamento e troco, e no final emitindo um Cupom Fiscal padronizado. As funcionalidades implementadas são básicas, como cálculo de venda, busca dos códigos e nomes no banco de dados, como verificação de login e senha. Para fins de estudo, o sistema foi desenvolvido conforme planejado, seguindo o ciclo de vida da Prototipação. Sua documentação básica e necessária está toda de acordo com os padrões para que se possa dar continuação ao sistema. Como este é um trabalho de duração estipulada, o projeto se encerra aqui, mas mesmo assim com o objetivo de testes e demonstração 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 conclusão do projeto foi o agravante. Durante a elaboração da documentação UML surgiram algumas dúvidas, que foram sanadas no decorrer do tempo após algumas trocas de experiência com colegas e professores. O MER apresenta a modelagem do banco de dados, segundo Medeiros (p. 186).

2.7. CONSIDERAÇÕES FINAIS. Como este foi um trabalho com tempo delimitado e curto, a continuidade do mesmo pode ser repassada para um próximo candidato interessado sobre o tema. A documentação básica está documentada e, além disso, um primeiro protótipo foi implementado na linguagem REALBasic. O trabalho com Prototipação foi muito prático e os diagramas UML escolhidos foram muito úteis e serviram como base de estudos futuros.

45

3. CONCLUSÃO E TRABALHOS FUTUROS. O propósito deste projeto foi acompanhar o trabalho de um desenvolvedor no seu cotidiano. Como autor deste trabalho, e empregado numa empresa que desenvolve aplicações (software) para terceiros, foi de grande valia para o aprendizado profissional. A escolha da Prototipação para o desenvolvimento deste trabalho foi devido a sua flexibilidade e praticidade. A prototipação é um modelo de desenvolvimento muito usado no mercado e bastante eficiente para pequenas aplicações. A Prototipação não antecipa o desenvolvimento e a implementação do software, mas sim ajuda a demonstrar ao cliente o andamento do seu produto e do seu investimento. Também 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 idealização, criação e implementação. Faltaram as seguintes etapas: os testes, depois a implantação no qual o Protótipo passa a ser um produto mais completo e finalmente entra no ciclo de correção e manutenção. Os trabalhos com os diagramas UML deram os resultados esperados, especificando de forma clara e simples as funções e propriedades básicas do sistema. Dentro da Engenharia de Software, escolher um ciclo de vida não apenas afeta em como o sistema deverá ser desenvolvido, mas também afeta nos resultados esperados. Às vezes o tempo é o fator determinante, outras vezes são os recursos aplicados no desenvolvimento. A implantação deste sistema também poderia ser objeto de estudo futuro, para observar se a prática da Prototipação se encaixa neste tipo de aplicação. Estudos de relacionamento entre o cliente e o desenvolvedor também pode ser estudado, pois ainda existe uma grande barreira entre o mundo de T.I. e os negócios. Facilitar o entendimento, as relações, negociações e conversas entre os profissionais da área de tecnologia e os leigos são importantes para o trabalho de desenvolvimento, não somente na área de engenharia de software, mas também de comunicações de dados e armazenamento. Os diagramas UML padronizaram várias partes dessa comunicação e facilitam muito na hora de conversar e exemplificar para o cliente.

46

4. REFERÊNCIAS BIBLIOGRÁFICAS

CUNHA, Fulvio Alexandre da Cunha. Prototipação De Software. Publicado em 27/06/2007. Disponível 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 Prática 2ª edição. Editora novatec. Web site: www.novateceditora.com.br. Ano: 2004. LARMAN, Craig. Utilizando UML e Padrões – Uma introdução à análise e ao projeto orientados a objetos e ao Processo Unificado. Editora Bookman, 2ª edição. 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 Bíblia. 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ª Edição. Ano: 1995.

REZENDE, Denis Alcides. Engenharia de Software e Sistema de Informação. Editora BRADSPORT, 3ª edição. Web site: www.bradsport.com.br. Ano: 2005.

Sign up to vote on this title
UsefulNot useful