Pt - Ads - Sem 2 - Atividade em Grupo

Prévia do material em texto

�PAGE �
SUMÁRIO
31	INTRODUÇÃO	�
42	OBJETIVO	�
53	TESTE DE SOFTWARE	�
64	DIAGRAMA ENTIDADE RELACIONAMENTO	�
85	PROTÓTIPO DO SISTEMA	�
126	CASOS DE USO	�
137	CONCLUSÃO	�
14REFERÊNCIAS	�
�
ÍNDICE DE IMAGENS
6Figura 1 - DER (Módelo Lógico)	�
7Figura 2 - DER (Módelo Conceitual)	�
8Figura 3 - Tela Principal do Sistema	�
8Figura 4 - Tela Principal do Sistema, mostrando as opções do menu 'Cadastro'.	�
9Figura 5 - Tela Principal do Sistema, mostrando as opções do menu 'Consultas'.	�
9Figura 6 - Tela Principal do Sistema, mostrando as opções do menu 'Utilitários'.	�
10Figura 7 - Tela para 'Cadastro de Funcionário'.	�
10Figura 8 - Tela para 'Cadastro de Livros'.	�
10Figura 9 - Tela para 'Cadastro de Cliente'.	�
11Figura 10 - Tela para 'Locação de Livros'.	�
12Figura 11 - Diagrama de Caso de Uso	�
��
INTRODUÇÃO
Com os avanços tecnológicos, a competitividade entre as empresas está cada vez maior. Com a globalização, o mercado competitivo não é mais local e sim global com isso o mercado vem exigindo das empresas maior rapidez, flexibilidade e qualidade nos serviços e nos softwares. E para que essas exigências sejam satisfeitas, é preciso uma significativa melhoria e padronização no processo de desenvolvimento de softwares. 
A busca constante na evolução do software não se faz por meio de apenas uma metodologia, mas sim uma combinação de melhores ferramentas de automação, técnicas para a garantia da qualidade do software, gerenciamento e controle das atividades envolvidas; esses são os principais objetivos da engenharia de software. A testabilidade é um processo importante que detectar erros e falhas não identificadas nos fases anteriores. 
No passado os programadores desenvolviam seus produtos de forma pessoal, por meio de técnicas próprias, que por meio da sua experiência de acertos e erros criavam seu próprio padrão. 
OBJETIVO
A TI (Tecnologia da Informação) é movida por tecnologia, desenvolvimento, rapidez, robustez e segurança. O profissional que atua nessa área deve está sempre atualizado e apto a adaptar-se a um mercado sempre em evolução. Deve conhecer os padrões, as técnicas de desenvolvimento de software para que possa usar o melhor de cada técnica em um determinado projeto.
O presente trabalho tem como objetivos os seguintes aspectos:
• 	Conhecer o processo de testabilidade de software e definir uma política de teste;
• Através da ferramenta BrModelo será construída o diagrama Entidade Relacionamento;
•	A construção do Protótipo do sistema para locação de livros;
•	A Identificação dos Casos de usos, atores e herança;
teste de software
Uma boa política de testes deve envolver tanto testes de baixo nível, que verificam se uma pequena parte do código fonte foi corretamente implementada, quanto testes de alto nível, que validam unções do sistema relativas aos requisitos do cliente. Pode ser dividida em quatro fases:
Teste de Unidade: Uma unidade é a menor porção de um software que pode ser executada. O teste de unidade verifica se uma porção do código executa adequadamente a sua funcionalidade, isoladamente do resto do sistema. Por isso, geralmente o caso de teste faz uso de drivers e stubs. Um driver é um elemento (classe, programa principal ou software externo) que aplica os casos de teste à unidade sob teste. O driver é responsável por fornecer os dados de entrada, coletar os dados de saída e apresentá-los ao usuário. Um stub é um pedaço de código usado para substituir módulos necessários para a execução daunidade, simulando seu comportamento. A utilização de drivers e stubs possibilita que a unidade seja testada isoladamente.
Teste de Componente: Um componente é integração de diversas unidades, com interfaces bem definidas. Nesta fase o componente é testado de acordo com a especificação das funcionalidades e de sua estrutura. Também podem ser necessários drivers e stubs.
Teste de Integração: Nesta fase os componentes são integrados, e os casos de teste são direcionados à descoberta de erros arquiteturais, relacionados às interfaces dos componentes. A integração pode se dar com o uso de uma abordagem big-bang, na qual todos os componentes são integrados de uma só vez, dispensando,o uso de drivers e stubs, mas dificultando a localização de falhas. O mais recomendado é,portanto, o uso de uma abordagem incremental, na qual os componentes são integrados pouco a pouco. O uso de drivers e stubs pode ser necessário neste caso. Testes de integração reutilizam casos de testes gerados durante as fases de teste anteriores para verificar se o novo componente integrado não afeta os demais.
Teste de Sistema: Nesta fase todo o sistema é integrado, incluindo outros sistemas, hardware, etc. São testados todas as funcionalidades propostas na especificação do sistema, bem como seus atributos requeridos para qualidade, segurança, desempenho e confiabilidade.
diagrama entidade relacionamento
Uma locadora de livros deve ter um controle principal sobre seus clientes como também sobre os livros que possuem em estoque. Na cardinalidade entre as entidades clientes e livros dentro de um sistema de controle de locação, podemos afirmar que um cliente pode locar um ou mais livros, como também pode não locar nenhum e continuar sendo cliente. Já um livro não pode ser locado por mais de um cliente ao mesmo tempo, ou seja, um livro pose ser alugado apenas para um cliente. Um funcionário controla todos os livros e clientes da locadora.
Portanto a cardinalidade entre as entidades clientes e livros, conforme demonstrada via diagrama abaixo, fica um cliente para zero, um ou mais de um livro para um cliente.
Figura 1 - DER (Módelo Lógico)
Figura 2 - DER (Módelo Conceitual)
protótipo do sistema
Após análise dos diagramas do banco de dados, foi elaborado um protótipo para que o cliente possa entender como funcionará o sistema. Abaixo, observaremos as telas desse protótipo.
Figura 3 - Tela Principal do Sistema
Figura 4 - Tela Principal do Sistema, mostrando as opções do menu 'Cadastro'.
Figura 5 - Tela Principal do Sistema, mostrando as opções do menu 'Consultas'.
Figura 6 - Tela Principal do Sistema, mostrando as opções do menu 'Utilitários'.
Figura 7 - Tela para 'Cadastro de Funcionário'.
Figura 8 - Tela para 'Cadastro de Livros'.
Figura 9 - Tela para 'Cadastro de Cliente'.
Figura 10 - Tela para 'Locação de Livros'.
CASOS DE USO
Um diagrama de caso de uso mostra de que forma os casos de uso estão correlacionados uns com os outros
No cenário “Nossa Locadora de Livros”, identificamos como casos de uso: Cadastrar Funcionário, Cadastrar Cliente, Cadastrar Livro, Locar Livro. Os atores são representados pelo Diretor, os Funcionários e os Clientes. Percebemos também que o Diretor herda todas as funções dos funcionários e algumas outras exclusivas do seu cargo. 
A imagem abaixo mostra o Diagrama de Caso de Uso referente ao cenário proposto.
Figura 11 - Diagrama de Caso de Uso
conclusão
O presente trabalho nos proporcionou entendimento sobre análise de sistemas, processos de desenvolvimento de softwares, qualidade e padronização no desenvolvimento de softwares, orientação a objetos, banco de dados e SGBD. Conhecer cada processo de desenvolvimento de software, cascata, prototipação, espiral entre outros, saber diferenciar cada método e aplica-lo conforme o projeto.
 Com o estudo de caso “Nossa Locadora de Livros” podemos colocar em prática o conteúdo estudado nas disciplinas analisando e discutindo os métodos no processo de desenvolvimento de softwares que melhor atende o projeto.
Toda a discussão que este trabalho envolve faz o paliativo sobre como se comporta o mercado de desenvolvimento de softwares, que a cada dia, exigeum profissional que tenha muito mais que conhecimento técnico, que tenha um conhecimento amplo da organização, padronização, linguagens e gerência. Profissional esse, que crie alternativas e encontre soluções de software, para os problemas dos clientes. Além de saber analisar e entender o que o cliente realmente está necessitando: que entenda o cliente. 
REFERÊNCIAS
BEZERRA, Eduardo. Princípios de Análise e Projeto de Sistemas com UML. 2a ed., Elsevier, 2007.
ELMASRI, Ramez E., NAVATHE, Shamkant B.  Sistemas de Banco de Dados – Fundamentos e Aplicações. 6.ed. São Paulo: Pearson, 2011.
LIMA, Edwin; REIS, Eugênio. C# e .NET – Guia do Desenvolvedor; 1. ed. Rio de Janeiro: Campos, 2002.
TANAKA, Simone Sawasaki. Análise de Sistemas I. São Paulo: Pearson Prentice Hall, 2009.
Um Processo para Testes de Sistemas com Reuso de Componentes. UNICAMP. Disponível emhttp://www.ic.unicamp.br/~reltech/2006/06-21.pdf. Acessado em 29 de outubro de 2012.
Fases de Teste. UNICAMP. Disponível em http://www.ic.unicamp.br/~ranido/mc626/FasesTestes.pdf. Acessado em 30 de outubro de 2012.
Sistema de Ensino Presencial Conectado
ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
ANTÔNIO JOHNYSLEI SAMPAIO
charles lindemberg albuquerque lima
francisco wótila carneiro cruz
gean viana rodrigues
josé vidal de araújo
produção textual
Em Grupo
Sobral
2012
ANTÔNIO JOHNYSLEI SAMPAIO
charles lindemberg albuquerque lima
francisco wótila carneiro cruz
gean viana rodrigues
josé vidal de araújo
produção textuaL
Em Grupo
Trabalho apresentado à Universidade Norte do Paraná - UNOPAR, como requisito parcial para a obtenção de média semestral nas disciplinas de Análise de Sistemas I, Banco de Dados I, Engenharia de Software. Linguagens e Técnicas de Programação II e Seminário II.
Orientadores: Profa.. Polyanna Gomes, Prof. Roberto Nishimura, Prof. Luis Cláudio Perini e Prof. Anderson Gonçalves.
Sobral
2012