ministÉrio da educaÇÃo utfpr - páginas pessoais · este sistema foi desenvolvido utilizando o...

MINISTÉRIO DA EDUCAÇÃO

UTFPR – UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ

CAMPUS CORNÉLIO PROCÓPIO

CURSO SUPERIOR DE TECNOLOGIA EM INFORMÁTICA

ALBERTO LUIZ DA SILVA

TRABALHO DE CONCLUSÃO DE CURSO

Sistema de vendas de música na internet por meio de cartão “ MP3 CARD”

CORNÉLIO PROCÓPIO

MARÇO – 2006

ii

MINISTÉRIO DA EDUCAÇÃO

UTFPR – UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ

CAMPUS CORNÉLIO PROCÓPIO

CURSO SUPERIOR DE TECNOLOGIA EM INFORMÁTICA


TRABALHO DE CONCLUSÃO DE CURSO

Sistema de vendas de música na internet por meio de cartão “ MP3 CARD”

Trabalho de conclusão de curso apresentado

como requisito para a obtenção do grau de

Tecnólogo em Informática pela Universidade

Tecnológica Federal do Paraná – Campus

Cornélio Procópio.

Orientador: Professor Ms. Fabrício Martins

Lopes

CORNÉLIO PROCÓPIO

MARÇO – 2006

iii

COMISSÃO EXAMINADORA

Professor Ms. Fabrício Martins Lopes

Orientador

Professor Antônio Carlos Fernandes da Silva

Membro da banca examinadora

Professor Guilherme Luiz Frufrek

Membro da banca examinadora

Cornélio Procópio, 31 de Março de 2006

iv

AGRADECIMENTOS

A Deus pela saúde e oportunidade.

A minha Família pelo amor, apoio e imensurável esforço realizado

para com os meus estudos.

A minha namorada Talita pelo seu amor, carinho, paciência e pela

compreensão nos momentos em que estive ausente. EU TE AMO MEU NENÊ!!!

Ao meu orientador, conselheiro e amigo Professor Mestre Fabrício

Martins Lopes pela confiança e paciência depositada em mim deste a época do

estágio curricular, além da incomparável amizade.

Aos meus amigos e colegas que de alguma maneira me apoiaram e

me deram força durante o desenvolvimento deste trabalho.

Ao Pixote pelos momentos de descontração.

v

EPÍGRAFE

“ A imaginação é mais importante que o conhecimento.”

Albert Einstein

“A alegria que se tem em pensar e aprender faznos pensar e aprender ainda mais.”

Aristóteles.

vi

RESUMO

A violação dos direitos autorais de arquivos musicais na internet é

um crime que é praticado todos os dias por milhares de pessoas no mundo todo e

acarreta muitos prejuízos aos detentores desses direitos.

Buscando uma solução viável para essa questão, o objetivo do

sistema desenvolvido neste trabalho é proporcionar a compra de forma legal de

arquivos musicais por meio de um cartão com uma senha e um determinado número

de créditos. Assim proporcionando ao consumidor uma economia em relação à

compra de um disco musical e ao detentor dos direitos autorais sobre tal música o

ressarcimento devido.

Este sistema foi desenvolvido utilizando o Processo Unificado de

desenvolvimento de software e na modelagem de diagramas foi utilizada a notação

Unified Modeling Language (UML) com extensão para web. Na implementação do

sistema foram aplicados quatro padrões de projeto e o mesmo foi implementado

utilizando a linguagem de programação Java.

vii

ABSTRACT

The breaking of the copyrights of musical archives in the Internet is a

crime that is practiced every day by thousand of people all over the world and causes

many damages to the retainers of these rights.

Searching a viable solution for this question, the objective of the

system developed in this work is to provide the purchase of legal form of musical

archives through a card with a password and one determined number of credits.

Thus providing to the consumer an economy in relation the purchase of a musical

record and to the retainer of the copyrights on such music the compensation due.

The system was developed using the Unified Process software

development and all the diagrams models are under UML language and also with

web extension. Four project patterns had been applied for the implementation of

system and the language used was Java.

viii

LISTA DE ILUSTRAÇÕES

Figura 1 – Exemplo de um “Mp3 Card” .....................................................................20

Figura 2 – Estrutura do Processo Unificado Adaptada da Figura 2.7 (ARLOW;

NEUSTAD, 2002). ..............................................................................................27

Figura 3 – Marcos, Fases e Iterações do Processo Unificado Adaptada da Figura

2.6 (ARLOW; NEUSTAD, 2002).........................................................................28

Figura 4 Estrutura do Processo Unificado – Fluxo de trabalho requisitos Adaptada

da Figura 2.7 (ARLOW; NEUSTAD, 2002).........................................................31

Figura 5 Estrutura do Processo Unificado Fluxo de trabalho análise Adaptada da

Figura 2.7 (ARLOW; NEUSTAD, 2002)..............................................................33

Figura 6 Estrutura do Processo Unificado Fluxo de trabalho projeto Adaptada da

Figura 2.7 (ARLOW; NEUSTAD, 2002)..............................................................34

Figura 7 Estrutura do Processo Unificado Fluxo de trabalho implementação

Adaptada da Figura 2.7 (ARLOW; NEUSTAD, 2002). .......................................36

Figura 8 – Atores do sistema.....................................................................................53

Figura 9 – Modelo de caso de uso ............................................................................56

Figura 10 – Diagrama de caso de uso Logar Administrador no Sistema...................57

Figura 11 – Diagrama de caso de uso Administrador Efetuar Logout .......................57

Figura 12 – Diagrama de caso de uso Alterar senha de Administrador ....................57

Figura 13 – Diagrama de caso de uso Gerenciar Discos ..........................................58

Figura 14 – Diagrama de caso de uso Gerenciar Músicas........................................58

Figura 15 – Diagrama de caso de uso Gerenciar Senhas.........................................59

Figura 16 – Diagrama de caso de uso Gerenciar Usuários.......................................59

Figura 17 – Diagrama de caso de uso Gerenciar Aquisições....................................59

ix

Figura 18 – Diagrama de caso de uso Alterar Cadastro............................................60

Figura 19 – Diagrama de caso de uso Debitar crédito em Senha.............................60

Figura 20 – Diagrama de Seqüência Logar Administrador no Sistema.....................83

Figura 21 – Diagrama de Seqüência Administrador Efetuar Logout .........................84

Figura 22 Diagrama de Seqüência Alterar senha de Administrador .......................85

Figura 23 Diagrama de Seqüência Cadastrar Disco...............................................86

Figura 24 Diagrama de Seqüência Alterar Disco ....................................................87

Figura 25 Diagrama de Seqüência Excluir Disco ....................................................88

Figura 26 Diagrama de Seqüência Listar Discos ....................................................89

Figura 27 Diagrama de Seqüência Cadastrar Música.............................................90

Figura 28 Diagrama de Seqüência Alterar Música..................................................91

Figura 29 Diagrama de Seqüência Excluir Música..................................................92

Figura 30 Diagrama de Seqüência Listar Músicas..................................................93

Figura 31 Diagrama de Seqüência Visualizar Música.............................................94

Figura 32 Diagrama de Seqüência Gerar Senha(s) ................................................95

Figura 33 Diagrama de Seqüência Cadastrar Senha(s)..........................................96

Figura 34 Diagrama de Seqüência Excluir Senha...................................................97

Figura 35 Diagrama de Seqüência Buscar Senha ..................................................98

Figura 36 Diagrama de Seqüência Listar Usuários.................................................99

Figura 37 Diagrama de Seqüência Visualizar Usuário..........................................100

Figura 38 Diagrama de Seqüência Excluir Usuário...............................................101

Figura 39 Diagrama de Seqüência Listar Aquisições............................................102

Figura 40 Diagrama de Seqüência Visualizar Aquisição.......................................103

Figura 41 Diagrama de Seqüência Excluir Aquisição............................................104

Figura 42 Diagrama de Seqüência Logar no Sistema...........................................105

x

Figura 43 Diagrama de Seqüência Efetuar logout no Sistema..............................106

Figura 44 Diagrama de Seqüência Cadastrar Usuário..........................................107

Figura 45 Diagrama de Seqüência Alterar Cadastro.............................................108

Figura 46 Diagrama de Seqüência Listar Discos cadastrados..............................109

Figura 47 Diagrama de Seqüência Listar Músicas cadastradas ...........................110

Figura 48 Diagrama de Seqüência Exibir Download de Música............................111

Figura 49 Diagrama de Seqüência Download de Música......................................111

Figura 50 – Diagrama de Atividade Logar Administrador no Sistema – Referente ao

caso de uso UC1..............................................................................................112

Figura 51 – Diagrama de Atividade Alterar senha de Administrador – Referente ao

caso de uso UC3..............................................................................................113

Figura 52 – Diagrama de Atividade Cadastrar Disco – Referente ao caso de uso

UC4.1. ..............................................................................................................114

Figura 53 – Diagrama de Atividade Alterar Disco – Referente ao caso de uso UC4.2.

.........................................................................................................................115

Figura 54 – Diagrama de Atividade Excluir Disco – Referente ao caso de uso UC4.3.

.........................................................................................................................116

Figura 55 – Diagrama de Atividade Cadastrar Música – Referente ao caso de uso

UC5.1. ..............................................................................................................117

Figura 56 – Diagrama de Atividade Alterar Música – Referente ao caso de uso

UC5.2. ..............................................................................................................118

Figura 57 – Diagrama de Atividade Excluir Música – Referente ao caso de uso

UC5.3. ..............................................................................................................119

Figura 58 – Diagrama de Atividade Listar Músicas – Referente ao caso de uso

UC5.4. ..............................................................................................................119

xi

Figura 59 – Diagrama de Atividade Visualizar Música – Referente ao caso de uso

UC5.5. ..............................................................................................................120

Figura 60 – Diagrama de Atividade Gerar Senha(s) – Referente ao caso de uso

UC6.1. ..............................................................................................................121

Figura 61 – Diagrama de Atividade Cadastrar Senha(s) – Referente ao caso de uso

UC6.2. ..............................................................................................................122

Figura 62 – Diagrama de Atividade Excluir Senha – Referente ao caso de uso

UC6.3. ..............................................................................................................123

Figura 63 – Diagrama de Atividade Buscar Senha – Referente ao caso de uso

UC6.4. ..............................................................................................................124

Figura 64 – Diagrama de Atividade Visualizar Usuário – Referente ao caso de uso

UC7.2. ..............................................................................................................125

Figura 65 – Diagrama de Atividade Excluir Usuário – Referente ao caso de uso

UC7.3. ..............................................................................................................126

Figura 66 – Diagrama de Atividade Listar Aquisições – Referente ao caso de uso

UC8.1. ..............................................................................................................127

Figura 67 – Diagrama de Atividade Visualizar Aquisição – Referente ao caso de uso

UC8.2. ..............................................................................................................128

Figura 68 – Diagrama de Atividade Excluir Aquisição – Referente ao caso de uso

UC8.3. ..............................................................................................................129

Figura 69 – Diagrama de Atividade Logar no Sistema – Referente ao caso de uso

UC9. .................................................................................................................130

Figura 70 – Diagrama de Atividade Cadastrar Usuário – Referente ao caso de uso

UC11. ...............................................................................................................131

xii

Figura 71 – Diagrama de Atividade Alterar cadastro – Referente ao caso de uso

UC12. ...............................................................................................................132

Figura 72 – Diagrama de Atividade Listar Discos cadastrados – Referente ao caso

de uso UC13.1. ................................................................................................132

Figura 73 – Diagrama de Atividade Listar Músicas cadastradas – Referente ao caso

de uso UC13.2. ................................................................................................133

Figura 74 – Diagrama de Atividade Exibir Download de Música – Referente ao caso

de uso UC13.3. ................................................................................................134

Figura 75 – Diagrama de Atividade Download de Música – Referente ao caso de uso

UC13.4. ............................................................................................................135

Figura 76 – Diagrama de Classes ...........................................................................137

Figura 77 – Diagrama de Componentes..................................................................139

Figura 78 – Modelo EntidadeRelacionamento .......................................................140

xiii

LISTA DE TABELAS

Tabela 1 – Requisitos funcionais...............................................................................50

Tabela 2 – Requisitos nãofuncionais .......................................................................53

Tabela 3 – Casos de uso identificados......................................................................54

Tabela 4 – Especificação do caso de uso Logar Administrador no Sistema .............61

Tabela 5 – Especificação do caso de uso Administrador Efetuar Logout..................61

Tabela 6 – Especificação do caso de uso Alterar senha de Administrador...............62

Tabela 7 – Especificação do caso de uso Gerenciar Discos.....................................63

Tabela 8 Especificação do caso de uso Gerenciar Musicas ...................................66

Tabela 9 Especificação do caso de uso Gerenciar Senhas ....................................70

Tabela 10 Especificação do caso de uso Gerenciar Usuários ................................73

Tabela 11 Especificação do caso de uso Gerenciar Aquisições .............................75

Tabela 12 Especificação do caso de uso Logar no Sistema...................................77

Tabela 13 Especificação do caso de uso Efetuar logout no Sistema......................78

Tabela 14 Especificação do caso de uso Cadastrar Usuário..................................78

Tabela 15 Especificação do caso de uso Alterar Cadastro.....................................79

Tabela 16 Especificação do caso de uso Processar download de Música .............80

Tabela 17 – Caso de Teste Logar Administrador no Sistema .................................141

Tabela 18 – Caso de Teste Administrador Efetuar Logout......................................142

Tabela 19 – Caso de Teste Alterar senha de Administrador ...................................143

Tabela 20 – Caso de Teste Cadastrar Disco...........................................................144

Tabela 21 – Caso de Teste Alterar Disco................................................................145

Tabela 22 – Caso de Teste Excluir Disco................................................................145

Tabela 23 – Caso de Teste Listar Discos................................................................146

xiv

Tabela 24 – Caso de Teste Cadastrar Música ........................................................147

Tabela 25 – Caso de Teste Alterar Música .............................................................148

Tabela 26 – Caso de Teste Excluir Música .............................................................149

Tabela 27 – Caso de Teste Listar Músicas .............................................................149

Tabela 28 – Caso de Teste Visualizar Música ........................................................150

Tabela 29 – Caso de Teste Gerar Senha(s)............................................................151

Tabela 30 – Caso de Teste Cadastrar Senha(s).....................................................152

Tabela 31 – Caso de Teste Excluir Senha ..............................................................153

Tabela 32 – Caso de Teste Buscar Senha..............................................................153

Tabela 33 – Caso de Teste Listar Usuários ............................................................154

Tabela 34 – Caso de Teste Visualizar Usuário .......................................................155

Tabela 35 – Caso de Teste Excluir Usuário ............................................................156

Tabela 36 – Caso de Teste Listar Aquisições .........................................................157

Tabela 37 – Caso de Teste Visualizar Aquisição ....................................................157

Tabela 38 – Caso de Teste Excluir Aquisição.........................................................158

Tabela 39 – Caso de Teste Logar no Sistema ........................................................159

Tabela 40 – Caso de Teste Efetuar Logout no Sistema..........................................160

Tabela 41 – Caso de Teste Cadastrar Usuário .......................................................160

Tabela 42 – Caso de Teste Alterar Cadastro ..........................................................161

Tabela 43 – Caso de Teste Listar Discos cadastrados ...........................................162

Tabela 44 – Caso de Teste Listar Músicas cadastradas.........................................163

Tabela 45 – Caso de Teste Exibir Download de Música .........................................164

Tabela 46 – Caso de Teste Download de Música ...................................................164

Tabela 47 – Cronograma de Execução...................................................................167

Tabela 48 – Cronograma de Atividades ..................................................................167

xv

LISTA DE ABREVIATURAS E SIGLAS

ARPA Advanced Research Projects Agency

CD Compact Disc

DAO Data Acess Object

DVD Digital Video Disc

EUA Estados Unidos da América

J2EE Java 2 Enterprise Edition

JSP Java Server Page

MER Modelo EntidadeRelacionamento

MP3 MPEG Audio Layer3

MPEG Moving Picture Experts Group

RIAA Recording Industry Association of América

SP São Paulo

TCP/IP Transmission Control Protocol/Internet Protocol

UML Unified Modeling Language

UP Processo Unificado

VO Value Object

WAE Web Application Extension

xvi

SUMÁRIO

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

2 OBJETIVOS........................................................................................................20

3 JUSTIFICATIVAS ...............................................................................................21

4. REVISÃO BIBLIOGRÁFICA ..............................................................................22

4.1. INTERNET ..................................................................................................22

4.1.1 A Internet e os Direitos Autorais ............................................................23

4.2. PROCESSO UNIFICADO (UP) ...................................................................25

4.2.1. Fases....................................................................................................28

4.2.1.1 Concepção..........................................................................................28

4.2.1.2 Elaboração..........................................................................................29

4.2.1.3 Construção .........................................................................................29

4.2.1.4 Transição............................................................................................30

4.2.2. Fluxos de Trabalho ...............................................................................30

4.2.2.1 Requisitos ...........................................................................................31

4.2.2.2 Análise................................................................................................32

4.2.2.3 Projeto ................................................................................................33

4.2.2.4 Implementação ...................................................................................35

4.2.2.5 Teste...................................................................................................36

4.3. LINGUAGEM DE MODELAGEM UNIFICADA (UML) .................................37

4.3.1 Extensão para a Web ............................................................................38

4.3.2. Diagrama de Caso de Uso....................................................................39

4.3.2.1 Caso de Uso.......................................................................................39

4.3.2.2 Ator .....................................................................................................40

xvii

4.3.2.3 Relacionamento..................................................................................40

4.3.3 Diagrama de Seqüência ........................................................................41

4.3.4 Diagrama de Atividades.........................................................................41

4.3.5 Diagrama de Classes ............................................................................42

4.3.6 Diagrama de Componentes ...................................................................43

4.4. PADRÕES DE PROJETO...........................................................................44

4.4.1. Front Controller.....................................................................................45

4.4.1.1 Estratégia de implementação .............................................................45

4.4.2 Singleton................................................................................................46

4.4.3 Value Object (VO)..................................................................................47

4.4.4 Data Acess Object (DAO)......................................................................48

5. DESENVOLVIMENTO.......................................................................................50

5.1. CONCEPÇÃO .............................................................................................50

5.1.1 Requisitos Funcionais............................................................................50

5.1.2 Requisitos nãofuncionais......................................................................52

5.1.3 Identificação de atores...........................................................................53

5.1.4 Identificação de casos de uso................................................................54

5.1.5 Modelo de caso de uso..........................................................................56

5.2. ELABORAÇÃO............................................................................................56

5.2.1 Diagramas de caso de uso ....................................................................57

5.2.2 Especificação de Caso de Uso..............................................................60

5.2.3. Realizações dos Casos de Uso Identificados. ......................................83

5.2.3.1 Diagramas de Seqüência....................................................................84

5.2.3.2 Diagramas de Atividades..................................................................112

5.2.4 Diagrama de Classes ..........................................................................135

xviii

5.3. CONSTRUÇÃO.........................................................................................138

5.3.1 Diagrama de Componentes .................................................................138

5.3.2 Modelo EntidadeRelacionamento.......................................................139

5.3.3. Testes.................................................................................................141

5.3.3.1 Teste de Caixa Preta ........................................................................141

5.4. TRANSIÇÃO .............................................................................................165

6 CRONOGRAMA ...............................................................................................167

7 RECURSOS ALOCADOS.................................................................................168

8 CONCLUSÃO ...................................................................................................169

9 TRABALHOS FUTUROS..................................................................................170

10 REFERÊNCIAS ..............................................................................................171

APÊNDICE A – PROPOSTA DO TRABALHO DE DIPLOMAÇÃO......................173

19

1 INTRODUÇÃO

A popularização tanto da internet discada quanto à de banda larga

reflete naturalmente o aumento do número de usuários que acessam a rede e

também quantitativamente e qualitativamente os serviços oferecidos na internet que

permitem aos usuários terem acesso a suas contas bancárias, participar de leilões,

ver notícias em tempo real, trocar arquivos, escutar músicas, ver filmes, e

especialmente comprar eletroeletrônicos, livros e Compact Disc’s (CD’s).

A popularização da internet trouxe também a necessidade de uma

maior prudência e responsabilidade quanto ao uso da rede, já que a facilidade de

acessar dados confidenciais de pessoas e violação de direitos aumentou

proporcionalmente com o aumento da rede. Uma grande preocupação atualmente é

a facilidade com que os usuários podem adquirir músicas sem terem que pagar

pelos direitos autorais das mesmas.

O propósito desse trabalho de diplomação é desenvolver um sistema

de aquisição de músicas pela internet de forma legal, por meio da compra de um

cartão “raspinha” comprado em lojas ou ganhado em shows musicais.

20

2 OBJETIVOS

Este trabalho teve como objetivo desenvolver um sistema de

aquisição de arquivos musicais no formato MPEG Audio Layer3 (mp3) via internet

por meio de uma senha que está impressa em um cartão “raspinha” que pode ser

comprado em lojas de venda de CD’s musicais ou ganhados em shows musicais.

Nesse cartão “MP3 CARD” está impressa uma senha, que dá direito

ao usuário ter acesso por meio de um serviço web a uma ou mais músicas do

website, dependendo de quantos créditos possui o cartão, e independente de álbum

musical. Essa senha é única e é gerada aleatoriamente pelo sistema e depois

passada a gráfica para a impressão dos cartões “raspinhas”.

Figura 1 – Exemplo de um “Mp3 Card”

21

3 JUSTIFICATIVAS

Tendo em vista a viabilidade deste projeto, foi detectado o interesse

de um grupo de músicos em contribuir com o trabalho, profissionais da banda

Gigahertz (São Paulo – SP), que colaboraram ativamente no desenvolvimento do

trabalho. Esta colaboração ocorreu na forma de sugestões sobre a forma com que a

banda deseja utilizar esse sistema.

Com a banda Gigahertz utilizando esse sistema, o custo de

aquisição de músicas para o consumidor se torna mais acessível. Pois o CD não

precisaria ser gravado e colocado em uma capa protetora com um encarte, além do

fato de que o consumidor não precisaria pagar por um CD com quinze músicas e

que interessam a ele apenas cinco músicas.

22

4. REVISÃO BIBLIOGRÁFICA

4.1. INTERNET

No auge da guerra fria, em meados da década de 1960, o

Departamento de Defesa dos Estados Unidos da América (EUA) decidiu desenvolver

uma rede de comunicação que suportasse uma possível guerra nuclear, já que as

tradicionais redes de comunicação utilizadas naquela época eram consideradas

vulneráveis, pois caso ocorresse à perda de uma linha de comunicação todas as

conversações que estivessem utilizando esta linha seriam perdidas e a rede seria

dividida (TANENBAUM, 1997).

Para solucionar esse problema foi convocada pelo Pentágono a

Advanced Research Projects Agency (ARPA). A ARPA foi responsável pela criação

da ARPANET, que foi concebida a partir de estudos e pesquisas realizadas nas

universidades nos EUA e também por empresas.

No final do ano de 1969 entrou no ar uma rede de cunho

experimental com quatro nós em diferentes localidades dos EUA. O que levou a

ARPA a escolher esses nós foi devido ao grande número de contratos que esses

locais possuíam com a ARPA e também devido ao fato dos locais terem

computadores com diferentes configurações e completamente incompatíveis, o que

proporcionava a essa rede um grande destaque.

Essa rede de cunho experimental cresceu rapidamente e em

Setembro de 1972 já possuía trinta e quatro nós espalhados por todo território norte

americano.

23

Em meados da década de 1980, a ARPANET já era uma rede

estável e bem sucedida. A rede passou a ser denominada como uma interrede e

depois como Internet (TANENBAUM, 1997).

O protocolo Transmission Control Protocol/Internet Protocol (TCP/IP)

tornouse o primeiro protocolo oficial da Internet (TANENBAUM, 1997), e com isso a

rede acabou tendo um grande crescimento ano após ano até os dias atuais. Com o

crescimento da rede, a Internet ganhou novos protocolos e passou a oferecer uma

grande variedade de serviços como, por exemplo, correio eletrônico, notícias em

tempo real, entretenimento, televisão, música, compartilhamento de arquivos e

especialmente compras online de CD’s musicais, Digital Vídeo Disc’s (DVD’s) e

muitos outros.

4.1.1 A Internet e os Direitos Autorais

O grande crescimento da Internet nos últimos anos provocou uma

revolução tecnológica e social muito grande em toda sociedade mundial. Essa rede

de computadores que no seu início era utilizada apenas por pesquisadores, passou

a ultrapassar fronteiras de países e hoje é acessada por milhões e milhões de

pessoas em todo o planeta. Antes o que era utilizado com o objetivo de trocar

informações sobre pesquisas realizadas em universidades norteamericanas

(TANENBAUM, 1997), hoje pode ser utilizado para vários fins.

Essa evolução permite aos usuários que utilizam a rede mundial de

computadores acessarem com uma velocidade cada vez maior um grande número

de serviços que são oferecidos pela rede, desde fazer compras em lojas virtuais a

até assistir um canal de televisão ou ouvir uma rádio virtual.

24

Com esse crescimento e popularização da Internet, surgiram

também os problemas relacionados a essa mesma rede. Um desses problemas é a

violação dos direitos autorais de obras intelectuais, como por exemplo, livros,

composições, músicas e filmes.

O surgimento e a popularização da Internet não é o responsável pelo

aparecimento desse crime, pois os equipamentos listados a seguir não foram

inventados graças a Internet e não dependem da tecnologia da mesma.

• Máquina fotocopiadora: permite copiar de forma não

autorizada um livro, revista, artigo.

• Radiogravador: permite copiar as músicas de um CD para

uma fitacassete de áudio sem prévia autorização.

• Vídeocassete, DVD: Permite reproduzir cópias não

autorizadas de filmes.

A internet não foi a responsável pelo surgimento do crime por

violação de direitos autorais, mas com a constante evolução dos computadores e da

Internet esse crime passou a ser praticado por milhões de pessoas que utilizam à

rede mundial de computadores. Há alguns anos atrás uma música que era copiada

de um CD musical para uma fita cassete de áudio tinha sua qualidade

comprometida, e esta nova cópia gerada só poderia gerar novas cópias com

qualidades ainda piores.

Hoje com a evolução dos computadores é possível em alguns

minutos que as músicas contidas em um CD sejam copiadas para o computador

com a mesma qualidade de áudio encontrada no CD. Dessa forma, basta o

computador estar conectado a Internet e possuir um software de compartilhamento

de arquivos para que essas músicas possam ser compartilhadas com pessoas de

todo o planeta sem terem que pagar nada por isso.

25

Para conter os avanços da “pirataria virtual” as gravadoras estão

movendo processos judiciais contras pessoas e empresas que estariam “baixando”

arquivos de música da Internet sem pagar os direitos autorais aos produtores das

músicas, ou seja, as próprias gravadoras. No dia 22 de junho de 2005 a Recording

Industry Association of America (RIAA), entidade que representa as gravadoras

norteamericanas comemorou o processo judicial de número 3.000 contra pessoas e

empresas por violarem os direitos autorais de arquivos musicais por meio da Internet

(GUEIROS, 2005).

Além dessa tentativa rigorosa de conter a troca de arquivos de

música pela Internet, há outras tentativas de se resolver esse problema crescente.

Várias gravadoras no mundo já disponibilizam serviços de vendas de músicas na

Internet, permitindo ao usuário comprar as músicas separadamente, sem terem que

adquirir todas as músicas de um álbum específico.

Essas soluções para tentar impedir a troca de arquivos de música

pela internet e a violação dos direitos autorais podem até surtir efeito, mas o efeito

esperado só será obtido quando houver uma conscientização por parte dos usuários

da rede mundial de computadores para que sejam respeitados os direitos autorais

nas obras musicais e que os arquivos musicais sejam adquiridos de maneira legal.

4.2. PROCESSO UNIFICADO (UP)

O Processo Unificado de Desenvolvimento de Software (UP) forma

uma estrutura geral e adaptável para o desenvolvimento de software. Segundo

(ARLOW; NEUSTADT, 2002) o processo unificado descreve “um conjunto de passos

que define quem está fazendo o que, quando e como para alcançar um determinado

26

objetivo”. Na visão da engenharia de software, para atingir este objetivo é

necessário que um produto seja entregue de maneira eficiente e previsível, além de

atender às necessidades de seu negócio.

Esse processo de desenvolvimento de software pode ser

considerado uma compilação das melhores e principais características de outros

processos de desenvolvimento de software. Mas isso não impediu que o UP

deixasse de possuir suas próprias características, as quais proporcionam a este um

diferencial importante em relação aos outros processos de desenvolvimento de

software. Veja a seguir as três principais características que agregam grandes

valores a esse processo:

• Orientado por casos de uso: Um caso de uso pode ser

considerado uma seqüência de ações de um sistema que resultam

em um valor e o retorna ao usuário, e um conjunto de casos de uso

forma o diagrama de casos de uso que descreve a funcionalidade do

sistema sob um contexto. Dessa forma, um processo de

desenvolvimento de software orientado por casos de uso faz com

que um sistema seja desenvolvido especificadamente com a

finalidade de atender as necessidades de cada usuário que interage

com o mesmo, evitando o desenvolvimento e posterior apresentação

de funcionalidades desnecessárias no sistema.

• Centrado na arquitetura: Este processo de desenvolvimento

de software, o conceito de arquitetura de software encapsula os

aspectos estáticos e dinâmicos mais importantes do sistema. Dessa

forma, a arquitetura é responsável por fornecer um ambiente para a

realização de todos os requisitos dos casos de uso do sistema em

desenvolvimento, já que os casos de uso estão ligados a

funcionalidade do mesmo. Assim o processo unificado permite o(s)

arquiteto(s) do sistema concentrarse nas metas corretas e

requisitos principais do sistema, obtendo durante e ao final do

27

desenvolvimento um produto de qualidade que possa evoluir, se

adaptar a mudanças e conter componentes reutilizáveis.

• Iterativo incremental: Um processo iterativo incremental

permite que todo o desenvolvimento do projeto seja dividido em

miniprojetos. Assim cada miniprojeto é uma iteração que ao seu

final resulta em um avanço no desenvolvimento do produto como um

todo (incremento). Com essa divisão do projeto e o controle dessas

iterações é possível obter alguns benefícios significativos no

desenvolvimento do projeto, como por exemplo, redução do risco de

custo para despesas em um único incremento; redução do risco de

violação de prazos; facilidade maior na adaptação do sistema a

mudanças dos requisitos.

O Processo Unificado define que um projeto baseado na estrutura

do mesmo deve ter o seu ciclo de vida dividido em quatros fases: Concepção,

Elaboração, Construção e Transição. Cada uma dessas fases é subdividida em

iterações, sendo que cada iteração passa por cinco fluxos de trabalho definidos pelo

Processo Unificado: Requisitos, Análise, Projeto, Implementação e Teste. A Figura 2

mostra a estrutura do Processo Unificado.

Figura 2 – Estrutura do Processo Unificado Adaptada da Figura 2.7 (ARLOW;

NEUSTAD, 2002).

28

4.2.1. Fases

O ciclo de vida de um projeto baseado no UP está dividido em

quatro fases, cada uma dessas podendo ser subdividida em iterações que

conseqüentes ao seu final tornamse incrementos. Conforme mostrado na Figura 3,

o final de cada fase do ciclo de vida é demarcado por um ponto de verificação, ou

seja, pela disponibilidade de um conjunto de artefatos que possibilitem a avaliação

do projeto.

Figura 3 – Marcos, Fases e Iterações do Processo Unificado Adaptada da Figura

2.6 (ARLOW; NEUSTAD, 2002)

4.2.1.1 Concepção

O principal objetivo da fase de concepção é a delimitação do escopo

do projeto a ser desenvolvido, por meio da definição de como o sistema será

utilizado por cada um dos usuários, por meio da criação dos casos de uso mais

relevantes.

Todo o esforço que será aplicado durante esta fase poderá evitar o

fracasso do projeto por meio da identificação prévia dos riscos.

29

Nesta fase de concepção, a maior parte do trabalho que será

realizado está voltada ao fluxo de requisitos, porém cada um dos fluxos de trabalho

da estrutura do UP possui seu papel dentro desta fase, conforme a quantidade de

esforço a ser empregado na mesma.

4.2.1.2 Elaboração

Durante a fase de elaboração, os requisitos remanescentes são

capturados e transformados em casos de uso. Dessa forma, é estabelecida a base

da arquitetura responsável por guiar os trabalhos nas fases de construção e

transição.

Na fase de elaboração é obtida uma visão geral do sistema, sem a

necessidade de conceber uma visão do sistema que engloba detalhes minuciosos

sobre o mesmo.

O foco desta fase se encontra na formulação de uma base para a

arquitetura do sistema em desenvolvimento.

4.2.1.3 Construção

Na fase de construção o trabalho é iniciado baseado na arquitetura

executável produzida na fase de elaboração, assim o trabalho desta fase prossegue

por meio de iterações e conseqüentes incrementos, objetivando o desenvolvimento

de um produto pronto para operações iniciais no ambiente de usuário (versão beta).

Nesta fase os casos de uso remanescentes são detalhados e a

descrição arquitetural é modificada quando houver necessidade. Os fluxos de

30

trabalho desta fase prosseguem por meio de iterações adicionais, objetivando o

preenchimento dos modelos de análise, projeto e implementação. Dessa forma os

subsistemas e o sistema como uns todos são integrados e testados.

4.2.1.4 Transição

O objetivo desta fase é estabelecer o produto no ambiente

operacional.

Nesta fase é possível realizar as seguintes verificações a partir da

avaliação do usuário:

• O sistema realmente cumpre as necessidades do usuário.

• O sistema possui falhas ou problemas.

• Dificuldades encontradas pelos usuários na utilização do

sistema.

Conforme os resultados obtidos nas avaliações, a equipe de

desenvolvimento do projeto pode modificar o sistema e/ou seus respectivos

artefatos.

4.2.2. Fluxos de Trabalho

As fases do processo unificado são divididas em iterações, e cada

uma delas realiza cinco fluxos de trabalho. O grau de importância de cada um dos

fluxos de trabalho depende da fase do UP em que a iteração se encontra.

Os cinco fluxos de trabalho do UP são detalhados nas próximas

subseções.

31

4.2.2.1 Requisitos

Neste fluxo de trabalho, os requisitos do sistema são capturados e

especificados por meio da identificação das necessidades do usuário do sistema

(requisitos funcionais).

Estes requisitos funcionais são expressos em de casos de uso, os

quais são identificados por meio da identificação das tarefas de cada usuário do

sistema, no desenvolvimento de suas atividades.

O foco das atividades realizadas neste fluxo de trabalho, conforme

Figura 4, está na identificação de entidades que interagem com o sistema,

denominadas de atores, e na identificação dos requisitos funcionais do sistema para

cada um dos atores, denominados de casos de uso.

Figura 4 Estrutura do Processo Unificado – Fluxo de trabalho requisitos Adaptada

da Figura 2.7 (ARLOW; NEUSTAD, 2002).

O agrupamento de todos os diagramas de casos de uso e atores

identificados que compõem o sistema em um único diagrama forma o modelo de

casos de uso.

32

Esse modelo de casos de uso é desenvolvido e melhorado em

vários incrementos. Cada uma das iterações realizadas adiciona novos casos de uso

ao modelo ou detalha ainda mais casos de uso já existentes.

O modelo de casos de uso é utilizado com o objetivo de organizar os

requisitos funcionais do sistema. Isso permite que clientes e usuários possam

entendêlo e usálo para comunicar suas necessidades de forma consistente e não

redundante. Os desenvolvedores do projeto podem dividir o trabalho de identificação

de requisitos entre si, e então utilizar os resultados obtidos como entrada para os

fluxos de análise, projeto, implementação e teste.

4.2.2.2 Análise

Na realização deste fluxo de trabalho é gerado o modelo de análise.

O objetivo desse modelo é aprimorar os requisitos especificados no fluxo de

requisitos por meio da construção de diagramas de classes conceituais, permitindo

assim a argumentação a respeito do funcionamento do sistema. Esse modelo de

análise fornece mais poder expressivo e formalismo por meio de diagramas de

interações e diagramas de gráficos de estados que representam a dinâmica do

sistema.

Conforme Figura 5, este fluxo de trabalho tem maior importância

durante a realização da fase de elaboração. Isso permite que a arquitetura seja

definida de forma estável e facilita o entendimento detalhado dos requisitos.

33

Figura 5 Estrutura do Processo Unificado Fluxo de trabalho análise Adaptada da

Figura 2.7 (ARLOW; NEUSTAD, 2002).

O modelo de análise fornece uma estrutura voltada a manutenção

dos requisitos do sistema por meio da estruturação dos mesmos. Essa estrutura,

além de ser útil à manutenção dos requisitos, serve também de entrada para os

fluxos de projeto e de implementação.

A preservação da estrutura fornecida pelo modelo de análise no

projeto, permite desenvolver um sistema de fácil manutenção e com grande poder

de adaptação caso ocorra mudança de requisitos. Mas há situações em que a

estrutura que é fornecida pelo modelo de análise não deve ser preservada, e sim

transformada durante o projeto e implementação do sistema.

4.2.2.3 Projeto

Na realização deste fluxo de trabalho moldase o sistema e a sua

definição, com o objetivo de suprir as necessidades especificadas pelos requisitos.

34

No fluxo de projeto é construído o modelo de projeto baseandose no modelo de

análise que foi definido no fluxo de análise.

Este modelo de projeto construído é utilizado para descrever o

sistema em um nível físico, e a sua principal função é obter uma compreensão

refinada dos requisitos do sistema, considerando detalhes sobre sistema

operacional, linguagem de programação, banco de dados e interface com usuário.

O foco do fluxo de projeto, conforme Figura 6, está entre o final da

fase de elaboração é o início da fase de construção. Essa distribuição permite a

definição de uma arquitetura estável e também contribui na criação do modelo de

projeto que posteriormente fornecerá base para o próximo fluxo (fluxo de

implementação) e será preservado durante o ciclo de vida do sistema.

Figura 6 Estrutura do Processo Unificado Fluxo de trabalho projeto Adaptada da

Figura 2.7 (ARLOW; NEUSTAD, 2002).

Este modelo criado pode ser visto como uma abstração da

implementação do sistema, haja vista que o fluxo anterior (fluxo de análise) descreve

o que o sistema em desenvolvimento deve fazer e o fluxo de projeto enfoca como os

requisitos deste sistema serão implementados.

35

4.2.2.4 Implementação

Este fluxo de trabalho baseiase no modelo de projeto criado no

fluxo anterior (fluxo de projeto) para implementar o sistema em arquivos executáveis,

componentes e códigos fontes.

A arquitetura do sistema foi definida durante a realização do fluxo de

projeto, sendo assim, o fluxo de implementação produzirá um modelo de

implementação que permitirá planejar as integrações do sistema em cada iteração

do ciclo de vida, resultando em uma implementação que será realizada em

pequenas etapas sucessíveis e gerenciáveis.

Por meio destas pequenas etapas são implementados os

subsistemas que foram identificados durante o projeto e posteriormente serão

realizados testes sobre essas implementações e integração dos subsistemas.

O maior parte do esforço do fluxo de implementação é desprendido

durante a fase de construção (Figura 7), e mesmo com as características próprias

deste fluxo, as atividades que são realizadas durante a execução do mesmo

ocorrem de maneira “automática”, pois as decisões mais complexas sobre o projeto

foram tomadas durante o fluxo anterior (fluxo de projeto).

36

Figura 7 Estrutura do Processo Unificado Fluxo de trabalho implementação

Adaptada da Figura 2.7 (ARLOW; NEUSTAD, 2002).

4.2.2.5 Teste

O último fluxo a ser executado conforme a estrutura do UP é o fluxo

de teste. O desenvolvimento deste fluxo é realizado baseado no produto gerado

durante o fluxo anterior (fluxo de implementação).

Neste fluxo, o objetivo principal é submeter arquivos executáveis e

componentes criados durante a execução do fluxo de implementação a testes para a

então análise dos resultados e posterior disponibilização do sistema aos usuários

finais do mesmo. Assim é possível verificar se o produto do fluxo de implementação

satisfaz os requisitos do sistema especificados pelos clientes e usuários da

aplicação. E caso se encontre componentes com falhas, os mesmos serão

direcionados aos fluxos de trabalho anteriores para a correção dos problemas

encontrados.

37

Na execução deste fluxo de trabalho é criado o modelo de teste.

Este modelo descreve como são testados os componentes do sistema

desenvolvidos durante o fluxo de implementação.

4.3. LINGUAGEM DE MODELAGEM UNIFICADA (UML)

A Unified Modeling Language (UML) define uma linguagem padrão e

uma notação gráfica para a criação de modelos de negócios e sistemas técnicos

(CARLSON, 2002).

Essa linguagem de modelagem é o resultado de um processo que

buscou unir os pontos positivos dos principais métodos de desenvolvimento de

sistemas orientados a objeto existentes na primeira metade da década de 1990.

Assim foi possível obter uma linguagem de modelagem que pudesse ser utilizada

não apenas por programadores, e sim por projetistas e analistas também. É

importante salientar que a UML é uma linguagem de modelagem e é utilizada

juntamente com um processo de desenvolvimento de software, independentemente

de qual processo está sendo utilizado.

A notação utilizada pela UML é padronizada, e obrigatoriamente

deve ser assim, para que a descrição de cada parte do sistema que está sendo

modelado possa ser precisa e entendida por qualquer pessoa que conheça e

entenda a UML.

Essa notação utilizada é uma notação gráfica, na qual a descrição

de um software ou parcial desse software é feita por meio de símbolos gráficos

padronizados que se relacionam e formam os diagramas, que são descritos por

38

nomes e termos padronizados. Cada diagrama apresenta uma visão parcial do

software, e a união de todos os diagramas representa o software.

4.3.1 Extensão para a Web

A UML possui mecanismos de extensão que permitem o refinamento

da sintaxe e da semântica da notação utilizada pela UML para a adequação a

projetos específicos de sistemas.

Esses mecanismos de extensão podem ser de três tipos:

• Estereótipos: São criadas definições de novos elementos a

partir das definições dos elementos já existentes.

• Restrições: Ampliase a semântica dos elementos definidos

pela UML por meio da definição de novas regras ou modificação das

regras já existentes.

• Valores rotulados: Permite a criação de novas propriedades

para os elementos já existentes.

Jim Conallen, em 1999, criou a Web Application Extension (WAE).

Esse mecanismo de extensão é utilizado na definição de estereótipos para serem

aplicados a componentes específicos de sistemas com arquitetura voltada a

ambiente Web.

A WAE permite representar esses elementos sem a necessidade de

criação de novos diagramas e modelos além dos que já são utilizados para

especificar o sistema. A lista a seguir mostra alguns dos componentes

estereotipados pela WAE:

• Server Page

• Client Page

• Formulário

• Frameset

39

• Link

• Submit

• Redirect

• Servlet

Maiores detalhes sobre WAE e suas especificações são encontrados

no artigo em que o autor propôs inicialmente os estereótipos para a Web

(CONALLEN, 1999).

A seguir são apresentados os diagramas que foram utilizados na

modelagem deste trabalho dentre os nove diagramas definidos pela UML. Veja em

(ARLOW; NEUSTAD, 2002) todos os diagramas definidos pela UML e mais detalhes

sobre essa a mesma.

4.3.2. Diagrama de Caso de Uso

Os diagramas de caso de uso são responsáveis por modelar o

comportamento do sistema, subsistema ou de uma classe. Segundo (CONALLEN,

2003) um diagrama de caso de uso expressa os casos de uso do sistema em

relação aos atores que os chamam.

Veja abaixo os três tipos de símbolos gráficos padronizados que

compõem um caso de uso definido pela UML.

4.3.2.1 Caso de Uso

O caso de uso é uma maneira formal de capturar e expressar a

interação e o diálogo entre usuário do sistema, denominados atores e o próprio

sistema (CONALLEN, 2003).

40

Um caso de uso é escrito com o objetivo de expressar o que o

sistema deve fazer, sem impor restrições de como isso será feito.

Em um diagrama de caso de uso, o caso de uso é representado por

meio de uma elipse que contém um nome, e esse nome deve ser intuitivo o

suficiente para que possa refletir a finalidade ou objetivo do caso de uso.

4.3.2.2 Ator

O termo ator é utilizado para representar um papel genérico de um

usuário do sistema ou representar um outro sistema que irá se comunicar com o

sistema em desenvolvimento.

Conforme a padronização da UML, o ator deve ser representado em

um diagrama de caso de uso por meio de uma figura que contenha os traços simples

do corpo de uma pessoa. Essa figura é acompanha de um nome que representa o

tipo de papel que esse ator desempenha no sistema.

4.3.2.3 Relacionamento

O relacionamento entre um ator e um caso de uso tem o objetivo de

expressar que o ator pode chamar este caso de uso.

Em um digrama de caso de uso é possível encontrar dois tipos

principais de relacionamentos entre casos de uso: <<extend>> e <<include>>. Esses

dois tipos de relacionamentos são representados por meio de uma linha tracejada

com uma ponta em forma de seta.

41

4.3.3 Diagrama de Seqüência

Um diagrama de seqüência descreve o comportamento dos objetos

do sistema. Esses objetos se relacionam entre si por meio de troca de mensagens

em interações feitas de forma ordenada em uma linha de tempo que ocorre de cima

para baixo.

Neste diagrama os objetos são organizados um ao lado do outro na

parte superior do diagrama, e cada um desses objetos possui uma linha tracejada no

eixo vertical no qual estão organizadas as mensagens que são trocadas entre esses

objetos.

Esse eixo vertical permite representar a linha de vida dos objetos e

também o foco de controle que indica o período em que o objeto está

desempenhando alguma ação. O foco de controle é representado por um retângulo

alto e estreito sedo que cada foco ocorre entre o recebimento de uma mensagem e

o respectivo retorno da mesma.

As mensagens são representadas por uma seta horizontal, e a ponta

da seta indica o objeto alvo da mensagem.

4.3.4 Diagrama de Atividades

O diagrama de atividades é criado com o objetivo de documentar e

detalhar o fluxo dentro de um caso de uso.

A seguir veja algumas das figuras que são utilizadas em um

diagrama de atividade e suas respectivas representações:

• Estado de início: representado por um círculo preenchido e

localizado no topo do diagrama.

42

• Atividade: representado por um retângulo comprido com os vértices arredondados.

• Nó de decisão: representado por um losango que indica

caminhos alternativos ao fluxo mediante o resultado de alguma

expressão. Cada uma das transições de saída desse nó de decisão

possui um rótulo de condição de saída para este caminho. Somente

uma das transições de saída de um nó de decisão é seguida.

• Barra de sincronização: representada por uma linha

horizontal que indica a união ou bifurcação de um fluxo. A união

possui duas ou mais transições de entrada e apenas uma transição

de saída na qual representa a sincronização dos fluxos de entrada.

A bifurcação contém apenas uma transição de entrada e duas ou

mais transições de saída, sendo que cada uma dessas transições de

saída é um fluxo de controle que ocorrem paralelamente e de forma

independente.

• Transição simples: representada por uma seta que liga duas

figuras do diagrama. A ponta da seta representa a direção do fluxo a

ser seguido.

4.3.5 Diagrama de Classes

O objetivo do diagrama de classes é modelar a visão estática do

sistema, incluindo um conjunto de classes, interfaces, colaborações e seus

relacionamentos.

Em uma estrutura de uma classe podese definir um conjunto de

atributos, que representam seu estado e um conjunto de operações (métodos) que

representam o comportamento desta classe.

Além de atributos e métodos, a classe deve conter também um

nome. Esse nome deve ser o mais adequado possível para a representação dessa

43

classe, assim tornase mais fácil à compreensão do diagrama de classes e também

a identificação da classe no sistema.

A utilização de um diagrama de classes pode ser realizada visando

atingir três objetivos básicos:

• Modelar o vocabulário do sistema: faz com que seja possível

indicar quais são as abstrações que estão dentro do limite do

sistema e quais estão fora desse limite.

• Modelar as colaborações simples: possibilita representar o

comportamento cooperativo de elementos que funcionam em

conjunto (classes, interfaces).

• Modelar o esquema lógico do banco de dados utilizado no

sistema.

4.3.6 Diagrama de Componentes

O diagrama de componentes é utilizado na modelagem dos

aspectos físicos do sistema demonstrando a configuração do sistema, ou seja, como

as partes do sistema se relacionam.

Cada parte do sistema é identificada por um componente, e a

organização, os relacionamentos e a dependência entre esses componentes formam

o sistema.

Um diagrama de componentes modela os itens físicos do sistema,

proporcionando a equipe responsável pelo desenvolvimento do sistema identificar e

relacionar quais serão os arquivos executáveis que serão gerados, quais são as

bibliotecas de sistema que já existem e quais serão criadas e quais os arquivos de

configuração do sistema serão gerados (arquivos com extensão .properties).

44

4.4. PADRÕES DE PROJETO

Vários autores já definiram padrões de várias maneiras diferentes

(GAMMA; HELM; JOHNSON; VLISSIDES, 2002). Alguns foram mais rígidos em

suas definições e outros foram mais simples e flexíveis. Podese definir um padrão

como uma solução permanente para um problema em um determinado contexto.

Essa definição simples pode ser explicada por três palavras chaves:

• Contexto – O contexto é um ambiente em que nele se

encontram circunstâncias, situações e condições que podem gerar

algo que possa ser denominado como problema.

• Problema – Um problema é uma questão que precisa ser

investigada e estudada para que se possa “chegar” a uma solução

que resolva o mesmo. Esse problema pode estar restrito ao

ambiente (contexto) em que o mesmo ocorre.

• Solução – A solução pode ser definida como sendo a

resposta ou ajuda à resposta do problema encontrado.

É importante notar que caso se obtenha a solução de um

determinado problema que ocorre em um determinado contexto não

necessariamente essa solução irá ser um padrão. Pois uma característica muito

importante de um padrão é a reutilização ou regularidade do mesmo. Para ser

considerado um padrão útil, a solução encontrada deve ser definida de tal forma que

se possa ser reutilizada diversas vezes e em projetos diferentes.

Neste trabalho foram utilizados alguns padrões do catálogo de

padrões Java 2 Enterprise Edition (J2EE). Nas subseções seguintes serão

apresentados esses padrões e as estratégias para implementação dos mesmos.

45

4.4.1. Front Controller

O Front Controller é utilizado como o ponto inicial de contato para

tratar todas as solicitações relacionadas. O Front Controller centraliza a lógica de

controle, a qual, de outro modo, poderia ser duplicada, e gerencia as atividades de

tratamento de solicitações principais (ALUR; CRUPI; MALKS, 2003).

Além de evitar a duplicidade de código, o padrão Front Controller

permite a implementação de uma lógica comum às diversas ou todas as solicitações

do sistema. Essa lógica comum de tratamento de solicitações pode ser utilizada para

todo o projeto ou pode ser divida para cada um dos módulos da aplicação que

necessitam que seja feito um tratamento diferenciado para cada solicitação.

Exemplificando, o módulo de cadastro de usuários de um sistema pode ter uma

lógica de tratamento de solicitações diferente do módulo de relatórios acessado pelo

administrador do sistema.

Este padrão também permite a separação da lógica de

processamento do sistema da lógica de visualização do mesmo. Ou seja, a

visualização do sistema que é representada por meio de arquivos Java Server Page

(JSP) contém apenas os códigos Java referentes à visualização de dados.

4.4.1.1 Estratégia de implementação

A implementação do padrão Front Controller foi realizada utilizando

a estratégia Servlet Front.

Nesta estratégia é implementado um Servlet como sendo o

controlador que gerencia todas as requisições do sistema e as relacionam com o

46

processamento de negócio que será submetida cada requisição. Esse Servlet é

representado no sistema pela a classe MainController.java (vide diagrama de

componentes).

Neste projeto, o controlador contém uma lógica condicional que

delega a solicitação para um objeto específico de tratamento da mesma,

denominado Action. Essa lógica condicional é implementada pelo padrão Singleton

(Vide seção 4.4.2).

O padrão Front Controller pode ser implementado também com as

seguintes estratégias:

• JSP Front;

• Command and Controller;

• Physical Resource Mapping;

• Logical Resource Mapping;

• Multiplexed Resource Mapping;

• Dispatcher in Controller

• Base Front

• Filter Controller As estratégias acimas citadas são descritas em (ALUR; CRUPI;

MALKS, 2003).

4.4.2 Singleton

O padrão Singleton garante que uma classe tenha somente uma

instância e fornece um ponto global de acesso para a mesma (GAMMA; HELM;

JOHNSON; VLISSIDES, 2002).

47

Essa instanciação única é garantida porque a classe que

implementa o padrão contém encapsulada sua única instancia, isso permite um

controle total sobre quando e como os clientes acessam essa classe.

Com a implementação do padrão Singleton o número de criação de

variáveis globais é reduzido, pois a implementação do padrão possibilita configurar

na aplicação a instanciação de classes em tempo real, sem que haja a necessidade

de criação de variáveis globais que armazenam instâncias únicas de classes.

Este padrão foi implementado no projeto por meio da classe

AliasMapping.java (Vide seção 5.3.1 Diagrama de Componentes). Com a

implementação deste padrão foi obtido um refinamento de código considerável na

instanciação de classes Action em tempo real na classe MainController.java a partir

de uma chave.

4.4.3 Value Object (VO)

O padrão Value Object (VO) é projetado para otimizar a

transferência de dados entre camadas (ALUR; CRUPI; MALKS, 2003).

Essa transmissão é realizada pelo cliente sem a necessidade do

mesmo realizar várias chamadas a vários métodos getters (métodos de passagem

de valores individuais de uma classe para a outra), reduzindo consideravelmente o

número de solicitações remotas ao longo da rede. Esse grande número de

chamadas de métodos remotas influi negativamente no desempenho do sistema e

eleva o tráfego da rede.

O padrão VO permite que uma classe que implementa este padrão

possua todos os elementos de dados nessa única estrutura requerida pela

48

solicitação (request) ou resposta (response). Dessa forma, a classe implementada

com o padrão VO pode ter os seus atributos preenchidos na camada de

apresentação do sistema e ser transferida entre as camadas até a camada de

integração com o banco de dados ou viceversa. Assim é possível obter os seguintes

benefícios:

• Otimização de transferência de dados entre as camadas;

• Redução de duplicidade de código;

• Transferência de mais dados em menos chamadas remotas;

• Redução do tráfego da rede.

Este padrão foi implementado neste projeto pelas classes

UsuarioVO, SenhaVO, MusicaVO, DiscoVO e AquisicaoVO (veja seção 5.2.4

Diagrama de Classes e seção 5.3.1 Diagrama de Componentes).

4.4.4 Data Acess Object (DAO)

Tendo em vista a aplicação, a mistura da lógica de negócio com a

lógica de persistência de dados cria uma dependência entre a implementação da

regra de negócio e o armazenamento de dados do sistema em um determinado

repositório. Essa dependência direta torna mais complexa a migração de um tipo de

aplicação de repositório para um outro tipo de aplicação de repositório.

O padrão Data Acess Object (DAO) é utilizado para abstrair e

encapsular todo acesso ao armazenamento persistente. O DAO gerencia a conexão

com a fonte de dados para obter e armazenar dados (ALUR; CRUPI; MALKS, 2003).

Dessa forma, é criada uma camada de integração entre a camada de negócios e o

seu repositório. Com a utilização deste padrão é possível obter os seguintes

benefícios:

49

• Migração mais fácil: A migração do repositório para um outro

tipo de repositório tornase uma tarefa mais simples. Pois a regra de

negócio da aplicação está separada da regra de persistência.

• Organização do código de acesso a dados em uma camada

separada: Essa organização fornece uma maior facilidade de

manutenção e gerenciamento da aplicação.

• Fornece visão orientada a objetos e encapsulamento de

esquemas de repositórios: Os clientes (camada de negócio) que

utilizam transmitem os dados para a camada de integração por meio

das classes VO’s. Com isso os clientes não precisam estar cientes

de detalhes de conexão com o repositório, estrutura de tabelas,

nome de colunas e assim por diante.

• Complexidade de código na camada de negócio reduzida:

Com a criação da camada de integração com a implementação do

padrão DAO, os componentes da camada de negócio se tornam

mais simples e específicos. Isso proporciona uma melhora na

capacidade de manutenção e produtividade no desenvolvimento.

Acima foram citados alguns dos principais benefícios obtidos com a

implementação do padrão DAO. Veja mais detalhes sobre este padrão e as

diferentes estratégias de implementação do mesmo em (ALUR; CRUPI; MALKS,

2003). Veja classes implementadas no projeto com o padrão Data Acess Object na

seção 5.3.1.

50

5. DESENVOLVIMENTO

5.1. CONCEPÇÃO

A ênfase dos trabalhos realizados nesta fase está no fluxo de

trabalho de requisitos.

Neste trabalho, a execução desta fase buscou atingir os seguintes

objetivos:

• Delimitar o escopo do projeto.

• Definir os principais requisitos do sistema.

• Representar o domínio e as funcionalidades do sistema por

meio de casos de uso.

• Identificação dos papéis dos usuários do sistema.

5.1.1 Requisitos Funcionais

Os requisitos funcionais, o tipo mais comum de requisito, identificam

os procedimentos que o sistema pode fazer, normalmente em resposta à entrada de

dados externa (CONALLEN, 2003).

A Tabela 1 contém todos os requisitos funcionais identificados junto

com o cliente do sistema.

Tabela 1 – Requisitos funcionais Identificador Requisito Funcional Prioridade

RF01 Permitir ao administrador do sistema acesso ao sistema

por meio de uma sessão com login e senha.

Essencial

51

Identificador Requisito Funcional Prioridade

RF02 Permitir ao administrador do sistema realizar o logout na

sessão do sistema.

Essencial

RF03 Permitir ao administrador alterar a senha de acesso. Essencial

RF04 Permitir ao administrador do sistema inserir, alterar e

excluir um registro de um disco no sistema.

Essencial

RF05 Permitir ao administrador do sistema listar os discos

cadastrados no sistema.

Essencial

RF06 Permitir ao administrador do sistema inserir, alterar e

excluir uma música no sistema.

Essencial

RF07 Permitir ao administrador do sistema listar todas as

músicas cadastradas no sistema.

Essencial

RF08 Permitir ao administrador do sistema relacionar uma

música cadastrada no sistema a um disco já cadastrado

no sistema.

Essencial

RF09 Permitir ao administrador do sistema gerar, inserir, e

excluir uma senha com um determinado número de

créditos no sistema que será utilizada posteriormente

em um mp3card para a realização de downloads de

músicas.

Essencial

RF10 Permitir ao administrador do sistema buscar uma senha

cadastrada no sistema por meio de um filtro de busca.

Essencial

RF11 Permitir ao administrador do sistema listar, excluir e

visualizar registros de usuários cadastrados no sistema.

Essencial

52

Identificador Requisito Funcional Prioridade

RF12 Permitir ao administrador do sistema listar, excluir e visualizar as aquisições de músicas realizadas por

usuários do sistema.

Essencial

RF13 Permitir ao usuário do sistema acesso ao sistema por

meio de uma sessão com login e senha.

Essencial

RF14 Permitir ao usuário do sistema realizar um cadastro

pessoal no sistema e alterar o mesmo.

Essencial

RF15 Permitir ao usuário do sistema realizar o logout da

sessão no sistema.

Essencial

RF16 Permitir ao usuário do sistema visualizar os discos

cadastrados no sistema.

Essencial

RF17 Permitir ao usuário do sistema visualizar as músicas

cadastradas para cada um dos discos do sistema.

Essencial

RF18 Permitir ao usuário do sistema informar uma senha e

realizar o download da música cadastrada no sistema.

Essencial

RF19 Realizar o débito de um crédito na senha informada pelo

usuário no momento do download de uma música

cadastrada no sistema.

Essencial

5.1.2 Requisitos nãofuncionais

Os requisitos não funcionais não indicam os procedimentos que o

sistema pode ou deve fazer. Esses requisitos objetivam a qualidade do sistema, e

podem ser categorizados para uma melhor compreensão. Abaixo são listadas

algumas categorias comuns de requisitos nãofuncionais:

• Usabilidade

53

• Padronização

• Segurança

• Desempenho

• Implantação

• Robustez/confiabilidade

A Tabela 2 mostra os requisitos nãofuncionais identificados com os

clientes do sistema.

Tabela 2 – Requisitos nãofuncionais Identificador Requisito nãofuncional Categoria

RNF01 O sistema desenvolvido deverá ser acessado por

um navegador de Internet.

Usabilidade

RNF02 O sistema desenvolvido deverá conter um banco de

dados free para o armazenamento das informações.

Padronização

RNF03 O sistema deverá realizar autenticação de usuários. Segurança

RNF04 O sistema deverá realizar criptografia nas senhas. Segurança

5.1.3 Identificação de atores

Um ator é utilizado para representar um papel genérico de um

usuário do sistema ou para representar um outro sistema que irá se comunicar com

o sistema em desenvolvimento.

A Figura 8 mostra os atores identificados no desenvolvimento deste

trabalho.

Figura 8 – Atores do sistema

54

• Administrador: Usuário do sistema com perfil de acesso

administrador.

• Usuário WEB: Usuário do sistema que irá usar o navegar do

Internet para baixar uma música do sistema.

5.1.4 Identificação de casos de uso

Um caso de uso é uma descrição textual da interação entre um ator

e o sistema (CONALLEN, 2003).

A Tabela 3 contém todos os casos de uso identificados no

desenvolvimento do sistema.

Tabela 3 – Casos de uso identificados Identificador Caso de uso Prioridade

UC1 Logar Administrador no Sistema. Essencial

UC2 Administrador Efetuar Logout Essencial

UC3 Alterar senha de Administrador. Essencial

UC4. Gerenciar Discos. Essencial

UC4.1 Cadastrar Disco. Essencial

UC4.2 Alterar Disco. Essencial

UC4.3 Excluir Disco. Essencial

UC4.4 Listar Discos. Essencial

UC5. Gerenciar Músicas. Essencial

UC5.1 Cadastrar Música. Essencial

UC5.2 Alterar Música. Essencial

UC5.3 Excluir Música. Essencial

UC5.4 Listar Músicas. Essencial

55

Identificador Caso de uso Prioridade

UC5.5 Visualizar Música. Essencial

UC6. Gerenciar Senhas. Essencial

UC6.1 Gerar Senha(s). Essencial

UC6.2 Cadastrar Senha(s). Essencial

UC6.3 Excluir Senha. Essencial

UC6.4 Buscar Senha. Essencial

UC7. Gerenciar Usuários. Essencial

UC7.1 Listar Usuários. Essencial

UC7.2 Visualizar Usuário. Essencial

UC7.3 Excluir Usuário. Essencial

UC8. Gerenciar Aquisições. Essencial

UC8.1 Listar Aquisições. Essencial

UC8.2 Visualizar Aquisição. Essencial

UC8.3 Excluir Aquisição. Essencial

UC9 Logar no Sistema. Essencial

UC10 Efetuar logout no Sistema. Essencial

UC11 Cadastrar Usuário. Essencial

UC12 Alterar Cadastro. Essencial

UC13. Processar download de Música. Essencial

UC13.1 Listar Discos cadastrados. Essencial

UC13.2 Listar Músicas cadastradas. Essencial

UC13.3 Exibir Download de Música. Essencial

UC13.4 Download de Música. Essencial

56

5.1.5 Modelo de caso de uso

A coleção completa de casos de uso, atores e diagramas constitui

um modelo de caso de uso, que, como os casos de uso individuais, é apenas uma

parte da especificação de requisitos do sistema (CONALLEN, 2003).

A Figura 9 ilustra o modelo de caso de uso do sistema desenvolvido

neste trabalho.

Figura 9 – Modelo de caso de uso

5.2. ELABORAÇÃO

Nesta fase do trabalho, as atividades foram realizadas com o

objetivo foi detalhar o escopo e os objetivos do sistema além de estabelecer a

57

arquitetura responsável por guiar as atividades nas fases seguintes do trabalho

(construção e transição).

5.2.1 Diagramas de caso de uso

A seguir são ilustrados todos os diagramas de caso de uso

levantados durante a execução deste trabalho. A especificação de cada um dos

diagramas de caso de uso é encontrada na próxima subseção.

Figura 10 – Diagrama de caso de uso Logar Administrador no Sistema

Figura 11 – Diagrama de caso de uso Administrador Efetuar Logout

Figura 12 – Diagrama de caso de uso Alterar senha de Administrador

58

Figura 13 – Diagrama de caso de uso Gerenciar Discos

Figura 14 – Diagrama de caso de uso Gerenciar Músicas

59

Figura 15 – Diagrama de caso de uso Gerenciar Senhas

Figura 16 – Diagrama de caso de uso Gerenciar Usuários

Figura 17 – Diagrama de caso de uso Gerenciar Aquisições

60

Figura 18 – Diagrama de caso de uso Alterar Cadastro

Figura 19 – Diagrama de caso de uso Debitar crédito em Senha

5.2.2 Especificação de Caso de Uso

Nesta seção são especificados os casos de usos ilustrados na seção

anterior com o objetivo de apresentar a interação entre o sistema e os atores do

sistema, as précondições, as póscondições e os fluxos alternativos em cada um

dos diagramas de caso de uso ilustrados.

61

Tabela 4 – Especificação do caso de uso Logar Administrador no Sistema Caso de uso: Logar Administrador no Sistema

Identificador: UC1

Atores: Administrador

Précondições: Nenhuma

Fluxo de eventos:

1. O Administrador informa o nome do usuário e a senha e clica no

botão Logar.

2. O Sistema valida as informações, efetua o login e armazena os

valores na sessão do usuário.

Póscondições:

1. Se a operação for realizada com sucesso é exibida a tela com o

menu de administração.

2. Se não é exibida a tela de erro.

Fluxo Alternativo 1:

1. O Administrador pode fechar a tela do navegador.


1. O Administrador pode ir para outro website.

Tabela 5 – Especificação do caso de uso Administrador Efetuar Logout Caso de uso: Administrador Efetuar Logout

Identificador: UC2


Précondições: Ter realizado o caso de uso UC1.

Fluxo de eventos:

62

1. O Administrador clica no botão Logout.

2. O Sistema apaga os dados da sessão do usuário administrador e

exibe a tela de login de administrador.

Póscondições: Nenhuma.





Tabela 6 – Especificação do caso de uso Alterar senha de Administrador Caso de uso: Alterar senha de Administrador

Identificador: UC3



Fluxo de eventos:

1. O Administrador clica no botão Alterar Senha.

2. O Sistema exibe a tela de alteração de senha.

3. O Administrador informa a senha atual e a nova senha e clica no

botão Alterar.

4. O sistema valida a nova senha e atualiza o banco de dados.

Póscondições:

1. Se a operação for realizada com sucesso é exibida a tela com o



63






1. O Administrador pode cancelar a operação.

Tabela 7 – Especificação do caso de uso Gerenciar Discos Caso de uso: Gerenciar Discos

Identificador: UC4.

Caso de uso: Cadastrar Disco

Identificador: UC4.1



Fluxo de eventos:

1. O Administrador clica no botão Inserir Disco.

2. O Sistema exibe a tela de inserção de Disco.

3. O Administrador informa os dados do Disco e clica no botão Inserir.

4. O Sistema valida as informações e insere as mesmas no banco de

dados.

Póscondições:

1. Se a operação for realizada com sucesso é exibida a tela de

inserção novamente com a mensagem de sucesso.


64







Caso de uso: Alterar Disco



Précondições: Ter realizado o caso de uso UC4.4.

Fluxo de eventos:

1. O Administrador clica no botão Alterar.

2. O Sistema carrega tela com os dados referentes ao Disco.

3. O Administrador informa os novos dados do Disco e clica no botão

Alterar.

4. O Sistema valida as informações e atualiza o banco de dados.

Póscondições:

1. Se a operação for realizada com sucesso é exibida novamente a tela

de alteração com a mensagem de sucesso.






65



Caso de uso: Excluir Disco




Fluxo de eventos:

1. O Administrador clica no botão Excluir.

2. O Sistema exclui o Disco do banco de dados.

Póscondições:


listagem de Discos.






Caso de uso: Listar Discos




Fluxo de eventos:

1. O Administrador clica no botão Listar Discos.

2. O Sistema realiza a listagem dos Discos cadastrados.

66

Póscondições:


listagem de Discos.






Tabela 8 Especificação do caso de uso Gerenciar Musicas Caso de uso: Gerenciar Músicas

Identificador: UC5.

Caso de uso: Cadastrar Música




Fluxo de eventos:

1. O Administrador clica no botão Inserir Música.

2. O Sistema exibe a tela de inserção de Música.

3. O Administrador informa os dados da Música e clica no botão Inserir.


dados.

Póscondições:


de inserção com a mensagem de sucesso.

67








Caso de uso: Alterar Música




Fluxo de eventos:

1. O Administrador clica no botão Alterar.

2. O Sistema carrega tela com os dados referentes à Música.

3. O Administrador informa os novos dados da Música e clica no botão

Alterar.

4. O Sistema valida as informações e atualiza o banco de dados.

Póscondições:


de alteração com a mensagem de sucesso.





68




Caso de uso: Excluir Música




Fluxo de eventos:


2. O Sistema exclui a Música do banco de dados.

Póscondições:


listagem de Músicas.






Caso de uso: Listar Músicas




Fluxo de eventos:

1. O Administrador clica no botão Listar Músicas.

69

2. O Sistema realiza a listagem das Músicas cadastradas.

Póscondições:


listagem de Músicas.






Caso de uso: Visualizar Música




Fluxo de eventos:

1. O Administrador clica no botão Visualizar.

2. O Sistema recupera os dados da Música e do Disco que a Música

pertence.

Póscondições:


visualização de Música.





70


Tabela 9 Especificação do caso de uso Gerenciar Senhas Caso de uso: Gerenciar Senhas

Identificador: UC6.

Caso de uso: Gerar Senha(s)




Fluxo de eventos:

1. O Administrador clica no botão Gerar Senhas.

2. O Sistema exibe a tela de geração e cadastro de Senhas.

3. O Administrador informa a quantidade de Senhas que deseja e clica

no botão Gerar Senha(s).

4. O Sistema valida as informações e gera as senhas.

Póscondições:


de geração e cadastro de Senhas com as Senhas geradas.








71

Caso de uso: Cadastrar Senha(s)




Fluxo de eventos:

1. O Administrador informa os dados da(s) Senha(s) e clica no botão

Inserir.


dados.

Póscondições:

1. Se a operação for realizada com sucesso é exibida tela de

visualização de senha(s) cadastrada(s) no banco de dados com a

mensagem de sucesso.








Caso de uso: Excluir Senha




72

Fluxo de eventos:


2. O Sistema exclui a Senha do banco de dados.

Póscondições:

1. Se a operação for realizada com sucesso é exibida a tela de busca

de Senhas com a mensagem de sucesso.






Caso de uso: Buscar Senha




Fluxo de eventos:

1. O Administrador clica no botão Buscar Senhas.

2. O Sistema exibe a tela de busca de Senhas.

3. O Administrador insere dados no filtro de busca e clica no botão

Buscar.

4. O Sistema realiza a busca das Senhas cadastradas.

Póscondições:

1. Se a operação for realizada com sucesso é exibida a tela de busca

de Senhas com o resultado da busca.

73






Tabela 10 Especificação do caso de uso Gerenciar Usuários Caso de uso: Gerenciar Usuários

Identificador: UC7.

Caso de uso: Listar Usuários




Fluxo de eventos:

1. O Administrador clica no botão Listar Usuários.

2. O Sistema realiza a listagem dos Usuários cadastrados.

Póscondições:


listagem de Usuários.






74

Caso de uso: Visualizar Usuário




Fluxo de eventos:


2. O Sistema recupera os dados do Usuário cadastrado.

Póscondições:


visualização de Usuário.






Caso de uso: Excluir Usuário




Fluxo de eventos:


2. O Sistema exclui o Usuário do banco de dados.

Póscondições:


75

listagem de Usuários.






Tabela 11 Especificação do caso de uso Gerenciar Aquisições Caso de uso: Gerenciar Aquisições

Identificador: UC8.

Caso de uso: Listar Aquisições




Fluxo de eventos:

1. O Administrador clica no botão Listar Aquisições.

2. O Sistema realiza a listagem das Aquisições cadastradas.

Póscondições:


listagem de Aquisições.





76


Caso de uso: Visualizar Aquisição




Fluxo de eventos:


2. O Sistema recupera os dados da Aquisição cadastrada.

Póscondições:


visualização de Aquisição.






Caso de uso: Excluir Aquisição




Fluxo de eventos:


2. O Sistema exclui a Aquisição do banco de dados.

Póscondições:

77


listagem de Aquisições.






Tabela 12 Especificação do caso de uso Logar no Sistema Caso de uso: Logar no Sistema

Identificador: UC9

Atores: Usuário WEB


Fluxo de eventos:

1. O Usuário WEB acessa o website.

2. O Sistema exibe a tela principal do website.

3. O Usuário WEB informa o nome de usuário e senha e clica no botão

Logar.

4. O Sistema valida os dados, efetua o login e armazena os valores na

sessão do usuário.

Póscondições:

1. Se a operação for realizada com sucesso é exibida a tela principal

do website novamente.


78


1. O Usuário WEB pode fechar a tela do navegador.


1. O Usuário WEB pode ir para outro website.

Tabela 13 Especificação do caso de uso Efetuar logout no Sistema Caso de uso: Efetuar logout no Sistema

Identificador: UC10



Fluxo de eventos:

1. O Usuário WEB clica no botão Logout.

2. O Sistema apaga os dados da sessão do usuário e exibe a tela

principal do website.

Póscondições: Nenhuma.





Tabela 14 Especificação do caso de uso Cadastrar Usuário Caso de uso: Cadastrar Usuário

Identificador: UC11


79


Fluxo de eventos:

1. O Usuário WEB clica no botão Cadastro.

2. O Sistema exibe a tela de cadastro.

3. O Usuário WEB informa os dados necessários e clica no botão

Cadastrar.

4. O Sistema valida as informações, armazena as informações no

banco de dados e cria uma sessão de usuário.

Póscondições:

1. Se a operação for realizada com sucesso é exibida a tela principal

do website novamente.







1. O Usuário WEB pode ir para outra área website.

Tabela 15 Especificação do caso de uso Alterar Cadastro Caso de uso: Alterar Cadastro

Identificador: UC12



80

Fluxo de eventos:

1. O Usuário WEB clica no botão Cadastro.

2. O Sistema carrega as informações do usuário e exibe a tela de

alteração de cadastro com as informações carregadas na tela.

3. O Usuário WEB informa os novos dados e clica no botão Alterar.

4. O Sistema valida as informações e armazena as mesmas no banco

de dados.

Póscondições:


sucesso de operação.







1. O Usuário WEB pode ir para outra área website.

Tabela 16 Especificação do caso de uso Processar download de Música Caso de uso: Processar download de Música

Identificador: UC13.

Caso de uso: Listar Discos cadastrados



81


Fluxo de eventos:

1. O Usuário WEB clica no botão Músicas.

2. O Sistema lista todos os Discos cadastrados no banco de dados.

Póscondições:

1. Se a operação for realizada com sucesso é exibida tela com a

listagem dos Discos.






Caso de uso: Listar Músicas cadastradas




Fluxo de eventos:

1. O Usuário WEB clica em um Disco listado na tela.

2. O Sistema lista todas as músicas cadastradas no Disco escolhido

pelo Usuário WEB.

Póscondições:

1. Se a operação for realizada com sucesso é exibida tela com a

listagem das Músicas do Disco.


82






1. O Usuário WEB pode ir para outra área do website.

Caso de uso: Exibir Download de Música




Fluxo de eventos:

1. O Usuário WEB clica no botão Download.

2. O Sistema carrega dados da Música escolhida e do Disco ao qual a

música pertence.

Póscondições:


download ao Usuário WEB.






Caso de uso: Download de Música


83



Fluxo de eventos:

1. O Usuário WEB informa a senha do MP3CARD e clica no botão

Download.

2. O sistema verificação se a senha é válida e a quantidade de créditos

da mesma.

3. O Sistema efetiva a aquisição no banco de dados.

4. O Sistema atualiza debita um crédito na senha.

Póscondições:

1. Se a operação for realizada com sucesso sistema retorna ao Usuário

WEB o arquivo de música para o download.






5.2.3. Realizações dos Casos de Uso Identificados.

Uma realização de caso de uso é em parte uma explicação de como

um caso de uso é implementado com os elementos do modelo específico ao qual

fazem parte (CONALLEN, 2003).

84

A seguir são ilustrados os diagramas de seqüência e de atividades

utilizados para a representação da realização dos casos de uso do sistema

desenvolvido neste trabalho.

5.2.3.1 Diagramas de Seqüência

Um diagrama de seqüência descreve o comportamento dos objetos

do sistema os quais se relacionam entre si por meio de troca de mensagens.

83

Abaixo são ilustrados os diagramas de seqüência criados durante o desenvolvimento deste trabalho.

Figura 20 – Diagrama de Seqüência Logar Administrador no Sistema

84

Figura 21 – Diagrama de Seqüência Administrador Efetuar Logout

85

Figura 22 Diagrama de Seqüência Alterar senha de Administrador

86

Figura 23 Diagrama de Seqüência Cadastrar Disco

87

Figura 24 Diagrama de Seqüência Alterar Disco

88

Figura 25 Diagrama de Seqüência Excluir Disco

89

Figura 26 Diagrama de Seqüência Listar Discos

90

Figura 27 Diagrama de Seqüência Cadastrar Música

91

Figura 28 Diagrama de Seqüência Alterar Música

92

Figura 29 Diagrama de Seqüência Excluir Música

93

Figura 30 Diagrama de Seqüência Listar Músicas

94

Figura 31 Diagrama de Seqüência Visualizar Música

95

Figura 32 Diagrama de Seqüência Gerar Senha(s)

96

Figura 33 Diagrama de Seqüência Cadastrar Senha(s)

97

Figura 34 Diagrama de Seqüência Excluir Senha

98

Figura 35 Diagrama de Seqüência Buscar Senha

99

Figura 36 Diagrama de Seqüência Listar Usuários

100

Figura 37 Diagrama de Seqüência Visualizar Usuário

101

Figura 38 Diagrama de Seqüência Excluir Usuário

102

Figura 39 Diagrama de Seqüência Listar Aquisições

103

Figura 40 Diagrama de Seqüência Visualizar Aquisição

104

Figura 41 Diagrama de Seqüência Excluir Aquisição

105

Figura 42 Diagrama de Seqüência Logar no Sistema

106

Figura 43 Diagrama de Seqüência Efetuar logout no Sistema

107

Figura 44 Diagrama de Seqüência Cadastrar Usuário

108

Figura 45 Diagrama de Seqüência Alterar Cadastro

109

Figura 46 Diagrama de Seqüência Listar Discos cadastrados

110

Figura 47 Diagrama de Seqüência Listar Músicas cadastradas

111

Figura 48 Diagrama de Seqüência Exibir Download de Música

111

Figura 49 Diagrama de Seqüência Download de Música

112

5.2.3.2 Diagramas de Atividades

Objetivando documentar e detalhar o fluxo dentro dos casos de uso

identificados no desenvolvimento do sistema, foram criados os diagramas de

atividades ilustrados a seguir:

Figura 50 – Diagrama de Atividade Logar Administrador no Sistema – Referente ao caso de uso UC1.

113

Figura 51 – Diagrama de Atividade Alterar senha de Administrador – Referente ao caso de uso UC3.

114

Figura 52 – Diagrama de Atividade Cadastrar Disco – Referente ao caso de uso UC4.1.

115

Figura 53 – Diagrama de Atividade Alterar Disco – Referente ao caso de uso UC4.2.

116

Figura 54 – Diagrama de Atividade Excluir Disco – Referente ao caso de uso UC4.3.

117

Figura 55 – Diagrama de Atividade Cadastrar Música – Referente ao caso de uso UC5.1.

118

Figura 56 – Diagrama de Atividade Alterar Música – Referente ao caso de uso UC5.2.

119

Figura 57 – Diagrama de Atividade Excluir Música – Referente ao caso de uso UC5.3.

Figura 58 – Diagrama de Atividade Listar Músicas – Referente ao caso de uso UC5.4.

120

Figura 59 – Diagrama de Atividade Visualizar Música – Referente ao caso de uso UC5.5.

121

Figura 60 – Diagrama de Atividade Gerar Senha(s) – Referente ao caso de uso UC6.1.

122

Figura 61 – Diagrama de Atividade Cadastrar Senha(s) – Referente ao caso de uso UC6.2.

123

Figura 62 – Diagrama de Atividade Excluir Senha – Referente ao caso de uso UC6.3.

124

Figura 63 – Diagrama de Atividade Buscar Senha – Referente ao caso de uso UC6.4.

125

Figura 64 – Diagrama de Atividade Visualizar Usuário – Referente ao caso de uso UC7.2.

126

Figura 65 – Diagrama de Atividade Excluir Usuário – Referente ao caso de uso UC7.3.

127

Figura 66 – Diagrama de Atividade Listar Aquisições – Referente ao caso de uso UC8.1.

128

Figura 67 – Diagrama de Atividade Visualizar Aquisição – Referente ao caso de uso UC8.2.

129

Figura 68 – Diagrama de Atividade Excluir Aquisição – Referente ao caso de uso UC8.3.

130

Figura 69 – Diagrama de Atividade Logar no Sistema – Referente ao caso de uso UC9.

131

Figura 70 – Diagrama de Atividade Cadastrar Usuário – Referente ao caso de uso UC11.

132

Figura 71 – Diagrama de Atividade Alterar cadastro – Referente ao caso de uso UC12.

Figura 72 – Diagrama de Atividade Listar Discos cadastrados – Referente ao caso de uso UC13.1.

133

Figura 73 – Diagrama de Atividade Listar Músicas cadastradas – Referente ao caso de uso UC13.2.

134

Figura 74 – Diagrama de Atividade Exibir Download de Música – Referente ao caso de uso UC13.3.

135

Figura 75 – Diagrama de Atividade Download de Música – Referente ao caso de uso UC13.4.

5.2.4 Diagrama de Classes

O objetivo do diagrama de classes é modelar a visão estática do

sistema por meio de um conjunto de classes e seus relacionamentos.

Neste digrama representado na Figura 76, estão representadas apenas as classes

que fazem parte da camada de negócios do sistema. As demais classes do sistema

podem ser encontradas no diagrama de componentes na seção 5.3.1.

137

Figura 76 – Diagrama de Classes de Projeto

138

5.3. CONSTRUÇÃO

Ao contrário das fases de concepção e elaboração, que foram

realizadas objetivando à modelagem do sistema, nesta fase as atividades realizadas

objetivaram o desenvolvimento do sistema proposto.

O trabalho desta fase foi iniciado baseado na arquitetura produzida

pela fase anterior (Elaboração). As iterações e incrementos foram realizados com o

objetivo de completar o modelo de requisitos, análise e projeto.

Nesta fase além da implementação do sistema, foi elaborado o

diagrama de componentes para modelar os aspectos físicos do sistema

demonstrando a configuração do mesmo, ou seja, como as partes e a camadas do

sistema se relacionam.

5.3.1 Diagrama de Componentes

A seguir é ilustrado o diagrama de componentes com o objetivo de

demonstrar como os componentes e as camadas do sistema desenvolvido neste

trabalho se relacionam.

139

Figura 77 – Diagrama de Componentes

5.3.2 Modelo EntidadeRelacionamento

O modelo de dados entidaderelacionamento tem por base a

percepção do mundo real como um conjunto de objetos básicos,

140

chamados entidades, e do relacionamento entre eles. Além das entidades e dos relacionamentos, o modelo entidade

relacionamento representa certas regras, as quais o conteúdo do banco de dados precisa respeitar [KORTH; SILBERSCHATZ;

SUDARSHAN, 1999].

A Figura 78 ilustra o Modelo EntidadeRelacionamento do sistema desenvolvido neste trabalho.

FAIXA

MUSICAS

IDMUSICA IDDISCO NOMEMUSICA

PATHMUSICA

IMAGEM DISCOS

IDDISCO NOMEDISCO

ANO

TEM

1

N

SENHA

SENHAS

QTDECREDITOS DATACRIACAO

IDSENHA

QTDECREDITOSATUAL

LOCALDISTRIB

USUARIOS

EMAIL

IDUSUARIO

SENHA

USUARIO

NOME

TELEFONE

DATANASC ONDEADQUIRIU TIPO

AQUISICOES

IDUSUARIO IDMUSICA

IDAQUISICAO

IDSENHA

DATA

ESTÁ N 1

FAZ N 1

ESTÁ

N

1

Figura 78 – Modelo EntidadeRelacionamento

141

5.3.3. Testes

5.3.3.1 Teste de Caixa Preta

Os métodos de teste de caixa preta concentramse nos requisitos

funcionais do software, ou seja, esse teste possibilita que o engenheiro de software

derive conjuntos de condições de entrada que exercitem completamente todos os

requisitos funcionais para um programa [PRESSMAN, 1995].

Os testes de caixa preta foram realizados buscando atingir os

seguintes objetivos:

• Funções ausentes ou incorretas

• Erros na interface

• Erros nas estruturas

• Erros de inicialização e término

Abaixo seguem as tabelas que especificam os casos de testes

realizados no desenvolvimento deste trabalho.

Tabela 17 – Caso de Teste Logar Administrador no Sistema Caso de teste: Logar Administrador no Sistema

Identificador: TC1

Descrição: Por meio deste caso de uso o usuário administrador deverá

acessar o sistema.

Responsável: Alberto Luiz da Silva

Caso de uso: UC1

Abordagem: Caixa Preta

142

Técnica: Manual

Précondições: Nenhuma.

Passos:

1. Acessar a página de login de administrador.

2. Informa usuário e senha de administrador.

3. Clicar no botão Logar.

Póscondições:

1. Se a operação for realizada com sucesso e o usuário administrador

informar dados corretos, o mesmo será redirecionado a tela com o


2. Caso contrário o usuário administrador será redirecionado para uma

página de erro.

Tabela 18 – Caso de Teste Administrador Efetuar Logout Caso de teste: Administrador Efetuar Logout

Identificador: TC2

Descrição: Por meio deste caso de uso o usuário administrador deverá

efetuar o logout no sistema.


Caso de uso: UC2


Técnica: Manual


Passos:

143

1. Clicar no botão Logout.

Póscondições:

1. O usuário administrador será redirecionado a tela de login de

administrador.

Tabela 19 – Caso de Teste Alterar senha de Administrador Caso de teste: Alterar senha de Administrador

Identificador: TC3

Descrição: Por meio deste caso de uso o usuário administrador poderá

alterar a senha do seu usuário.


Caso de uso: UC3


Técnica: Manual


Passos:

1. Clicar no botão Alterar Senha do menu de administração.

2. Informar a senha atual, a nova senha e a confirmação da nova

senha.

3. Clicar no botão Alterar.

Póscondições:


informar dados corretos, o mesmo será redirecionado a tela com o

144



página de erro.

Tabela 20 – Caso de Teste Cadastrar Disco Caso de teste: Cadastrar Disco

Identificador: TC4


cadastrar um Disco no Sistema.


Caso de uso: UC4.1


Técnica: Manual


Passos:

1. Clicar no botão Inserir Disco do menu de administração.

2. Informar os dados do Disco que será cadastrado.

3. Clicar no botão Inserir.

Póscondições:


informar dados corretos, o mesmo será redirecionado novamente a tela

de inserção de Disco.


página de erro.

145

Tabela 21 – Caso de Teste Alterar Disco Caso de teste: Alterar Disco

Identificador: TC5


alterar o cadastro de um Disco no Sistema.


Caso de uso: UC4.2


Técnica: Manual


Passos:

1. Clicar em um botão Alterar na tela de listagem de Discos.

2. Informar os novos dados do Disco que será alterado.


Póscondições:



de alteração de Disco.


página de erro.

Tabela 22 – Caso de Teste Excluir Disco Caso de teste: Excluir Disco

Identificador: TC6


146

excluir um Disco do Sistema.


Caso de uso: UC4.3


Técnica: Manual


Passos:

1. Clicar em um botão Excluir na tela de listagem de Discos.

Póscondições:

1. Se a operação for realizada com sucesso o usuário administrador

será redirecionado novamente a tela de listagem de Discos.


página de erro.

Tabela 23 – Caso de Teste Listar Discos Caso de teste: Listar Discos

Identificador: TC7


listar os Discos cadastrados no Sistema.


Caso de uso: UC4.4


Técnica: Manual

147


Passos:

1. Clicar no botão Listar Discos do menu de administração.

Póscondições:


será redirecionado a tela de listagem de Discos.


página de erro.

Tabela 24 – Caso de Teste Cadastrar Música Caso de teste: Cadastrar Música

Identificador: TC8


cadastrar uma Música no Sistema.


Caso de uso: UC5.1


Técnica: Manual


Passos:

1. Clicar no botão Inserir Música do menu de administração.

2. Informar os dados da Música que será cadastrada.


Póscondições:

148



de inserção de Música.


página de erro.

Tabela 25 – Caso de Teste Alterar Música Caso de teste: Alterar Música

Identificador: TC9


alterar o cadastro de uma Música no Sistema.


Caso de uso: UC5.2


Técnica: Manual


Passos:

1. Clicar em um botão Alterar na tela de listagem de Músicas.

2. Informar os novos dados da Música que será alterada.


Póscondições:



de alteração de Música.

149


página de erro.

Tabela 26 – Caso de Teste Excluir Música Caso de teste: Excluir Música

Identificador: TC10


excluir uma Música do Sistema.


Caso de uso: UC5.3


Técnica: Manual


Passos:

1. Clicar em um botão Excluir na tela de listagem de Músicas.

Póscondições:


será redirecionado novamente a tela de listagem de Músicas.


página de erro.

Tabela 27 – Caso de Teste Listar Músicas Caso de teste: Listar Músicas

Identificador: TC11

150


listar a Músicas cadastradas no Sistema.


Caso de uso: UC5.4


Técnica: Manual


Passos:

1. Clicar no botão Listar Músicas do menu de administração.

Póscondições:


será redirecionado a tela de listagem de Músicas.


página de erro.

Tabela 28 – Caso de Teste Visualizar Música Caso de teste: Visualizar Música

Identificador: TC12


visualizar uma Música cadastrada no Sistema.


Caso de uso: UC5.5


151

Técnica: Manual

Précondições: Ter realizado o caso de uso UC5.4

Passos:

1. Clicar em um botão Visualizar na tela de listagem de Músicas.

Póscondições:


será redirecionado a tela de visualização de Música.


página de erro.

Tabela 29 – Caso de Teste Gerar Senha(s) Caso de teste: Gerar Senha(s)

Identificador: TC13


gerar Senhas que serão utilizadas nos cartões MP3CARD’s.


Caso de uso: UC6.1


Técnica: Manual


Passos:

1. Clicar no botão Gerar Senhas do menu de administração.

2. Informar o número de Senhas que serão geradas.

3. Clicar no botão Gerar Senhas.

152

Póscondições:


será redirecionado novamente a tela de geração de Senhas com a lista

de Senhas geradas.


página de erro.

Tabela 30 – Caso de Teste Cadastrar Senha(s) Caso de teste: Cadastrar Senha(s)

Identificador: TC14


cadastrar Senhas no sistema.


Caso de uso: UC6.2


Técnica: Manual


Passos:

1. Informar os dados das Senhas que serão cadastradas.


Póscondições:


será redirecionado a tela de visualização de Senhas cadastradas com

a lista de Senhas que foram cadastradas na operação.

153


página de erro.

Tabela 31 – Caso de Teste Excluir Senha Caso de teste: Excluir Senha

Identificador: TC15


excluir uma Senha do Sistema.


Caso de uso: UC6.3


Técnica: Manual


Passos:

1. Clicar em um botão Excluir na tela de listagem de Senhas.

Póscondições:


será redirecionado novamente a tela de busca de Senhas.


página de erro.

Tabela 32 – Caso de Teste Buscar Senha Caso de teste: Buscar Senha

Identificador: TC16

154


buscar uma Senha cadastrada no Sistema por meio de um filtro de busca.


Caso de uso: UC6.4


Técnica: Manual


Passos:

1. Clicar no botão Buscar Senhas do menu de administração.

2. Informar os dados da Senha no filtro de busca.

3. Clicar no botão Buscar.

Póscondições:


será redirecionado novamente a tela de busca de Senhas com o

resultado da busca realizada.


página de erro.

Tabela 33 – Caso de Teste Listar Usuários Caso de teste: Listar Usuários

Identificador: TC17


listar os Usuários cadastrados no Sistema.


155

Caso de uso: UC7.1


Técnica: Manual


Passos:

1. Clicar no botão Listar Usuários do menu de administração.

Póscondições:


será redirecionado a tela de listagem de Usuários.


página de erro.

Tabela 34 – Caso de Teste Visualizar Usuário Caso de teste: Visualizar Usuário

Identificador: TC18


visualizar um Usuário cadastrado no Sistema.


Caso de uso: UC7.2


Técnica: Manual


Passos:

1. Clicar em um botão Visualizar na tela de listagem de Usuários.

156

Póscondições:


será redirecionado a tela de visualização de Usuário.


página de erro.

Tabela 35 – Caso de Teste Excluir Usuário Caso de teste: Excluir Usuário

Identificador: TC19


excluir um Usuário do Sistema.


Caso de uso: UC7.3


Técnica: Manual


Passos:

1. Clicar em um botão Excluir na tela de listagem de Usuários.

Póscondições:


será redirecionado novamente a tela de listagem de Usuários.


página de erro.

157

Tabela 36 – Caso de Teste Listar Aquisições Caso de teste: Listar Aquisições

Identificador: TC20


listar as Aquisições cadastradas no Sistema.


Caso de uso: UC8.1


Técnica: Manual


Passos:

1. Clicar no botão Listar Aquisições do menu de administração.

Póscondições:


será redirecionado a tela de listagem de Aquisições.


página de erro.

Tabela 37 – Caso de Teste Visualizar Aquisição Caso de teste: Visualizar Aquisição

Identificador: TC21


visualizar uma Aquisição cadastrada no Sistema.


158

Caso de uso: UC8.2


Técnica: Manual


Passos:

1. Clicar em um botão Visualizar na tela de listagem de Aquisições.

Póscondições:


será redirecionado a tela de visualização de Aquisição.


página de erro.

Tabela 38 – Caso de Teste Excluir Aquisição Caso de teste: Excluir Aquisição

Identificador: TC22


excluir uma Aquisição do Sistema.


Caso de uso: UC8.3


Técnica: Manual


Passos:

1. Clicar em um botão Excluir na tela de listagem de Aquisições.

159

Póscondições:


será redirecionado novamente a tela de listagem de Aquisições.


página de erro.

Tabela 39 – Caso de Teste Logar no Sistema Caso de teste: Logar no Sistema

Identificador: TC23

Descrição: Por meio deste caso de uso o usuário deverá acessar o

sistema.


Caso de uso: UC9


Técnica: Manual

Précondições: Possuir cadastro no sistema.

Passos:

1. Acessar a página principal do Sistema.

2. Informa nome usuário e senha.

3. Clicar no botão Logar.

Póscondições:

1. Se a operação for realizada com sucesso e o usuário informar dados

corretos, o mesmo será redirecionado novamente a tela principal do

Sistema.

160

2. Caso contrário o usuário será redirecionado para uma página de

erro.

Tabela 40 – Caso de Teste Efetuar Logout no Sistema Caso de teste: Efetuar Logout no Sistema

Identificador: TC24

Descrição: Por meio deste caso de uso o usuário deverá efetuar o logout

no sistema.


Caso de uso: UC10


Técnica: Manual


Passos:

3. Clicar no botão Logout.

Póscondições:

1. O usuário será redirecionado a tela principal do Sistema.

Tabela 41 – Caso de Teste Cadastrar Usuário Caso de teste: Cadastrar Usuário

Identificador: TC25

Descrição: Por meio deste caso de uso o usuário poderá se cadastrar no

Sistema.

161


Caso de uso: UC11


Técnica: Manual

Précondições: Acessar a página principal do Sistema.

Passos:

1. Clicar no botão Cadastro.

2. Informar os dados do usuário que será cadastrado.

3. Clicar no botão Cadastrar.

Póscondições:


corretos, o mesmo será redirecionado a tela de sucesso de operação.


erro.

Tabela 42 – Caso de Teste Alterar Cadastro Caso de teste: Alterar Cadastro

Identificador: TC26

Descrição: Por meio deste caso de uso o usuário poderá alterar o

cadastro do mesmo no Sistema.


Caso de uso: UC12


Técnica: Manual

162


Passos:

1. Clicar no botão Cadastro.

2. Informar os novos dados do usuário cadastrado.


Póscondições:


corretos, o mesmo será redirecionado a tela de sucesso de operação.


erro.

Tabela 43 – Caso de Teste Listar Discos cadastrados Caso de teste: Listar Discos cadastrados

Identificador: TC27

Descrição: Por meio deste caso de uso o usuário poderá listar os Discos

cadastrados no Sistema.


Caso de uso: UC13.1


Técnica: Manual


Passos:

1. Clicar no botão Músicas.

Póscondições:

163

1. Se a operação for realizada com sucesso o usuário será

redirecionado a tela de listagem de Discos cadastrados no Sistema.


erro.

Tabela 44 – Caso de Teste Listar Músicas cadastradas Caso de teste: Listar Músicas cadastradas

Identificador: TC28

Descrição: Por meio deste caso de uso o usuário poderá listar as Músicas

cadastradas no Sistema.


Caso de uso: UC13.2


Técnica: Manual


Passos:

1. Clicar no botão referente a um Disco listado na tela.

Póscondições:


redirecionado a tela de listagem de Músicas cadastradas para o Disco

selecionado no Sistema.


erro.

164

Tabela 45 – Caso de Teste Exibir Download de Música Caso de teste: Exibir Download de Música

Identificador: TC29

Descrição: Por meio deste caso de uso o usuário poderá visualizar a de

download de Música cadastrada no Sistema.


Caso de uso: UC13.3


Técnica: Manual


Passos:

1. Clicar no botão Download referente a uma listada na tela.

Póscondições:


redirecionado a tela de Download de Música cadastrada.


erro.

Tabela 46 – Caso de Teste Download de Música Caso de teste: Download de Música

Identificador: TC30

Descrição: Por meio deste caso de uso o usuário poderá realizar o

download de uma Música cadastrada no Sistema.

165


Caso de uso: UC13.4


Técnica: Manual


Passos:

1. Inserir a senha do MP3CARD.

2. Clicar no botão Download.

Póscondições:

1. Se a operação for realizada com sucesso o usuário receberá a

Música para download na tela de download do navegador.


erro.

5.4. TRANSIÇÃO

Esta fase tem como objetivo estabelecer o produto desenvolvido

durante a execução do trabalho no ambiente operacional. Assim a partir da

disponibilização da versão beta do sistema é possível a avaliar se o sistema

desenvolvido cumpre as necessidades do usuário e não possui falhas ou

ambigüidades na documentação gerada.

Conforme os resultados, o sistema ou a documentação do mesmo

pode ser modificada. Essas modificações não têm o objetivo de reformular o

sistema, e sim de ajustar algum detalhe que passou despercebido na fase de

construção.

166

A fase de transição é concluída com a entrega da versão final do

sistema desenvolvido.

Sendo assim, esta fase não foi concluída até a presente data de

publicação deste trabalho, pois o sistema desenvolvido necessita de um provedor de

serviços de hospedagem de websites para que seja possível a sua implantação. A

contratação desse serviço não está no escopo deste trabalho.

167

6 CRONOGRAMA

Abaixo segue o cronograma de execução que foi seguido durante

este trabalho.

Este cronograma difere do cronograma proposto, pois por motivos

pessoais não foi realizado nenhum trabalho nos meses de setembro, outubro e início

de novembro. Isso acarretou na extensão dos trabalhos até o mês de Fevereiro.

Tabela 47 – Cronograma de Execução Mai Jun Jul Ago Set Out Nov Dez Jan Fev

Requisitos Análise Projeto

Implementação Teste

Concepção Elaboração Construção 1 Iteração 2 Iterações 2 Iterações

Na Tabela 48 estão representadas as atividades realizadas durante

o desenvolvimento deste trabalho.

Tabela 48 – Cronograma de Atividades Mai Jun Jul Ago Set Out Nov Dez Jan Fev

Estudo sobre as tecnologias

utilizadas no projeto

Desenvolvimento

Redação do trabalho de

diplomação

168

7 RECURSOS ALOCADOS

Para o desenvolvimento deste trabalho foram alocados os seguintes

recursos de software e hardware

• Recursos de software

J2EE 1.4 SDK

Eclipse 3.0

Firebird 1.5

Jude 1.3

Erwin 4.0

Macromedia Dreamweaver MX

Macromedia Flash MX

Microsoft Word 2000

• Recursos de hardware

Microcomputador Intel Pentium IV 1.7GHz, 256 RAM, 40 GB

de disco rígido.

169

8 CONCLUSÃO

No desenvolvimento deste trabalho foi possível estudar e aplicar na

prática todo o conceito de processo de desenvolvimento de software e também os

conceitos estudados durante toda a graduação.

Durante o trabalho foi possível obter uma maior compreensão de

como são realizados todo o processo de análise e projeto de um sistema, e o quão é

complexo este processo.

Foi possível analisar também o quanto é útil a utilização de uma

metodologia de desenvolvimento de software junto com um processo de

desenvolvimento de software, neste caso o UP. Isso proporcionou uma melhor

organização no desenvolvimento do trabalho.

O sistema obtido ao final deste trabalho pode ser aplicado como

uma solução viável para bandas e gravadoras que buscam uma solução para o

aumento da violação dos direitos autorais na internet e redução do custo e preço

final de um CD musical para o consumidor. Mas é importante lembrar que esse a

violação de direitos autorais na internet não será solucionada com a apresentação

de uma solução por meio de um software, pois o mesmo não é um simples problema

tecnológico, e sim uma questão de cultura.

170

9 TRABALHOS FUTUROS

Com conclusão deste trabalho é possível analisar e buscar novas

melhorias para o sistema desenvolvido.

Algumas idéias foram surgindo durante a realização do trabalho,

mas não foram aplicadas para não desviar do objetivo inicial do mesmo. Essas

idéias e um estudo melhor sobre as questões que envolvem essa área da internet

proporcionará a aplicação futura de melhorias no sistema desenvolvido neste

trabalho.

Desse modo, está sendo em estudo a viabilidade de criação de uma

aplicação que integre o sistema já desenvolvido com um software (player) de

arquivos mp3.

171

10 REFERÊNCIAS

1. ALUR, D.; CRUPI, J.; MALKS, D. Core J2EE Patterns: As melhores práticas e

estratégias de design. 2. ed. Rio de Janeiro: Campus, 2004.

2. GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J. Padrões de Projeto:

Soluções reutilizáveis de software orientado a objetos. 1. ed. Porto Alegre: Bookman,

2002.

3. CONALLEN, J. Desenvolvendo Aplicações Web Com UML. 2. ed. Rio de

Janeiro: Campus, 2003.

4. ARLOW, J.; NEUSTADT, I. UML and the Unified Process: Pratical object

oriented analysis & design. 1. ed. Londres: Addinson Wesley, 2002.

5. KORTH, H. F.; SILBERSCHATZ, A.; SUDARSHAN, S. Sistema de Banco de

Dados. 3. ed. São Paulo: Makron Books, 1999.

6. PRESSMAN, R. S. Engenharia de Software. 3. ed. São Paulo: Makron Books,

1995.

7. CONALLEN, J. Modeling Web Application Architectures with UML,

Communications of the ACM, v.42, n.10, pp. 6370, Outubro 1999.

8. CARLSON, D. Modelagem de Aplicações XML com UML: Aplicações práticas

de ebusiness. 1. ed. São Paulo: Makron Books, 2002

172

9. TANENBAUM, A. S. Redes de Computadores. 3. ed. Rio de Janeiro: Campus,

1997.

10. GUEIROS, N. J. Download: Troca de arquivos de músicas na Internet chegou

para ficar. Disponível em <http://conjur.estadao.com.br/static/text/30384,1>. Acesso

em: 12 dez. 2005.

173

APÊNDICE A – PROPOSTA DO TRABALHO DE DIPLOMAÇÃO

174

MINISTÉRIO DA EDUCAÇÃO CENTRO FEDERAL DE EDUCAÇÃO TECNOLÓGICA DO PARANÁ UNIDADE DE CORNÉLIO PROCÓPIO CURSO SUPERIOR DE TECNOLOGIA EM INFORMÁTICA


Sistema de vendas de música na internet através de cartão “MP3

CARD”

Cornélio Procópio 2005

175

MINISTÉRIO DA EDUCAÇÃO CENTRO FEDERAL DE EDUCAÇÃO TECNOLÓGICA DO PARANÁ UNIDADE DE CORNÉLIO PROCÓPIO CURSO SUPERIOR DE TECNOLOGIA EM INFORMÁTICA



CARD”

Proposta para a disciplina Trabalho de Diplomação do curso Tecnologia em Informática orientado pelo professor Fabrício Martins Lopes

Cornélio Procópio 2005

176

LISTA DE FIGURAS

Figura 01 – Exemplo de um “Mp3 Card” ........................................... 183

177

LISTA DE TABELAS

Tabela 01 – Cronograma de atividades ............................................... 189

Tabela 01 – Cronograma de execução ................................................ 189

178

LISTA DE ABREVIATURAS E SIGLAS

TCP/IP Transmission Control Protocol/Internet Protocol

MP3 MPEG Audio Layer3

MPEG Moving Picture Experts Group

CD’s Compact Disc

SP São Paulo

CD Compact Disc

UP Processo Unificado

UML Unified Modeling Language

RUP Rational Unified Process

JSP Java Server Pages

HTTPS HyperText Transmission Protocol, Secure

HTTP HyperText Transmission Protocol

179

SUMÁRIO

1 TÍTULO ............................................................................................................180

2 INTRODUÇÃO .................................................................................................181

3 OBJETIVO .......................................................................................................183

4 JUSTIFICATIVAS.............................................................................................185

5 METODOLOGIA ..............................................................................................186

5.1 Estudo sobre as tecnologias utilizadas no projeto .........................................186

5.2 Desenvolvimento ...........................................................................................186

5.3 Redação do Trabalho de Diplomação............................................................188

6. CRONOGRAMA...............................................................................................189

6.1 Cronograma de atividades.............................................................................189

6.2 Cronograma de execução..............................................................................189

7 RECURSOS NECESSÁRIOS ..........................................................................190

8 REFERÊNCIAS BIBLIOGRAFICAS.................................................................191

180

1 TÍTULO


CARD”

181

2 INTRODUÇÃO

A internet começou a nascer no final da década de 1950 e inicio da

década de 1960 com o desejo do Departamento de Defesa do Estados Unidos de se

ter uma rede de controle e comunicação que conseguisse resistir a uma guerra

nuclear. Pois até aquele momento toda a comunicação era feita pelo sistema

telefônico, o qual os americanos consideram ser muito vulnerável.

Com o passar dos anos, a “rede” passou a ser utilizada também por

universidades a fim de permitir uma comunicação mais eficiente entre pesquisadores

de diferentes instituições acadêmicas americanas, a fim de permitir a troca de

informações sobre pesquisas realizadas em diferentes lugares do país.

O sucesso da internet era tão grande, que depois de algum tempo a

rede também foi disponibilizada para o acesso de pessoas comum, que não

tivessem interesse nenhum em pesquisas acadêmicas, e queriam apenas se

comunicar e obter informações na rede.

Depois que o protocolo TCP/IP se tornou o primeiro protocolo oficial

da rede, o número de usuários aumentou de forma exponencial, proporcionando a

popularização da internet e aumentando o número de serviços disponíveis na

mesma. Hoje um usuário comum pode ter acesso via internet a sua conta bancária,

fazer compras, participar de leilões, ver notícias em tempo real, trocar arquivos,

escutar músicas, ver filmes, e até comprar carros.

Mas a popularização da internet também trouxe ao usuário a

necessidade de uma maior prudência e responsabilidade quanto ao uso da rede, já

que a facilidade de acessar dados confidenciais de pessoas e violação de direitos

aumentou muito. Uma grande preocupação atualmente é a facilidade com que os

182

usuários podem adquirir músicas sem terem que pagar pelos direitos autorais das

mesmas.

O propósito desse trabalho de diplomação é desenvolver um sistema

de aquisição de músicas pela internet de forma legal, através da compra de um

cartão “raspinha” comprado em lojas ou ganhado em shows musicais.

183

3 OBJETIVO

Este trabalho tem como objetivo desenvolver um sistema de

aquisição de músicas mp3 via internet através de uma senha que está impressa em

um cartão “raspinha” que poderá ser comprado em lojas de venda de cd’s musicais

ou ganhados em shows musicais.

Nesse cartão “MP3 CARD” estará impressa uma senha, que dá

direito ao usuário de “baixar” uma ou mais músicas do website, dependendo de

quantos créditos possui o cartão, e independente de álbum musical. Essa senha é

única e é gerada aleatoriamente pelo sistema e depois passada a gráfica para a

impressão dos cartões “raspinhas”.

Figura 01 – Exemplo de um “Mp3 Card”

O desenvolvimento do sistema será dividido em três módulos:

módulo de administração de criação de senhas e cadastros de usuários, módulo de

gerenciamento de músicas disponíveis no website, e módulo de aquisição de

músicas e cadastro de clientes.

No módulo de administração de criação de senhas e cadastros de

usuários, o administrador do website poderá gerar senhas para os cartões, definir a

quantidade de créditos para cada senha e verificar quais senhas já foram utilizadas

e por quem foram utilizadas.

184

No segundo módulo, o administrador poderá adicionar e remover

arquivos de músicas disponíveis aos usuários.

O terceiro módulo será responsável pela criação do formulário de

cadastro de clientes do website, disponibilizar uma sessão de login e aquisição de

arquivos de músicas.

185

4 JUSTIFICATIVAS

Tendo em vista a viabilidade deste projeto, foi detectado o interesse

de um grupo de músicos que se interessaram em contribuir com a proposta. Músicos

profissionais da banda Gigahertz (São Paulo – SP) têm manifestado seu interesse e

estão colaborando ativamente para o desenvolvimento do projeto. Esta colaboração

tem ocorrido na forma de sugestões sobre a forma com que a banda deseja utilizar

esse sistema.

Com a banda Gigahertz utilizando esse sistema, o custo de

aquisição de músicas para o consumidor ficará mais baixo. Pois o cd não precisaria

ser gravado e colocado em uma capa protetora com um encarte, além do fato de

que o consumidor não precisaria pagar por um cd com 15 músicas e que interessam

a ele apenas 05 músicas.

186

5. METODOLOGIA

Este trabalho de diplomação será desenvolvido seguindo as

seguintes etapas:

1 – Estudo sobre as tecnologias utilizadas no projeto;

2 – Desenvolvimento;

3 – Redação do Trabalho de Diplomação.

5.1 Estudo sobre as tecnologias utilizadas no projeto

Está etapa se dará durante toda a realização do trabalho de

diplomação em paralelo com as outras etapas. Pois a necessidade de leitura,

aumento e refinamento do conhecimento sobre os assuntos do trabalho de

diplomação é constante.

5.2 Desenvolvimento

O desenvolvimento dos módulos do trabalho de diplomação será

baseado no Processo Unificado de desenvolvimento de sistemas (UP) utilizando a

notação UML (Linguagem de Modelagem Unificada) com extensão para a internet.

A escolha do Processo Unificado para ser o processo responsável

pelo desenvolvimento do sistema deuse ao fato de que este processo:

• É iterativo incremental;

• Está intimamente ligado a UML;

• Não ser tão complexo quanto o RUP (Rational Unified Process).

187

O Processo Unificado é divido em quatro fases: Concepção,

Elaboração, Construção e Transição. Em cada fase deste projeto pode existir uma

ou mais iterações que são composta por cinco atividades: Requisitos, Análise

Projeto, Implementação e Teste.

Conforme o desenvolvimento do projeto, serão gerados os seguintes

artefatos na execução das atividades:

Requisitos:

o Levantamento dos requisitos não funcionais e funcionais;

o Levantamento dos atores e caso de uso;

o Especificação de casos de uso;

o Diagrama de caso de uso;

Análise:

o Diagrama de seqüência;

o Diagrama de atividades;

Projeto:

o Diagrama de classes;

o Diagrama de pacotes;

Implementação:

o Codificação do sistema;

o Diagrama de componentes;

Teste:

o Caixa preta;

O sistema será implementado na linguagem de programação Java e

JSP para a criação dos arquivos do website.

188

Para uma maior segurança dos usuários do sistema, será utilizado

criptografia para a geração de senhas dos cartões através do método de chaves

públicas e chaves privadas. Esse suporte a criptografia já está incluso na ferramenta

j2eesdk1.4.

Toda a comunicação entre o browser do usuário e o servidor Web

será feita atreves do protocolo de comunicação HTTPS, o qual é muito similar com o

protocolo HTTP, se diferenciando na comunicação criptografada entre o browser e o

servidor. A implementação deste protocolo será feita através do servidor de

aplicação utilizado no projeto (Apache Tomcat 4.1).

O banco de dados definido para ser utilizado durante o

desenvolvimento do trabalho de diplomação foi o Firebird 1.5. A escolha levou em

consideração o fato do banco de dados ser free e open source.

5.3 Redação do Trabalho de Diplomação

Esta atividade levará em consideração além das bibliografias

estudadas, os textos e rascunhos gerados nas reuniões com o orientador e com os

profissionais da área musical como suporte a escrita da redação final.

189

6. CRONOGRAMA

6.1 Cronograma de atividades

Mai Jun Jul Ago Set Out Nov Dez

Estudo sobre as tecnologias

utilizadas no projeto

Desenvolvimento

Redação do trabalho de diplomação

Tabela 01 – Cronograma de atividades

6.2 Cronograma de execução

Mai Jun Jul Ago Set Out Nov Dez

Requisitos

Análise

Projeto

Implementação

Teste

Tabela 02 – Cronograma de execução

Iteração 1 – Módulo de administração de criação de senhas e cadastros de

usuários.

Iteração 2 – Módulo de gerenciamento de músicas disponíveis no website.

Iteração 3 – Módulo de aquisição de músicas e cadastro de clientes.

Iteração 4 – Revisão e possíveis correções e melhorias.

190

7 RECURSOS NECESSÁRIOS

Recursos de software:

J2eesdk 1.4.02

Eclipse 3.0

Firebird 1.5

Argo UML 0.16

Dreamweaver Mx

Recursos de hardware:

Microcomputador Intel Pentium IV 1.7GHz, 256 RAM, 40 GB de

disco rígido.

191

8 REFERÊNCIAS BIBLIOGRAFICAS

Deitel, H. M., Deitel, P. J.; Java Como Programar, 3ª Edição; Porto

Alegre, Bookman 2000.

Arlow, J., Neustadt, I.; UML and the Unified Process; Pearson

Professional Education 2001.

Conallen, J.; Desenvolvendo Aplicações Web com UML; Campus

2003

Kurniawan, B.; Java para a Web com Servlets, Jsp e Ejb; Ciência

Moderna 2002.

Francisco, B. J.; Java Server Page; A Tecnologia Java na Internet;

Tatuapé, Editora Érica Ltda. 2002.

Deepmak, A.; Crupi, J.; Malks, D.; Core J2EE Patterns; As Melhores

Práticas e Estratégias de Design; Rio de Janeiro, Campus 2004.

FREITAS, A. A.; firebird.br; Disponível em: <www.firebird.com.br>;

Acesso em: Abril, 2005

Tanenbaum, A. S.; Redes de Computadores, 4ª Edição; Rio de

Janeiro, Campus 2003.

ministÉrio da educaÇÃo utfpr - páginas pessoais · este sistema foi desenvolvido utilizando o...

Documents