




















Estude fácil! Tem muito documento disponível na Docsity
Ganhe pontos ajudando outros esrudantes ou compre um plano Premium
Prepare-se para as provas
Estude fácil! Tem muito documento disponível na Docsity
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
Prepare-se com as videoaulas e exercícios resolvidos criados a partir da grade da sua Universidade
Responda perguntas de provas passadas e avalie sua preparação.
Ganhe pontos para baixar
Ganhe pontos ajudando outros esrudantes ou compre um plano Premium
Projeto de Software
Tipologia: Notas de estudo
1 / 28
Esta página não é visível na pré-visualização
Não perca as partes importantes!





















© 2012 Gledson Leite Leal, Melissa Simões, Rafael Martins Alves, Rodrigo Martins Alves
© 2012 Gledson Leite Leal, Melissa Simões, Rafael Martins Alves, Rodrigo Martins Alves ................................................................................................................................... 18 1 Ferramentas utilizadas (IDEs, compiladores, ...) no
- Parte I Introdução Índice - Parte II Requisitos de software - 1 Problema abordado - 2 Análise do problema/negócio................................................................................................................................... - 3 Especificação de requisitos................................................................................................................................... - 4 Requisitos funcionais e não-funcionais................................................................................................................................... - Parte III Desenho (projeto) de software - 1 Diagrama de caso de Uso - 2 Diagrama de sequência................................................................................................................................... - 3 Diagrama de banco de dados................................................................................................................................... - 4 Diagrama de classes................................................................................................................................... 4 Trabalho de Engenharia de Software
© 2012 Gledson Leite Leal, Melissa Simões, Rafael Martins Alves, Rodrigo Martins Alves
Este trabalho faz parte da disciplina de Engenharia de Software ministrado pelo professor Carlos Michel Betemps.
O trabalho consiste no desenvolvimento de uma aplicação prática, dos assuntos abordado em sala de aula. Pelo qual desenvolvemos uma ferramenta de auxílio de projeto de cabines de tratores, neste se trata de um aplicativo para consulta das informações cadastradas na base de dados, onde todo o relacionamento das tabelas do banco de dados já foram definidas necessitando a consulta das informações cadastrada e sua impressão na tela do usuário.
8 Trabalho de Engenharia de Software
© 2012 Gledson Leite Leal, Melissa Simões, Rafael Martins Alves, Rodrigo Martins Alves
Desenho referente ao diagrama do software que são: diagrama de caso de uso, diagrama de seguência, diagrama de banco de dados e diagrama de classe.
Segundo Bezerra (2007, p. 53), “o modelo de caso de uso é a representação das funcionalidades externamente observáveis do sistema e dos elementos externos ao sistema que interagem com ele”. Este modelo é parte integrante da especificação de requisitos. Na verdade, o modelo de Caso de Uso molda os requisitos funcionais do sistema. Esse diagrama foi idealizado pelo engenheiro de software sueco, Ivar Jacobson na década de 1970, enquanto trabalhava no desenvolvimento de um sistema na empresa Ericson. Esse diagrama, embora usado com bastante intensidade nas etapas iniciais do processo de desenvolvimento de software, permeia praticamente todo esse processo, nesse sentido FOWLER (2000) relata que os diagramas de Caso de Uso dirigem todo o processo de desenvolvimento, eles fornecem a base da comunicação entre clientes e desenvolvedores no planejamento do projeto.
Segue o diagrama de caso de uso do projeto elaborado.
10 Trabalho de Engenharia de Software
© 2012 Gledson Leite Leal, Melissa Simões, Rafael Martins Alves, Rodrigo Martins Alves
Diagrama de sequência (ou Diagrama de Sequência de Mensagens) é um diagrama usado em UML (Unified Modeling Language), representando a sequência de processos (mais especificamente, de mensagens passadas entre objectos) num programa de computador. Como um projecto pode ter uma grande quantidade de métodos em classes diferentes, pode ser difícil determinar a sequência global do comportamento. O diagrama de sequência representa essa informação de uma forma simples e lógica.
Segue o diagram de sequência do projeto desenvolvido.
Figura 2 - Diagram a de sequência
Através deste diagrama poderemos representar, de forma sucinta e bem estruturada, todos os elementos essenciais abstraídos no processo de análise de sistemas. Denominamos entidade (retângulo) estes elementos. Atribuímos a cada entidade definida atributos pertinentes ao sistema. Desta forma, podemos definir conceitualmente que representaremos como entidades aqueles elementos no qual gostaríamos de armazenar dados – que por sua vez, são representados pelos atributos. Através do relacionamento (losango) representaremos o tipo de relação existente entre as entidades.
Desenho (projeto) de software 11
© 2012 Gledson Leite Leal, Melissa Simões, Rafael Martins Alves, Rodrigo Martins Alves
Segue o diagrama do bando de dados.
Figura 3 - Diagram a do anco de dados
O diagrama de classes representa a estrutura do sistema, recorrendo ao conceito de classe e suas relações. O modelo de classes resulta de um processo de abstracção onde são identificados os objectos relevantes do sistema em estudo. Um objecto é uma ocorrência que tem interesse para o sistema em estudo e que se pretende descrever no seu ambiente, contendo identidade e comportamento. O comportamento de um objecto define o modo como ele age e reage a estímulos externos e a identidade de um objecto é um atributo que o distingue de todos os demais, sendo preservada quando o seu estado muda. Um objecto não é mais do que uma instância da classe.
Segue o diagrama de classe aplicado com o Template Method:
14 Trabalho de Engenharia de Software
© 2012 Gledson Leite Leal, Melissa Simões, Rafael Martins Alves, Rodrigo Martins Alves
Nesta seção está as informações da implementação do software.
O website está subdividido em pastas, onde cada pasta contem uma coleção de arquivos que tem algum relacionamento entre eles, isso permite ter facilidade de busca de erro, melhor manutenção dos códigos, tudo isso trás uma maior organização da estrutura do software.
Os códigos foram documentados para que se possa ter uma maior compreensão do algoritmo empregado e descrisão das variáveis utilizadas que auxiliam terceiros que vão dar manutenção no software, tem uma maior rapidez de compreensão do código do programa.
Para criação do layout do software utilizou se folhas de estilo CSS que são Folhas de estilos em cascata — Cascading Style Sheets (CSS) — é uma ferramenta para construção do layout dos seus websites. Permite que projete websites com uma técnica completamente diferente da convencional e possibilita uma considerável redução de tempo de trabalho.
Utilizou-se o máximo possível de componentes que ajudou na agilização da programação, como o exemplo classes prontas para conexão em mysql que auxiliou na organição do software e na implementação do mesmo.
Para a documentação do software utilizou se diagramas UML que permite a descrição do programa graficamente a partir de vários elementos gráficos, isso auxilia a busca rápida de problemas e no compreende mento do sistema. Um elemento gráfico utilizado foi a especificação da arquitetura do banco de dados que foi criada apartir do DBDesigner, esse ferramenta permite fazer a relações das tabelas do banco de dados e gerar script sql para a criação do mesmo.
16 Trabalho de Engenharia de Software
© 2012 Gledson Leite Leal, Melissa Simões, Rafael Martins Alves, Rodrigo Martins Alves
Nesta seção está especificado as informações de teste de software.
No desenvolvimento do projeto foi verificado os componentes essenciais da arquitetura de modo a validar esses para o funcionamento básico da plataforma. Os planos de testes se manteve no desenvolvimento do software debugando os componentes para encontrar eventuais falhas e corrigir componentes mal programado. Após o desenvolvimento, componentes do grupo fez testes aleatório criado pelo mesmo de modo a averiguá-la a operação estável do sistema.
Os casos de teste foram simular consultas disponíveis, onde os casos de testes mantiveram em efetuar as operações disponíveis na plataforma que são as consultas nas tabelas de projeto, necessidade do cliente, normas de requisitos de projeto e requisitos de projeto.
Foi executado teste de validação onde foi possível mostrar ao grupo, que o aplicativo executou as operações desejada na parte de requisitos. Ou seja o teste mostrou que o sistema opera conforme pretendido.
Foi executado teste de defeito onde foi possível descobrir defeitos no software em onde foi possível expor o defeito no sistema.
O teste de caixa preta determinou oque entrada e oque sai no sistema onde foram conforme as entradas com suas respectivas saídas.
Resultado de teste foram os resultados da operação que foram os resultado da consulta e alguns erros.
Aspectos gerencias de desenvolvimento de software 19
© 2012 Gledson Leite Leal, Melissa Simões, Rafael Martins Alves, Rodrigo Martins Alves
gratuita. Mas por essas limitações, a linguagem é muito versátil, pois trabalha orientado a objeto que permite uma maior estruturação do problema e reutilização dos códigos.
Não houve muitas reuniões, a maior parte da comunicação se dava por emails, apenas nos espaços concedidos em aula que havia uma discussão do que ainda se faltava fazer e alguma descoberta referente ao tema que nós abordamos. E definido isso, cada um estudou e escreveu a parte teórica referente ao projeto. Não houve a definição de um Gerente de projeto, trocamos emails e discutíamos o que deveria ser feito e o que já havia sido feito, como parte do trabalho foi feito durante a greve, usamos o tempo que tivemos na volta as aulas para discutir sobre a apresentação e desenvolvimento do projeto.