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
Prepare-se para as provas
Estude fácil! Tem muito documento disponível na Docsity
Ganhe pontos para baixar
Ganhe pontos ajudando outros esrudantes ou compre um plano Premium
Guias e Dicas
Prepare-se para as provas
Estude fácil! Tem muito documento disponível na Docsity
Encontrar documentos
Prepare-se para as provas com trabalhos de outros alunos como você, aqui na Docsity
Encontra documentos específicos para os exames da tua universidade
Encontra documentos específicos para os exames da tua universidade
Videoaulas
Prepare-se com as videoaulas e exercícios resolvidos criados a partir da grade da sua Universidade
Quiz
Responda perguntas de provas passadas e avalie sua preparação.
Ganhe pontos para baixar
Ganhe pontos ajudando outros esrudantes ou compre um plano Premium
Prototipação de Software - Apostilas - Informática , Notas de estudo de Informática
Apostilas de Informática sobre o estudo da Prototipação de Software: um estudo de caso para um Mercado de venda de Produtos variados, Definições de Engenharia de Software, Ciclos de vidas.
Tipologia: Notas de estudo
2013
1 / 47
Esta página não é visível na pré-visualização
Não perca as partes importantes!
Documentos relacionados
Pré-visualização parcial do texto
Baixe Prototipação de Software - Apostilas - Informática e outras Notas de estudo em PDF para Informática, somente na Docsity!
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
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.
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.
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.
ABSTRACT
This work presents the development of software to meet the needs of a market for sales of various products. The study aims to understand the development of facilities to work with prototyping, which is a life-cycle of software engineering, and some documentation from UML 2.0. In this work we see the definitions of Software Engineering explaining the cycles of life and the documentation subsequently chosen for the development of the system. At the end status is displayed on the system development and completion of this application.
Keywords: Prototyping. UML. Software Engineering. System. Customer.
LISTA DE ABREVIATURAS E SIGLAS
UML – Unified Modeling Language. MER – Modelo Entidade Relacionamento. BD – Banco de dados. RAD – Desenvolvimento Rápido de Aplicações.
SUMÁRIO
- Figura 1 - Desenvolvimento em Queda d'Água.
- Figura 2 - O ciclo de vida clássico.
- Figura 3 - Prototipação.
- Figura 4 - O modelo espiral.
- Figura 5 - Técnicas de quarta geração.
- Figura 6 - A natureza mutante do desenvolvimento de software.
- Figura 7 - Diagrama de Caso de Uso nível
- Figura 8 – Diagrama de Caso de uso nível 1 – Venda.
- Figura 9 – Diagrama de Caso de uso nível 1 – Login.
- Figura 10 – Diagrama de Classes.
- Figura 11 – Diagrama do MER.
- Figura 12 - Tela de Login.
- Figura 13 - Tela de Vendas do Caixa.
- Figura 14 - Tela de Buscas de Produtos e Códigos.
- Figura 15 - Tela inicial do Administrador.
- Figura 16 - Tela de cadastro e edição dos usuários.
- Figura 17 - Tela de edição de preço e quantidade dos Produtos.
- Figura 18 - Tela de cadastro de novos Produtos.......................................................................
- Figura 19 - Tela de cadastro de novas Marcas.
- Figura 20 - Janela de Estorno de Produtos
- Figura 21 - Modelo do Cupom Fiscal
- INTRODUÇÃO
- ENGENHARIA DE SOFTWARE E UML
- 1.1. Engenharia de Software: uma visão geral.
- 1.2. Ciclo de vida de um Software
- 1.2.1. Os vários tipos de ciclos de vida.
- 1.2.2. Prototipação
- 1.3. UML e seus diagramas
- 1.3.1. Documento Visão
- 1.3.2. Diagrama de Caso de Uso...............................................................................
- 1.3.3. Diagrama de Classes
- 1.3.4. Banco de dados - MER Modelo Entidade Relacionamento
- 1.4. Considerações Finais
- DESENVOLVIMENTO DA APLICAÇÃO.....................................................................
- 2.1. Descrição breve do ramo de negócio da empresa.
- 2.2. As pessoas envolvidas (usuários).
- 2.3. Tecnologias utilizadas.
- 2.3.1. Linguagem de programação.
- 2.3.2. Servidor e banco de dados.
- 2.4. UML.
- 2.4.1. Documento Visão.
- 2.4.2. Diagrama de Caso de Uso...............................................................................
- 2.4.3. Diagrama de Classes
- 2.4.4. O MER – Modelo Entidade Relacionamento.
- 2.3.5. Interfaces do Sistema.
- 2.5. Status do sistema e funcionalidades.
- 2.6. Dificuldades encontradas.
- 2.7. Considerações finais.
- CONCLUSÃO E TRABALHOS FUTUROS.
- REFERÊNCIAS BIBLIOGRÁFICAS
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
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.
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
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 tem- se alguma comemoração, simplesmente escuta-se “não 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 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.
Tempo
Risco
Requerimentos
Análise e Design
Implementação
Testes
Implantação
Risco
Figura 1 - Desenvolvimento em Queda d'Água. (Fonte: Desenvolvimento Software com UML 2.0 p. 8)
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
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