TECNOLOGIA EM ANLISE E DESENVOLVIMENTO DE SISTEMAS

IOLANDA LIMA QUEIROZ ORLANDO DE OLIVEIRA LIMA

PRODUO TEXTUAL INTERDISCIPLINAR EM GRUPO

Gurupi - TO 2012

IOLANDA LIMA QUEIROZ ORLANDO DE OLIVEIRA LIMA

PRODUO TEXTUAL INTERDISCIPLINAR EM GRUPO

Trabalho de Anlise e desenvolvimento de sistemas apresentado Universidade Norte do Paran - UNOPAR, como requisito parcial para a obteno da mdia Semestral na disciplina de Anlise de Sistema I,Engenharia de Software, Banco de Dados I, Linguagens e Tcnicas de Programao II. Orientao: Prof.Polyanna P. Gomes Fabris Prof. Luis Cludio Perini Prof. Roberto Nishimura Prof. Anderson Macedo

Gurupi TO 2012

SUMRIO

1 INTRODUO........................................................................................................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 no 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 Prottipos das Telas..........................................................................................................................16 3.10 Privilgios de Administrador............................................................................................................18 3.10.1 Privilgios de Usurios Comum.......................................................................................................................19 4 CONCLUSO.........................................................................................................19 5 REFERNCIAS BIBLIOGRFICA.........................................................................21

1 INTRODUO

Todos os dias o mundo passa por mudanas. Em nosso dia-a-dia no diferente. Lidamos com tecnologia a todo o momento, que para ns, so muito teis sem as quais j no sabemos viver, nos tornando muito dependentes das mesmas. A revoluo digital est presente em nosso dia-a-dia, em tudo o que fazemos, estamos envolvidos com a tecnologia. E as empresas esto se utilizando desta ferramenta, para sua organizao, para melhorar a sua comunicao interna e externa, seu planejamento e atitudes perante o mercado de atuao. Visando suprir as necessidades e desejos de seus clientes. comprovado que hoje a comunicao est bem mais rpida e mais fcil com a era digital. A velocidade com que voc tem acesso informao, a rapidez na troca de informaes. Facilitando o desempenho da Comunicao Empresarial, e suas estratgias e aes. necessrio se utilizar bem desta ferramenta, no tem como nos dias de hoje ficar sem. A era digital, est em toda parte por menor que seja a sua rea de atuao, ou seu foco negcio.

2 OBJETIVO

O objetivo desse trabalho fazer com que ns 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 elaborao de um plano de desenvolvimento de software com base na qualidade, ou seja, vrios conceitos e prticas da Engenharia de Software que atuam de forma importante na produo de um software de qualidade. Neste projeto utilizaremos a ferramenta Astah na criao do diagrama de caso de uso do sistema da locadora de livros, o Br modelo na criao do banco de dados conceitual e lgico desse sistema e ainda a linguagem C# nos ajudar na criao das telas .

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 produo de um documento de requisitos e sua manuteno ao longo do tempo. Este processo deve ser precedido de estudos de viabilidade que, a partir das restries do projeto, determinam se este ou no vivel e se deve prosseguir para a identificao dos requisitos. O processo de engenharia de requisitos composto por quatro atividades de alto nvel (Soares, 2005):

Identificao; Anlise e negociao; Especificao e documentao; Validao.

Outra atividade que se pode considerar que faz tambm parte deste processo, se incluir a fase posterior produo do documento (isto , a sua "manuteno"), a gesto dos requisitos (change management, sendo que as alteraes podem ser causa pelos mais diversos fatores desde inovaes tecnolgicas a mudanas na natureza do negcio (e conseqentemente nos requisitos), entre outras.

3.2 Modelos de Processo de Software

de extrema importncia 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 nvel de confiabilidade/segurana do projeto, ou seja, um modelo para um processo de desenvolvimento uma proposta terica 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 so: se a equipe de desenvolvimento uma empresa de desenvolvimento (software house), uma fbrica de software (desenvolvimento em linha de produo) ou se a equipe de engenheiros da prpria organizao que utilizar o produto. A maneira como o produto ser vendido e instalado tambm tem relevncia: se o software para ser vendido para um pblico amplo (software genrico) ou se ser instalado em uma nica empresa, sob encomenda. So alguns exemplos de modelos: Prototipao, Espiral, Cascata, Extrem e Programming, SCRUM, RUP.

3.3 Testes de Software

O teste do software como se fosse basicamente uma espcie de investigao do software do qual se possvel fornecer informaes sobre sua qualidade em relao 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 aes que vo do levantamento de requisitos at a execuo do teste propriamente dito, pois desta forma no se pode garantir que todo software funcione corretamente, sem a presena de erros ,visto que os mesmos muitas vezes possuem um grande nmero de estados com frmulas, 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 permutao possvel do software deveria ser testada. Entretanto, isso se torna impossvel para a ampla maioria dos casos devido quantidade impraticvel de possibilidades. A qualidade do teste acaba se relacionando qualidade dos profissionais envolvidos em filtrar as permutaes relevantes, pois a maioria das falhas pode ser originada por diversos motivos. Por exemplo, a especificao pode estar errada ou incompleta, ou pode conter requisitos impossveis de serem implementado, devido a limitaes de hardware ou software. A implementao tambm 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 aplicao pode, e normalmente, varia significativamente de sistema para sistema. Os atributos qualitativos previstos na norma ISO 9126 so funcionalidade, confiabilidade, usabilidade, eficincia, manuteno e portabilidade. De forma geral, mensurar o bom funcionamento de um software envolve compar-lo com elementos como especificaes, outros softwares da mesma linha, verses anteriores do mesmo produto, inferncias pessoais, expectativas do cliente, normas relevantes, leis aplicveis, entre outros. Enquanto a especificao do software diz respeito ao processo de verificao do software, a expectativa do cliente diz respeito ao processo de validao do software. Um desenvolvimento de software organizado tem como premissa uma metodologia de trabalho. Esta deve ter como base conceitos que visem construo de um produto de software de forma eficaz. Dentro desta metodologia esto definidos os passos necessrios 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 prprio fornecedor, ou seja, a empresa de desenvolvimento. Observando este aspecto, no faz sentido iniciar a construo de um produto de software sem ter uma metodologia de trabalho bem solidificada e que seja do conhecimento de todos os envolvidos no processo. Porm, alm de uma crescente demanda por softwares de qualidade, as empresas de desenvolvimento de software sofrem cada vez mais presso por parte dos clientes para que o produto seja entregue num curto perodo de tempo. Este fato pode fazer com que uma slida 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 nvel de qualidade imprescindvel a melhoria dos processos de engenharia de software. Uma maneira vivel 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 situaes e ambientes especficos ou para solues genricas, existem alguns que so mais utilizados e

tidos como eficientes, como por exemplo, os SW-CMM, SE-CMM, ISO/IEC_15504 e o mais conhecido CMMI. Outro fator com grande influncia sobre a qualidade do software a ser produzido o que diz respeito aos testes que sero executados sobre tal produto. Todas as metodologias de desenvolvimento de software tm uma disciplina dedicada aos testes. Atualmente esta uma tarefa indispensvel, porm 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 bilhes de dlares economia dos Estados Unidos. Mais de um tero do custo poderia ser evitado com melhorias na infraestrutura do teste de software. Existem muitas maneiras de se testar um software. Mesmo assim, existem as tcnicas que sempre foram muito utilizadas em sistemas desenvolvidos sobre linguagens estruturadas que ainda hoje tm grandes valia para os sistemas orientados a objeto. Apesar de os paradigmas de desenvolvimento sere completamente diferentes, o objetivo principal destas tcnicas continua a ser o mesmo, encontrar falhas no software. Abaixo esto descritas algumas das tcnicas mais conhecidas. Caixa-Branca: Tambm chamada de teste estrutural ou orientada

lgica, a tcnica de caixa-branca avalia o comportamento interno do componente de software. Essa tcnica trabalha diretamente sobre o cdigo fonte do componente de software para avaliar aspectos tais como: teste de condio, teste de fluxo de dados, teste de ciclos, teste de caminhos lgicos, cdigos nunca executados.

Caixa-Preta: Tambm chamada de teste funcional, orientado a dado ou

orientado a entrada e sada, a tcnica de caixa-preta avalia o comportamento externo do componente de software, sem se considerar o comportamento interno do mesmo. Dados de entrada so fornecidos, o teste executado e o resultado obtido comparado a um resultado esperado previamente conhecido. Como detalhes de implementao no so considerados, os casos de teste so todos derivados da especificao.

Caixa-Cinza: A tcnica de teste de caixa-cinza um mesclado do uso

das tcnicas 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 so executados como na tcnica da caixa-preta. Manipular entradas de dados e formatar a sada no considerado caixa-cinza, pois a entrada e a sada esto claramente fora da caixa-preta. A caixa-cinza pode incluir tambm o uso de engenharia reversa para determinar, por exemplo, os limites superiores e inferiores das classes, alm de mensagens de erro.

Regresso: Essa uma tcnica de teste aplicvel a uma nova verso

de software ou necessidade de se executar um novo ciclo de teste durante o processo de desenvolvimento. Consiste em se aplicar, a cada nova verso do software ou a cada ciclo, todos os testes que j foram aplicados nas verses ou ciclos de teste anteriores do sistema. Inclui-se nesse contexto a observao de fases e tcnicas de teste de acordo com o impacto de alteraes provocado pela nova verso ou ciclo de teste. Para efeito de aumento de produtividade e de viabilidade dos testes, recomendada a utilizao de ferramentas de automao de teste, de forma que, sobre a nova verso ou ciclo de teste, todos os testes anteriores possam ser executados novamente com maior agilidade.

Alm destas tcnicas citadas h tambm outras tcnicas de teste existentes para testar aspectos no funcionais do software, como por exemplo, a adequao a restries de negcio, adequao a normas, ou restries tecnolgicas. Em contraste s tcnicas funcionais mencionadas acima, que verificam a produo pelo sistema de respostas adequadas de suas operaes, de acordo com uma especificao, as tcnicas no funcionais verificam atributos de um componente ou sistema que no se relacionam com a funcionalidade (por exemplo, confiabilidade, eficincia, usabilidade, manuteno 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 especificaes de tempo de processamento exigidas, o que determina a escala do software. O teste de usabilidade necessrio para verificar se a interface de usurio fcil de aprender e utilizar. Entre verificaes cabveis esto relao da interface
6

com conhecimento do usurio, 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 recuperao usado para verificar a robustez do software em retornar a um estado estvel de execuo aps estar em um estado de falha. Uma prtica comum testar o software aps uma funcionalidade ser desenvolvida, e antes dela ser implantada no cliente, por um grupo de profissionais diferente da implementao. Essa prtica pode resultar na fase de teste ser usada para compensar atrasos do projeto, comprometendo o tempo devotado ao teste. Outra prtica comear o teste no mesmo momento que o projeto, num processo contnuo at o fim do projeto. Em contrapartida, algumas prticas emergentes como a programao extrema e o desenvolvimento gil focam o modelo de desenvolvimento orientado ao teste. Nesse processo, os testes de unidade so escritos primeiro (TDD), por engenheiros de software. Antes da implementao da unidade em questo, o teste falha. Ento o cdigo escrito, passando incremental mente em pores maiores dos casos de teste. Os testes so mantidos junto com o resto do cdigo fonte do software, e geralmente tambm integra o processo de construo 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 atravs da definio e normatizao 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 satisfaa s expectativas do cliente, dentro daquilo que foi acordado inicialmente. Segundo a norma ISO 9000 (verso 2000), a qualidade o grau em que um conjunto de caractersticas 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 Laboratrio de Inteligncia Artificial e Cincia da Computao do MIT, define qualidade como a conformidade aos requisitos. Essa ((definio exige determinar dois pontos: I) o que se entende por conformidade; e II) como so 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 (usurios, desenvolvedores e patrocinadores), e o resultado que os defeitos no software causam, sejam eles externos ou internos, ao longo do tempo. No artigo Os Trs Aspectos da Qualidade de Software: funcionais estruturais e de processo (PDF), Chappell apresenta trs aspectos da qualidade de um software: funcional, estrutural e de processo, onde cada um est relacionado de alguma forma aos trs grupos de pessoas diretamente interessadas no produto final ou servio: usurios, desenvolvedores e patrocinadores. Qualidade funcional expressa o quo bem o software executa as tarefas solicitadas por seus usurios. Chappell distingue quatro atributos desse tipo de qualidade de software:

O software atende aos requisitos especificados Possui poucos defeitos Possui um desempenho razovel fcil de aprender e de usar

A Qualidade estrutural mede o quo bem o software organizado, sendo definida pelos seguintes atributos:

Testabilidade do cdigo Manutenibilidade - facilidade para realizar manuteno do cdigo Clareza - facilidade em se entender o cdigo Eficincia do cdigo - gerencia os recursos (memria, conexes de

rede) eficientemente?

Segurana do cdigo - capaz de impedir as ameaas de segurana

mais comuns?

Enquanto a qualidade funcional e a estrutural "recebem a fatia do leo nas discusses sobre qualidade de software", Chappell considera que a qualidade do processo tambm muito importante, em que seus principais atributos so:

As datas de entrega so cumpridas? Est dentro do oramento? H um processo de desenvolvimento de software replicvel? Um que

entregue software de qualidade de forma confivel e previsvel? Chappell acredita que os usurios esto 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 prprio trabalho, mas tambm esto interessados em qualidade funcional, s que no tanto quanto os usurios, e na qualidade do processo porque "fornece muitas das mtricas 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 no funcionais do sistema Nossa Locadora de Livros Os requisitos so as caractersticas e restries do produto de software do ponto de vista de satisfao das necessidades do usurio, e, em geral independente da tecnologia empregada na construo da soluo sendo a parte mais crtica e propensa a erros no desenvolvimento de software. So objetivos ou restries estabelecidas por clientes e usurios do sistema que definem as diversas propriedades da soluo. Os requisitos de software so, obviamente, aqueles dentre os requisitos de sistema que dizem respeito a propriedades do software tradicionalmente, os requisitos de software so separados em requisitos funcionais e no funcionais. Funcionais: So a descrio das diversas funes que clientes e

usurios querem ou precisam que o software faa. Eles definem a funcionalidade desejada do software. A especificao de um requisito funcional deve determinar o que se espera que o software faa, sem a preocupao de como ele faz.

No funcionais: So as qualidades globais de um software, como

manuteno, usabilidade, desempenho, custos e vrias outras. Normalmente estes requisitos so descritos de maneira informal. Descrevem as restries de tempo, do processo de desenvolvimento, padres e etc. Geralmente, so mais crticos do que os funcionais e se ignorados, podem transformar todo o sistema em algo intil. Os requisitos funcionais do sistema Nossa Locadora de Livros leva em considerao os seguintes itens:

O sistema deve manter um cadastro de clientes; O sistema deve prover e controlar a renovao do emprstimo de

forma on-line; O sistema deve manter um cadastro de livros; O sistema deve controlar e disparar avisos sobre prazos de devoluo

se esgotando a seus clientes; O sistema deve controlar o nmero mximo permitido de livros

emprestados por vez para cada cliente.

J os requisitos no funcionais o sistema levar em consideraes outros detalhes como, por exemplo:

O cadastro de clientes deve ser simplificado com: nome, endereo,

telefone, e-mail e senha; O sistema deve vetar emprstimos em caso de atraso confirmado e

avisar ao cliente que comparea biblioteca para sanar as pendncias do referido emprstimo; O sistema deve limitar para no mximo 03(trs) exemplares, os

emprstimos por vez para cada cliente; O sistema dever comunicar ao cliente, via e-mail, quando faltar1 (um)

dia para se esgotar o prazo de devoluo do emprstimo; O cadastro de livros deve contemplar de forma obrigatria a localizao

e a quantidade de exemplares por ttulo.

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 seqncia de eventos de um ator que usa um sistema para completar um processo". Um caso de uso representa uma unidade discreta da interao entre um usurio (humano ou mquina) 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" so todos casos de uso. Cada caso de uso tem uma descrio da funcionalidade que ir ser construda no sistema proposto. Um caso de uso pode "usar" outra funcionalidade de caso de uso ou "estender" outro caso de uso com seu prprio comportamento. Casos de uso so tipicamente relacionados a "atores". Um ator um humano ou entidade mquina que interage com o sistema para executar um significante trabalho. No Cenrio o Cliente chega locadora de livros e solicita o emprstimo. O funcionrio verifica no sistema podendo cadastrar o cliente ou efetuar o emprstimo. O cliente de forma on-line poder efetuar a renovao do emprstimo segundo as regras impostas pelo sistema, bem como gerenciar suas pendncias de emprstimos. O funcionrio tambm pode efetuar renovaes e gerenciar pendncias. O funcionrio mantm o cadastro dos livros informando sempre a localizao e o nmero de exemplares por ttulos.

Os Atores so representados pelo Cliente e funcionrio. Casos de uso: manter cadastro de cliente; manter cadastro de livro; controlar emprstimos; cadastrar localizao do livro; cadastrar quantidade de volumes por ttulo; gerenciar pendncias de emprstimos. Na Figura 01 mostra-se um Prt scr de todo o processo de criao do diagrama do caso de uso usando a ferramenta ASTAH, j na figura02 possvel 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 criao.

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

3.7 Projetos de Banco de Dados

Aps 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 trs tarefas bsicas. So elas: entrada, processamento e sada. A entrada dos dados est relacionada diretamente com a interao do usurio, que na maioria das vezes o responsvel pela insero da informao por meio de teclado, mouse, entre outros dispositivos de entrada, com relao sada, os dados
12

que foram informados na entrada passam pelo processamento atendendo a expectativa do usurio e so apresentados por um dispositivo de sada, como por exemplo, um monitor ou impressora j no caso do processamento pode definir simplesmente como interao dos dados de entrada com a sada. "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 informaes consideradas significativas a qualquer organizao ou um nico usurio." (DATE 1990).

3.8 Modelagens do Banco de dados

Existem dois modelos de bancos de dados; a modelagem conceitual e a modelagem lgica, sendo que modelagem de entidades e relacionamentos onde a finalidade estruturar a soluo descrevendo de maneira conceitual os dados que sero utilizados em nosso sistema. No nosso modelo conceitual foi verificada a necessidade de trs tabelas (usurio, cadlivro e emplivro) e duas relaes entre elas (cadastro e emprstimo). Na Figura 01 mostra um Prt scr do processo de criao 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 criao.

13

Figura 02-Br modelo Conceitual (imagem jpg).

J na modelagem lgica vamos dar incio s regras que cada campo deve conter, onde definiremos as principais caractersticas, informando se o preenchimento obrigatrio ou nulo, numrico, alfanumrico, boleano, etc. Nesse modelo, podemos compreender melhor a relao entre as tabelas USUARIO, CADLIVRO E EMPLIVRO. NA relao CADASTRO e a relao EMPRESTIMO, recebem duas chaves identificadoras, cod_usuario da tabela USUARIO e cod_livro da tabela CADLIVRO. Estas relaes que definem as aes dos usurios atravs do cod_usuario, qual caminho tomar, se para o cadastro ou somente para emprstimo. Na Figura 03 mostra um Prt scr do processo de criao desse modelo lgico para a Nossa Locadora de Livros. Na Figura 04 mostra como ficou o modelo lgico j convertido em imagem jpg.

14

Figura 03- modelo lgico em Prt scr Processo de Criao.

Figura 04- Modelo lgico convertido em imagem jpg.

Os campos da tabela USUARIO foram definidos da seguinte forma: Cod_usurio: ser do tipo numrico, com valor mximo de 7digitos, com incremento automtico e ser a chave primria da nossa tabela. Nome: ser do tipo alfanumrico, com no mximo 50 caracteres, com preenchimento obrigatrio. Endereo: ser do tipo alfanumrico, com no mximo 50caracteres, com preenchimento obrigatrio. Telefone: ser do tipo numrico, com no mximo 10 dgitos, com preenchimento obrigatrio.
15

 E-mail: ser do tipo alfanumrico, com no mximo 50 caracteres, com preenchimento obrigatrio. Senha: ser do tipo alfanumrico, com no mximo 8 caracteres, com preenchimento obrigatrio.

J os campos da tabela CADLIVRO, foram definidos da seguinte forma: Cod_livro: ser do tipo numrico, com valor mximo de 7 dgitos, com incremento automtico e ser a chave primria da nossa tabela. Livro: ser do tipo alfanumrico, com no mximo 50 caracteres, com preenchimento obrigatrio. Quantidade: ser do tipo numrico, com no mximo 3 dgitos, com preenchimento obrigatrio. Localizao: ser do tipo alfanumrico, com no mximo 50caracteres, com preenchimento obrigatrio.

Para a tabela EMPLIVRO: Cod_livro: chave estrangeira que foi importada com todas as caractersticas da tabela LIVRO. Cod_usuario: chave estrangeira importada da tabela USUARIO com todas as caractersticas. Data_emplivro: ser do tipo date, com preenchimento obrigatrio. Em caso de renovao, este campo ser alterado para a data atual.

3.9 Prottipos das Telas

Prototipao uma abordagem baseada numa viso evolutiva do desenvolvimento de software, afetando o processo como um todo. Esta abordagem envolve a produo de verses iniciais - prottipos (anlogo a maquetes para a arquitetura) - de um sistema futuro com o qual se podem realizar verificaes e experimentos, com intuito de avaliar algumas de suas caractersticas antes que o sistema venha realmente a ser construdo, de forma definitiva.

16

No processo de prototipao onde iremos compreender a funcionalidade do sistema sendo que na pgina de autenticao o cliente que j cadastrado vai inserir suas credenciais, e o sistema verificar seu tipo de privilgio atravs do cod_usuario. No caso do cliente com privilgios de um administrador, este ser redirecionado para a pgina de cadastro de livros, onde ter outros links para interagir com o cadastro de novos usurios alm de controlar emprstimos. A tela CADASTRAR LIVROS ser apresentado assim que o usurioadministrador informar seu login e senha. Os campos para o cadastro do livro que j foram explicados na modelagem conceitual e lgica so obrigatrios e quando efetuado o cadastro de um livro a pgina continua a mesma dando oportunidade para um novo cadastro.

Figura 5 Pgina de cadastro de Usurio

No link Cadastrar Usurio, o administrador redirecionado para uma nova tela onde conter novos campos para cadastros de um novo usurio. Assim como no processo de cadastro do livro, quando inserido um novo usurio, a pgina continua a mesma, informando atravs de uma mensagem na tela que o cadastro foi efetuado com sucesso. No link Controlar Emprstimos o administrador informar o cdigo do usurio que pretende gerenciar e na mesma tela retornar as informaes dos usurios junto com os livros que foram emprestados por este.
17

Figura 6- Emprstimo de Livros com a Data prxima do vencimento.

3.10 Privilgio de Administrador

No caso do cliente com privilgios de um administrador, este ser redirecionado para a pgina de cadastro de livros (figura 7), onde ter outros links para interagir com o cadastro de novos clientes alm de controlar emprstimos. A tela CADASTRAR LIVROS ser apresentada assim que o clienteadministrador informar seu login e senha. Os campos para o cadastro do livro que j foram explicados na modelagem conceitual e lgica so obrigatrios e quando efetuado o cadastro de um livro a pgina continua a mesma dando oportunidade para um novo cadastro.

Figura 7- Privilgio de Cadastrar Livros

18

3.10.1 Privilgios de Usurio Comum

Por padro, o nosso sistema tem o administrador e o usurio comum. O administrador tem permisso para cadastrar e gerenciar livros e usurios. No caso do usurio comum que foi cadastrado pelo administrador do sistema, ter acesso a pgina de autenticao em comum com o administrador, mas o sistema se encarregar de redirecion-lo para a pgina de emprstimos de livros onde atravs do campo pesquisa o usurio escolher o livro que procura. Em nosso exemplo mostramos que o usurio 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 emprstimo que est vencendo.

Figura 7- Emprstimo de Livros com a Data vencida

Quando o usurio estiver com algum emprstimo vencido, o sistema lhe apresenta o livro que est expirado e no permite a renovao do mesmo. Para uma renovao do emprstimo, o usurio ter que comparecera biblioteca para renovlo.

4 CONCLUSO

Neste Portiflio em Grupo aprendemos melhor sobre a teoria atravs dos conceitos e a prtica atravs do estudo de caso, aprendemos tambm como funciona o processo para criar um projeto de software utilizando a orientao a
19

objetos com UML, pois a documentao do projeto algo bastante importante para que todo o grupo envolvido no processo de desenvolvimento do sistema trabalhe em sincronismo, assim podendo alcanar os mesmos objetivo que um sistema funcionando em perfeito estado e superando as expectativas de todos, mesmo sabemos que esse processo de criao e documentao poder consumir um tempo que s vezes pode parecer desnecessrio at porque poderamos utilizar desse tempo para fazer outras atividades voltadas ao projeto. De tal forma aprendemos ainda que a documentao gerada no decorrer desse perodo de suma importncia e utilidade, tanto para manter o grupo alinhado aos objetivos do projeto quanto para a evoluo do sistema porque com na elaborao desse trabalho, necessrio ter em mente um mtodo eficaz de desenvolvimento para o sistema evitando os possveis erros, til tambm se necessrio empenhar-se na anlise de requisitos para evitar que no ocorra o famoso retrabalho, evitando tal forma ultrapassar o oramento 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 fcil a utilizao da anlise orientada a objetos, o desenvolvimento de software ficou simples, pois os objetos possuem caractersticas e aes retratando o mundo real.

20

REFERNCIAS BIBLIOGRFICAS

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