Docsity
Docsity

Prepare-se para as provas
Prepare-se para as provas

Estude fácil! Tem muito documento disponível na Docsity


Ganhe pontos para baixar
Ganhe pontos para baixar

Ganhe pontos ajudando outros esrudantes ou compre um plano Premium


Guias e Dicas
Guias e Dicas


Projeto de Software, Notas de estudo de Cultura

Projeto de Software

Tipologia: Notas de estudo

2012

Compartilhado em 19/11/2012

gledson-leite-leal-11
gledson-leite-leal-11 🇧🇷

5

(3)

2 documentos

1 / 28

Toggle sidebar

Esta página não é visível na pré-visualização

Não perca as partes importantes!

bg1
© 2012 Gledson Leite Leal, Melissa Simões, Rafael Martins Alves, Rodrigo Martins Alves
Trabalho de Engenharia
de Software
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19
pf1a
pf1b
pf1c

Pré-visualização parcial do texto

Baixe Projeto de Software e outras Notas de estudo em PDF para Cultura, somente na Docsity!

© 2012 Gledson Leite Leal, Melissa Simões, Rafael Martins Alves, Rodrigo Martins Alves

Trabalho de Engenharia

de Software

2 Trabalho de Engenharia de Software

© 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................................................................................................................................... 
  • Parte IV Implementação de software - 1 Como está agrupado o código referente ao projeto - 2 Padrão de documentação................................................................................................................................... - Parte V Teste de software - 1 Teste de software - software Parte VI Aspectos gerencias de desenvolvimento de - 2 Descrição desenvolvimento das atividades................................................................................................................................... desenvolvimento do projeto
  • Parte VII Telas do aplicativo - 1 Tela Inicial - 2 Consultar projeto................................................................................................................................... - 3 Seleção de tipo de informação................................................................................................................................... - 4 Necessidade do cliente................................................................................................................................... - 5 Requisitos dos clientes................................................................................................................................... - 6 Normas requisitos projeto................................................................................................................................... - 7 Consultar influência no projeto................................................................................................................................... - 8 Consultar influência no projeto (Todos Requisitos)................................................................................................................................... - 9 Consultar influência no projeto (Filtrar por categoria)...................................................................................................................................

4 Trabalho de Engenharia de Software

© 2012 Gledson Leite Leal, Melissa Simões, Rafael Martins Alves, Rodrigo Martins Alves

1 Introdução

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.

Parte

II

Parte

III

8 Trabalho de Engenharia de Software

© 2012 Gledson Leite Leal, Melissa Simões, Rafael Martins Alves, Rodrigo Martins Alves

3 Desenho (projeto) de software

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.

3.1 Diagrama de caso de Uso

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

3.2 Diagrama de sequência

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

3.3 Diagrama de banco de dados

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

3.4 Diagrama de classes

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:

Parte

IV

14 Trabalho de Engenharia de Software

© 2012 Gledson Leite Leal, Melissa Simões, Rafael Martins Alves, Rodrigo Martins Alves

4 Implementação de software

Nesta seção está as informações da implementação do software.

4.1 Como está agrupado o código referente ao projeto

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.

4.2 Padrão de documentação

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

5 Teste de software

Nesta seção está especificado as informações de teste de software.

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

Parte

VI

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.

6.2 Descrição desenvolvimento das atividades

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.

Parte

VII