TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS

IOLANDA LIMA QUEIROZORLANDO DE OLIVEIRA LIMA

PRODUÇÃO TEXTUAL INTERDISCIPLINAR EM GRUPO

Gurupi - TO2012

IOLANDA LIMA QUEIROZORLANDO DE OLIVEIRA LIMA

PRODUÇÃO TEXTUAL INTERDISCIPLINAR EM GRUPO

Trabalho de Análise e desenvolvimento de sistemas apresentado à Universidade Norte do Paraná - UNOPAR, como requisito parcial para a obtenção da média Semestral na disciplina de Análise de Sistema I,Engenharia de Software, Banco de Dados I, Linguagens e Técnicas de Programação II.

Orientação: Prof.ªPolyanna P. Gomes FabrisProf. Luis Cláudio PeriniProf.ª Roberto NishimuraProf. Anderson Macedo

Gurupi – TO2012

SUMÁRIO

1 INTRODUÇÃO........................................................................................................1

2 OBJETIVO .............................................................................................................1

3 DESENVOLVIMENTO............................................................................................2

3.1Engenharia de Requisitos...................................................................................................................2

3.2 Modelos de Processo de Software......................................................................................................................2

3.3 Testes de Software.......................................................................................................................3

3.4 Qualidades de Software.......................................................................................................................7

3.5 Requisitos funcionais e não funcionais do sistema “Nossa Locadora de Livros”..........................................................................................................................9

3.6 Diagramas Caso de Uso............................................................................................................................11

3.7Projetos de Banco de Dados........................................................................................................................12

3.8 Modelagens do Banco de Dados........................................................................................................................13

3.9 Protótipos das Telas..........................................................................................................................16

3.10 Privilégios de Administrador............................................................................................................18

3.10.1 Privilégios de Usuários Comum.......................................................................................................................19

4 CONCLUSÃO.........................................................................................................19

5 REFERÊNCIAS BIBLIOGRÁFICA.........................................................................21

1 INTRODUÇÃO

Todos os dias o mundo passa por mudanças. Em nosso dia-a-dia não é

diferente. Lidamos com tecnologia a todo o momento, que para nós, são muito úteis

sem as quais já não sabemos viver, nos tornando muito dependentes das mesmas.

A revolução digital está presente em nosso dia-a-dia, em tudo o que fazemos,

estamos envolvidos com a tecnologia. E as empresas estão se utilizando desta

ferramenta, para sua organização, para melhorar a sua comunicação interna e

externa, seu planejamento e atitudes perante o mercado de atuação. Visando suprir

as necessidades e desejos de seus clientes. É comprovado que hoje a comunicação

está bem mais rápida e mais fácil com a era digital. A velocidade com que você tem

acesso à informação,  a rapidez na troca de informações. Facilitando o desempenho

da Comunicação “Empresarial”, e suas estratégias e ações. É necessário se utilizar

bem desta ferramenta, não tem como nos dias de hoje ficar sem. A era digital, está

em toda parte por menor que seja a sua área de atuação, ou seu foco “negócio”.

2 OBJETIVO

O objetivo desse trabalho é fazer com que nós alunos, possamos ter um

conhecimento aprimorado de como é importante o uso de tais tecnologias no

desenvolvimento de softwares, e entendendo como funciona o processo de

qualidade desses softwares, mostraremos ainda como funciona a elaboração de um

plano de desenvolvimento de software com base na qualidade, ou seja, vários

conceitos e práticas da Engenharia de Software que atuam de forma importante na

produção de um software de qualidade. Neste projeto utilizaremos a ferramenta

Astah na criação do diagrama de caso de uso do sistema da locadora de livros, o Br

modelo na criação do banco de dados conceitual e lógico desse sistema e ainda a

linguagem C# nos ajudará na criação das telas .

1

3 DESENVOLVIMENTO

3.1 Engenharia de Requisitos

A engenharia de requisitos (no contexto da engenharia de software) é um

processo que engloba todas as atividades que contribuem para a produção de um

documento de requisitos e sua manutenção ao longo do tempo.

Este processo deve ser precedido de estudos de viabilidade que, a partir das

restrições do projeto, determinam se este é ou não viável e se deve prosseguir para

a identificação dos requisitos.

O processo de engenharia de requisitos é composto por quatro atividades de

alto nível (Soares, 2005):

Identificação;

Análise e negociação;

Especificação e documentação;

Validação.

Outra atividade que se pode considerar que faz também parte deste

processo, se incluir a fase posterior à produção do documento (isto é, a sua

"manutenção"), é a gestão dos requisitos (change management, sendo que as

alterações podem ser causa pelos mais diversos fatores desde inovações

tecnológicas a mudanças na natureza do negócio (e conseqüentemente nos

requisitos), entre outras.

3.2 Modelos de Processo de Software

É de extrema importância que antes do desenvolvimento de um produto,

deve-se preparar um plano geral, ou seja, escolher um modelo de ciclo de vida. Este

pode ser personalizado, se adaptando ao tamanho, complexidade e/ou nível de

confiabilidade/segurança do projeto, ou seja, um modelo para um processo de

desenvolvimento é uma proposta teórica que junto com o planejamento deve

determinar quais atividades devem ser realizadas, quando, como e por quem. A

escolha de um modelo envolve diversos fatores: se é um software de banco de

2

dados, um software de tempo real, um software embutido, um sistema especialista.

Outros fatores importantes são: se a equipe de desenvolvimento é uma empresa de

desenvolvimento (software house), uma fábrica de software (desenvolvimento em

linha de produção) ou se é a equipe de engenheiros da própria organização que

utilizará o produto. A maneira como o produto será vendido e instalado também tem

relevância: se o software é para ser vendido para um público amplo (software

genérico) ou se será instalado em uma única empresa, sob encomenda. São alguns

exemplos de modelos: Prototipação, Espiral, Cascata, Extrem e Programming,

SCRUM, RUP.

3.3 Testes de Software

O teste do software é como se fosse basicamente uma espécie de

investigação do software do qual se é possível fornecer informações sobre sua

qualidade em relação ao contexto em que ele deve operar. Isso inclui o processo de

utilizar o produto para encontrar seus defeitos.

O teste é um processo realizado pelo testador de software, que permeia

outros processos da engenharia de software, e que envolve ações que vão do

levantamento de requisitos até a execução do teste propriamente dito, pois desta

forma não se pode garantir que todo software funcione corretamente, sem a

presença de erros ,visto que os mesmos muitas vezes possuem um grande número

de estados com fórmulas, atividades e algoritmos complexos. O tamanho do projeto

a ser desenvolvido e a quantidade de pessoas envolvidas no processo aumentam

ainda mais a complexidade. Idealmente, toda permutação possível do software

deveria ser testada. Entretanto, isso se torna impossível para a ampla maioria dos

casos devido à quantidade impraticável de possibilidades. A qualidade do teste

acaba se relacionando à qualidade dos profissionais envolvidos em filtrar as

permutações relevantes, pois a maioria das falhas pode ser originada por diversos

motivos. Por exemplo, a especificação pode estar errada ou incompleta, ou pode

conter requisitos impossíveis de serem implementado, devido a limitações de

hardware ou software. A implementação também pode estar errada ou incompleta,

como um erro de um algoritmo. Portanto, uma falha é o resultado de um ou mais

defeitos em algum aspecto do sistema.

3

O teste de software pode ser visto como uma parcela do processo de

qualidade de software. A qualidade da aplicação pode, e normalmente, varia

significativamente de sistema para sistema. Os atributos qualitativos previstos na

norma ISO 9126 são funcionalidade, confiabilidade, usabilidade, eficiência,

manutenção e portabilidade. De forma geral, mensurar o bom funcionamento de um

software envolve compará-lo com elementos como especificações, outros softwares

da mesma linha, versões anteriores do mesmo produto, inferências pessoais,

expectativas do cliente, normas relevantes, leis aplicáveis, entre outros. Enquanto a

especificação do software diz respeito ao processo de verificação do software, a

expectativa do cliente diz respeito ao processo de validação do software.

Um desenvolvimento de software organizado tem como premissa uma

metodologia de trabalho. Esta deve ter como base conceitos que visem à construção

de um produto de software de forma eficaz. Dentro desta metodologia estão

definidos os passos necessários para chegar ao produto final esperado.

Assim, quando se segue uma metodologia para o desenvolvimento de um

produto de software, espera-se um produto final que melhor agrade tanto aos

clientes quanto ao próprio fornecedor, ou seja, a empresa de desenvolvimento.

Observando este aspecto, não faz sentido iniciar a construção de um produto de

software sem ter uma metodologia de trabalho bem solidificada e que seja do

conhecimento de todos os envolvidos no processo. Porém, além de uma crescente

demanda por softwares de qualidade, as empresas de desenvolvimento de software

sofrem cada vez mais pressão por parte dos clientes para que o produto seja

entregue num curto período de tempo. Este fato pode fazer com que uma sólida

metodologia de trabalho acabe por se desequilibrar.

Independentemente da metodologia de trabalho empregada no

desenvolvimento de um software, para que se obtenha um produto final com certo

nível de qualidade é imprescindível a melhoria dos processos de engenharia de

software.

Uma maneira viável para se assegurar a melhoria de tais processos seria

tomar como base modelos sugerido por entidades internacionais respeitadas no

assunto. Dentro de uma gama de modelos, sejam eles para situações e ambientes

específicos ou para soluções genéricas, existem alguns que são mais utilizados e

4

tidos como eficientes, como por exemplo, os SW-CMM, SE-CMM, ISO/IEC_15504 e

o mais conhecido CMMI.

Outro fator com grande influência sobre a qualidade do software a ser

produzido é o que diz respeito aos testes que serão executados sobre tal produto.

Todas as metodologias de desenvolvimento de software têm uma disciplina

dedicada aos testes. Atualmente esta é uma tarefa indispensável, porém muitas

vezes efetuada de maneira ineficiente, seja pelo subestimar dos que desenvolvem,

pela falta de tempo ou mesmo pela falta de recursos humanos e financeiros.

De acordo com um estudo conduzido pelo NIST em 2002, os defeitos

resultam num custo anual de 59,5 bilhões de dólares à economia dos Estados

Unidos. Mais de um terço do custo poderia ser evitado com melhorias na infra-

estrutura do teste de software.

Existem muitas maneiras de se testar um software. Mesmo assim, existem

as técnicas que sempre foram muito utilizadas em sistemas desenvolvidos sobre

linguagens estruturadas que ainda hoje têm grandes valia para os sistemas

orientados a objeto. Apesar de os paradigmas de desenvolvimento sere

completamente diferentes, o objetivo principal destas técnicas continua a ser o

mesmo, encontrar falhas no software. Abaixo estão descritas algumas das técnicas

mais conhecidas.

Caixa-Branca: Também chamada de teste estrutural ou orientada à

lógica, a técnica de caixa-branca avalia o comportamento interno do componente de

software. Essa técnica trabalha diretamente sobre o código fonte do componente de

software para avaliar aspectos tais como: teste de condição, teste de fluxo de dados,

teste de ciclos, teste de caminhos lógicos, códigos nunca executados.

Caixa-Preta: Também chamada de teste funcional, orientado a dado ou

orientado a entrada e saída, a técnica de caixa-preta avalia o comportamento

externo do componente de software, sem se considerar o comportamento interno do

mesmo. Dados de entrada são fornecidos, o teste é executado e o resultado obtido é

comparado a um resultado esperado previamente conhecido. Como detalhes de

implementação não são considerados, os casos de teste são todos derivados da

especificação.

5

Caixa-Cinza: A técnica de teste de caixa-cinza é um mesclado do uso

das técnicas de caixa-preta e de caixa-branca. Isso envolve ter acesso a estruturas

de dados e algoritmos do componente a fim de desenvolver os casos de teste, que

são executados como na técnica da caixa-preta. Manipular entradas de dados e

formatar a saída não é considerado caixa-cinza, pois a entrada e a saída estão

claramente fora da caixa-preta. A caixa-cinza pode incluir também o uso de

engenharia reversa para determinar, por exemplo, os limites superiores e inferiores

das classes, além de mensagens de erro.

Regressão: Essa é uma técnica de teste aplicável a uma nova versão

de software ou à necessidade de se executar um novo ciclo de teste durante o

processo de desenvolvimento. Consiste em se aplicar, a cada nova versão do

software ou a cada ciclo, todos os testes que já foram aplicados nas versões ou

ciclos de teste anteriores do sistema. Inclui-se nesse contexto a observação de

fases e técnicas de teste de acordo com o impacto de alterações provocado pela

nova versão ou ciclo de teste. Para efeito de aumento de produtividade e de

viabilidade dos testes, é recomendada a utilização de ferramentas de automação de

teste, de forma que, sobre a nova versão ou ciclo de teste, todos os testes anteriores

possam ser executados novamente com maior agilidade.

Além destas técnicas citadas há também outras técnicas de teste existentes

para testar aspectos não funcionais do software, como por exemplo, a adequação a

restrições de negócio, adequação a normas, ou restrições tecnológicas. Em

contraste às técnicas funcionais mencionadas acima, que verificam a produção pelo

sistema de respostas adequadas de suas operações, de acordo com uma

especificação, as técnicas não funcionais verificam atributos de um componente ou

sistema que não se relacionam com a funcionalidade (por exemplo, confiabilidade,

eficiência, usabilidade, manutenção e portabilidade).

Uma delas é o uso conjunto de teste de desempenho e teste de carga, que

verifica se o software consegue processar grandes quantidades de dados, e nas

especificações de tempo de processamento exigidas, o que determina a escala do

software. O teste de usabilidade é necessário para verificar se a interface de usuário

é fácil de aprender e utilizar. Entre verificações cabíveis estão à relação da interface

6

com conhecimento do usuário, a compreensibilidade das mensagens de erro e a

integridade visual entre diferentes componentes. Já o teste de confiabilidade é

usado para verificar se o software é seguro em assegurar o sigilo dos dados

armazenados e processados. O teste de recuperação é usado para verificar a

robustez do software em retornar a um estado estável de execução após estar em

um estado de falha.

Uma prática comum é testar o software após uma funcionalidade ser

desenvolvida, e antes dela ser implantada no cliente, por um grupo de profissionais

diferente da implementação. Essa prática pode resultar na fase de teste ser usada

para compensar atrasos do projeto, comprometendo o tempo devotado ao teste.

Outra prática é começar o teste no mesmo momento que o projeto, num processo

contínuo até o fim do projeto.

Em contrapartida, algumas práticas emergentes como a programação

extrema e o desenvolvimento ágil focam o modelo de desenvolvimento orientado ao

teste. Nesse processo, os testes de unidade são escritos primeiro (TDD), por

engenheiros de software. Antes da implementação da unidade em questão, o teste

falha. Então o código é escrito, passando incremental mente em porções maiores

dos casos de teste. Os testes são mantidos junto com o resto do código fonte do

software, e geralmente também integra o processo de construção do software.

3.4 Qualidades de Software

A qualidade de software é uma área de conhecimento da engenharia de

software que objetiva garantir a qualidade do software através da definição e

normatização de processos de desenvolvimento. Apesar dos modelos aplicados na

garantia da qualidade de software atuar principalmente no processo, o principal

objetivo é garantir um produto final que satisfaça às expectativas do cliente, dentro

daquilo que foi acordado inicialmente.

Segundo a norma ISO 9000 (versão 2000), a qualidade é o grau em que um

conjunto de características inerentes a um produto, processo ou sistema cumpre os

requisitos inicialmente estipulados para estes.

No desenvolvimento de software, a qualidade do produto está diretamente

relacionada à qualidade do processo de desenvolvimento, desta forma, é comum

7

que a busca por um software de maior qualidade passe necessariamente por uma

melhoria no processo de desenvolvimento.

Rodney Brooks, diretor do Laboratório de Inteligência Artificial e Ciência da

Computação do MIT, define qualidade como a conformidade aos requisitos. Essa

((definição exige determinar dois pontos: I) o que se entende por conformidade; e II)

como são especificados - e por quem - os requisitos.

Em dois artigos recentes, David Chappell, CEO da Chappell & Associates,

descreve os diferentes aspectos de qualidade de software (funcionais, estruturais e

de processo), os grupos de pessoas diretamente interessadas na qualidade

(usuários, desenvolvedores e patrocinadores), e o resultado que os defeitos no

software causam, sejam eles externos ou internos, ao longo do tempo.

No artigo Os Três Aspectos da Qualidade de Software: funcionais estruturais

e de processo (PDF), Chappell apresenta três aspectos da qualidade de um

software: funcional, estrutural e de processo, onde cada um está relacionado de

alguma forma aos três grupos de pessoas diretamente interessadas no produto final

ou serviço: usuários, desenvolvedores e patrocinadores.

Qualidade funcional expressa o quão bem o software executa as tarefas

solicitadas por seus usuários. Chappell distingue quatro atributos desse tipo de

qualidade de software:

O software atende aos requisitos especificados

Possui poucos defeitos

Possui um desempenho razoável

É fácil de aprender e de usar

A Qualidade estrutural mede o quão bem o software é organizado, sendo

definida pelos seguintes atributos:

Testabilidade do código

Manutenibilidade - facilidade para realizar manutenção do código

Clareza - facilidade em se entender o código

Eficiência do código - gerencia os recursos (memória, conexões de

rede) eficientemente?

Segurança do código - é capaz de impedir as ameaças de segurança

mais comuns?

8

Enquanto a qualidade funcional e a estrutural "recebem a fatia do leão nas

discussões sobre qualidade de software", Chappell considera que a qualidade do

processo também é muito importante, em que seus principais atributos são:

As datas de entrega são cumpridas?

Está dentro do orçamento?

Há um processo de desenvolvimento de software replicável? Um que

entregue software de qualidade de forma confiável e previsível?

Chappell acredita que os usuários estão mais interessados em qualidade

funcional, e possuem algum interesse no atributo "datas de entrega" da qualidade do

processo. Já os desenvolvedores se importam principalmente quanto a qualidade

estrutural, porque este item possui um impacto direto no resultado do seu próprio

trabalho, mas também estão interessados em qualidade funcional, só que não tanto

quanto os usuários, e na qualidade do processo porque "fornece muitas das

métricas com as quais o seu trabalho é medido". Já os patrocinadores de um projeto

devem se preocupar com todos os aspectos de qualidade de um software, cientes

de que cada aspecto tem um impacto importante sobre os resultados finais.

3.5 Requisitos funcionais e não funcionais do sistema “Nossa Locadora de

Livros”

Os requisitos são as características e restrições do produto de software do

ponto de vista de satisfação das necessidades do usuário, e, em geral independente

da tecnologia empregada na construção da solução sendo a parte mais crítica e

propensa a erros no desenvolvimento de software. São objetivos ou restrições

estabelecidas por clientes e usuários do sistema que definem as diversas

propriedades da solução. Os requisitos de software são, obviamente, aqueles dentre

os requisitos de sistema que dizem respeito a propriedades do software

tradicionalmente, os requisitos de software são separados em requisitos funcionais e

não funcionais.

Funcionais: São a descrição das diversas funções que clientes e

usuários querem ou precisam que o software faça. Eles definem a funcionalidade

desejada do software. A especificação de um requisito funcional deve determinar o

que se espera que o software faça, sem a preocupação de como ele faz.

9

Não funcionais: São as qualidades globais de um software, como

manutenção, usabilidade, desempenho, custos e várias outras. Normalmente estes

requisitos são descritos de maneira informal. Descrevem as restrições de tempo, do

processo de desenvolvimento, padrões e etc. Geralmente, são mais críticos do que

os funcionais e se ignorados, podem transformar todo o sistema em algo inútil.

Os requisitos funcionais do sistema “Nossa Locadora de Livros” leva em

consideração os seguintes itens:

O sistema deve manter um cadastro de clientes;

O sistema deve prover e controlar a renovação do empréstimo de

forma on-line;

O sistema deve manter um cadastro de livros;

O sistema deve controlar e disparar avisos sobre prazos de devolução

se esgotando a seus clientes;

O sistema deve controlar o número máximo permitido de livros

emprestados por vez para cada cliente.

Já os requisitos não funcionais o sistema levará em considerações outros

detalhes como, por exemplo:

O cadastro de clientes deve ser simplificado com: nome, endereço,

telefone, e-mail e senha;

O sistema deve vetar empréstimos em caso de atraso confirmado e

avisar ao cliente que compareça à biblioteca para sanar as pendências do referido

empréstimo;

O sistema deve limitar para no máximo 03(três) exemplares, os

empréstimos por vez para cada cliente;

O sistema deverá comunicar ao cliente, via e-mail, quando faltar1 (um)

dia para se esgotar o prazo de devolução do empréstimo;

O cadastro de livros deve contemplar de forma obrigatória a localização

e a quantidade de exemplares por título.

10

3.6 Diagramas Caso de Uso

O diagrama de caso de uso serve para descrever a funcionalidade proposta

para um novo sistema, que será projetado. Segundo Ivar Jacobson, podemos dizer

que um caso de uso é um "documento narrativo que descreve a seqüência de

eventos de um ator que usa um sistema para completar um processo". Um caso de

uso representa uma unidade discreta da interação entre um usuário (humano ou

máquina) e o sistema. Um caso de uso é uma unidade de um trabalho significante.

Por exemplo: o "logimn para o sistema", "registrar no sistema" e "criar pedidos" são

todos casos de uso. Cada caso de uso tem uma descrição da funcionalidade que irá

ser construída no sistema proposto. Um caso de uso pode "usar" outra

funcionalidade de caso de uso ou "estender" outro caso de uso com seu próprio

comportamento.

Casos de uso são tipicamente relacionados a "atores". Um ator é um

humano ou entidade máquina que interage com o sistema para executar um

significante trabalho.

No Cenário o Cliente chega à locadora de livros e solicita o empréstimo. O

funcionário verifica no sistema podendo cadastrar o cliente ou efetuar o empréstimo.

O cliente de forma on-line poderá efetuar a renovação do empréstimo segundo as

regras impostas pelo sistema, bem como gerenciar suas pendências de

empréstimos. O funcionário também pode efetuar renovações e gerenciar

pendências. O funcionário mantém o cadastro dos livros informando sempre a

localização e o número de exemplares por títulos.

Os Atores são representados pelo Cliente e funcionário. Casos de uso:

manter cadastro de cliente; manter cadastro de livro; controlar empréstimos;

cadastrar localização do livro; cadastrar quantidade de volumes por título; gerenciar

pendências de empréstimos.

Na Figura 01 – mostra-se um Prt scr de todo o processo de criação do

diagrama do caso de uso usando a ferramenta ASTAH, já na figura02 é possível ver

o diagrama do caso de uso já convertido em imagem jpg.

11

Figura 01- Prt scr do diagrama de caso de uso em processo de criação.

Figura 02-diagrama de caso de uso (imagem jpg).

3.7 Projetos de Banco de Dados

Após serem feitos os levantamento dos requisitos, e já com a estrutura

definida, passaremos agora para a modelagem do nosso banco de dados. Para

entender melhor o funcionamento de um banco de dados, é importante saber que o

computador possui três tarefas básicas. São elas: entrada, processamento e saída.

A entrada dos dados está relacionada diretamente com a interação do usuário, que

na maioria das vezes é o responsável pela inserção da informação por meio de

teclado, mouse, entre outros dispositivos de entrada, com relação à saída, os dados 12

que foram informados na entrada passam pelo processamento atendendo a

expectativa do usuário e são apresentados por um dispositivo de saída, como por

exemplo, um monitor ou impressora já no caso do processamento pode definir

simplesmente como interação dos dados de entrada com a saída.

"De forma simplificada pode-se conceituar banco de dados como sendo um

sistema de armazenamento de dados baseado em computador, cujo objetivo é

registrar e manter informações consideradas significativas a qualquer organização

ou um único usuário." (DATE 1990).

3.8 Modelagens do Banco de dados

Existem dois modelos de bancos de dados; a modelagem conceitual e a

modelagem lógica, sendo que modelagem de entidades e relacionamentos onde a

finalidade é estruturar a solução descrevendo de maneira conceitual os dados que

serão utilizados em nosso sistema.

No nosso modelo conceitual foi verificada a necessidade de três tabelas

(usuário, cadlivro e emplivro) e duas relações entre elas (cadastro e empréstimo).

Na Figura 01 mostra um Prt scr do processo de criação desse modelo

conceitual para a “Nossa Locadora de Livros”.

Na Figura 02 mostra como ficou o modelo conceitual já convertido em

imagem jpg.

Figura 01-Prt scr do Br modelo Conceitual ainda em processo de criação.

13

Figura 02-Br modelo Conceitual (imagem jpg).

Já na modelagem lógica vamos dar início às regras que cada campo deve

conter, onde definiremos as principais características, informando se o

preenchimento é obrigatório ou nulo, numérico, alfanumérico, boleano, etc. Nesse

modelo, podemos compreender melhor a relação entre as tabelas USUARIO,

CADLIVRO E EMPLIVRO.

NA relação CADASTRO e a relação EMPRESTIMO, recebem duas chaves

identificadoras, cod_usuario da tabela USUARIO e cod_livro da tabela CADLIVRO.

Estas relações é que definem as ações dos usuários através do cod_usuario, qual

caminho tomar, se é para o cadastro ou somente para empréstimo.

Na Figura 03 mostra um Prt scr do processo de criação desse modelo lógico

para a “Nossa Locadora de Livros”.

Na Figura 04 mostra como ficou o modelo lógico já convertido em imagem

jpg.

14

Figura 03- modelo lógico em Prt scr – Processo de Criação.

Figura 04- Modelo lógico convertido em imagem jpg.

Os campos da tabela USUARIO foram definidos da seguinte forma:

Cod_usuário: será do tipo numérico, com valor máximo de 7digitos, com incremento

automático e será a chave primária da nossa tabela.

Nome: será do tipo alfanumérico, com no máximo 50 caracteres, com preenchimento

obrigatório.

Endereço: será do tipo alfanumérico, com no máximo 50caracteres, com

preenchimento obrigatório.

Telefone: será do tipo numérico, com no máximo 10 dígitos, com preenchimento

obrigatório.

15

E-mail: será do tipo alfanumérico, com no máximo 50 caracteres, com

preenchimento obrigatório.

Senha: será do tipo alfanumérico, com no máximo 8 caracteres, com preenchimento

obrigatório.

Já os campos da tabela CADLIVRO, foram definidos da seguinte forma:

Cod_livro: será do tipo numérico, com valor máximo de 7 dígitos, com incremento

automático e será a chave primária da nossa tabela.

Livro: será do tipo alfanumérico, com no máximo 50 caracteres, com preenchimento

obrigatório.

Quantidade: será do tipo numérico, com no máximo 3 dígitos, com preenchimento

obrigatório.

Localização: será do tipo alfanumérico, com no máximo 50caracteres, com

preenchimento obrigatório.

Para a tabela EMPLIVRO:

Cod_livro: chave estrangeira que foi importada com todas as características da

tabela LIVRO.

Cod_usuario: chave estrangeira importada da tabela USUARIO com todas as

características.

Data_emplivro: será do tipo date, com preenchimento obrigatório. Em caso de

renovação, este campo será alterado para a data atual.

3.9 Protótipos das Telas

Prototipação é uma abordagem baseada numa visão evolutiva do

desenvolvimento de software, afetando o processo como um todo. Esta abordagem

envolve a produção de versões iniciais - protótipos (análogo a maquetes para a

arquitetura) - de um sistema futuro com o qual se podem realizar verificações e

experimentos, com intuito de avaliar algumas de suas características antes que o

sistema venha realmente a ser construído, de forma definitiva.

16

No processo de prototipação é onde iremos compreender a funcionalidade

do sistema sendo que na página de autenticação o cliente que já é cadastrado vai

inserir suas credenciais, e o sistema verificará seu tipo de privilégio através do

cod_usuario.

No caso do cliente com privilégios de um administrador, este será

redirecionado para a página de cadastro de livros, onde terá outros links para

interagir com o cadastro de novos usuários além de controlar empréstimos.

A tela CADASTRAR LIVROS será apresentado assim que o usuário-

administrador informar seu login e senha. Os campos para o cadastro do livro que já

foram explicados na modelagem conceitual e lógica são obrigatórios e quando é

efetuado o cadastro de um livro a página continua a mesma dando oportunidade

para um novo cadastro.

  Figura 5– Página de cadastro de Usuário

No link Cadastrar Usuário, o administrador é redirecionado para uma nova

tela onde conterá novos campos para cadastros de um novo usuário.

Assim como no processo de cadastro do livro, quando inserido um novo

usuário, a página continua a mesma, informando através de uma mensagem na tela

que o cadastro foi efetuado com sucesso.

No link Controlar Empréstimos o administrador informará o código do

usuário que pretende gerenciar e na mesma tela retornará as informações dos

usuários junto com os livros que foram emprestados por este.

17

Figura 6- Empréstimo de Livros com a Data próxima do vencimento.

3.10 Privilégio de Administrador

No caso do cliente com privilégios de um administrador, este será

redirecionado para a página de cadastro de livros (figura 7), onde terá outros links

para interagir com o cadastro de novos clientes além de controlar

empréstimos. A tela CADASTRAR LIVROS será apresentada assim que o cliente-

administrador informar seu login e senha. Os campos para o cadastro do livro que já

foram explicados na modelagem conceitual e lógica são obrigatórios e quando é

efetuado o cadastro de um livro a página continua a mesma dando oportunidade

para um novo cadastro.

Figura 7- Privilégio de Cadastrar Livros

18

3.10.1 Privilégios de Usuário Comum

Por padrão, o nosso sistema tem o administrador e o usuário comum. O

administrador tem permissão para cadastrar e gerenciar livros e usuários. No caso

do usuário comum que foi cadastrado pelo administrador do sistema, terá acesso a

página de autenticação em comum com o administrador, mas o sistema se

encarregará de redirecioná-lo para a página de empréstimos de livros onde através

do campo pesquisa o usuário escolherá o livro que procura. Em nosso exemplo

mostramos que o usuário já fez 3 cadastros de livros e que um deles expira em 1

dia. Para este caso, o sistema fornece um link para renovar o empréstimo que está

vencendo.

Figura 7- Empréstimo de Livros com a Data vencida

Quando o usuário estiver com algum empréstimo vencido, o sistema lhe

apresenta o livro que está expirado e não permite a renovação do mesmo. Para uma

renovação do empréstimo, o usuário terá que comparecera biblioteca para renová-

lo.

4 CONCLUSÃO

Neste Portifólio em Grupo aprendemos melhor sobre a teoria através dos

conceitos e a prática através do estudo de caso, aprendemos também como

19

funciona o processo para criar um projeto de software utilizando a orientação a

objetos com UML, pois a documentação do projeto é algo bastante importante para

que todo o grupo envolvido no processo de desenvolvimento do sistema trabalhe em

sincronismo, assim podendo alcançar os mesmos objetivo que é um sistema

funcionando em perfeito estado e superando as expectativas de todos, mesmo

sabemos que esse processo de criação e documentação poderá consumir um tempo

que às vezes pode parecer desnecessário até porque poderíamos utilizar desse

tempo para fazer outras atividades voltadas ao projeto. De tal forma aprendemos

ainda que a documentação gerada no decorrer desse período é de suma

importância e utilidade, tanto para manter o grupo alinhado aos objetivos do projeto

quanto para a evolução do sistema porque com na elaboração desse trabalho, é

necessário ter em mente um método eficaz de desenvolvimento para o sistema

evitando os possíveis erros, é útil também se necessário empenhar-se na análise de

requisitos para evitar que não ocorra o famoso retrabalho, evitando tal forma

ultrapassar o orçamento do projeto e na maioria das vezes, a data limite e com isso

a perda de dinheiro e tempo mais como o principal objetivo desse projeto é para um

trabalho escolar ficou mais fácil a utilização da análise orientada a objetos, o

desenvolvimento de software ficou simples, pois os objetos possuem características

e ações retratando o mundo real.

 

20

REFERÊNCIAS BIBLIOGRÁFICAS

http://www.infoq.com/br/news/2012/05/An-Introduction-Software-Quality <acesso em:

05/11/2012>

http://www.sobreengenhariadesoftware.com/ <acesso em: 01/11/2012>

http://www.sobreengenhariadesoftware.com/ <acesso em:06/11/2012>

http://pt.wikipedia.org/wiki/Engenharia_de_requisitos <acesso em:11/11/2012>

http://pt.wikipedia.org/wiki/Teste_de_software <acesso em:02/11/2012>

http://www.infoq.com/br/news/2012/05/An-Introduction-Software-Quality <acesso em:

27/10/2012>

http://pt.wikipedia.org/wiki/Diagrama_de_caso_de_uso acesso em:02/11/2012>

http://pt.wikipedia.org/wiki/Prototipa%C3%A7%C3%A3o <acesso em: 10/11/2012>

21