Monografia Engenharia de Software - Iuri

Monografia Engenharia de Software - Iuri

(Parte 1 de 5)

Porto Velho 2010

Porto Velho 2010

1 IURI MANDELA SIMÃO BATISTA

_ Profª, Msc. Liliane da Silva Coelho Jacon

_ Prof. Msc. Marcello Batista Ribeiro

_ Profª, Msc. Carolina Veludo Watanabe

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.

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

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.

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.

Figura 1 - Desenvolvimento em Queda d'Água15
Figura 2 - O ciclo de vida clássico20
Figura 3 - Prototipação20
Figura 4 - O modelo espiral21
Figura 5 - Técnicas de quarta geração2
Figura 6 - A natureza mutante do desenvolvimento de software23
Figura 7 - Diagrama de Caso de Uso nível 03
Figura 8 – Diagrama de Caso de uso nível 1 – Venda34
Figura 9 – Diagrama de Caso de uso nível 1 – Login34
Figura 10 – Diagrama de Classes35
Figura 1 – Diagrama do MER36
Figura 12 - Tela de Login37
Figura 13 - Tela de Vendas do Caixa37
Figura 14 - Tela de Buscas de Produtos e Códigos38
Figura 15 - Tela inicial do Administrador39
Figura 16 - Tela de cadastro e edição dos usuários39
Figura 17 - Tela de edição de preço e quantidade dos Produtos40
Figura 18 - Tela de cadastro de novos Produtos41
Figura 19 - Tela de cadastro de novas Marcas41
Figura 20 - Janela de Estorno de Produtos42

LISTA DE FIGURAS Figura 21 - Modelo do Cupom Fiscal ....................................................................................... 42

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

INTRODUÇÃO10
1. ENGENHARIA DE SOFTWARE E UML13
1.1. Engenharia de Software: uma visão geral13
1.2. Ciclo de vida de um Software19
1.2.1. Os vários tipos de ciclos de vida19
1.2.2. Prototipação23
1.3. UML e seus diagramas25
1.3.1. Documento Visão26
1.3.2. Diagrama de Caso de Uso27
1.3.3. Diagrama de Classes27
1.3.4. Banco de dados - MER Modelo Entidade Relacionamento28
1.4. Considerações Finais29
2. DESENVOLVIMENTO DA APLICAÇÃO30
2.1. Descrição breve do ramo de negócio da empresa30
2.2. As pessoas envolvidas (usuários)30
2.3. Tecnologias utilizadas31
2.3.1. Linguagem de programação31
2.3.2. Servidor e banco de dados31
2.4. UML32
2.4.1. Documento Visão32
2.4.2. Diagrama de Caso de Uso3
2.4.3. Diagrama de Classes35
2.4.4. O MER – Modelo Entidade Relacionamento35
2.3.5. Interfaces do Sistema36
2.5. Status do sistema e funcionalidades43
2.6. Dificuldades encontradas43
2.7. Considerações finais4
3. CONCLUSÃO E TRABALHOS FUTUROS45

SUMÁRIO 4. REFERÊNCIAS BIBLIOGRÁFICAS ............................................................................. 46

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.

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.

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. 1) é 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.

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.

“está muito bom, mas poderia mudar isso e isso”

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

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

(Parte 1 de 5)

Comentários