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
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” 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
ii 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
iii 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.
iv EPÍGRAFE “ A imaginação é mais importante que o conhecimento.” Albert Einstein “A alegria que se tem em pensar e aprender faz­nos pensar e aprender ainda mais.” Aristóteles.
v 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.
vi 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.
vii 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
viii 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
ix 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
x 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
xi 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 Entidade­Relacionamento .......................................................140
xii LISTA DE TABELAS Tabela 1 – Requisitos funcionais...............................................................................50 Tabela 2 – Requisitos não­funcionais .......................................................................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
xiii 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
xiv 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 Entidade­Relacionamento MP3 MPEG Audio Layer­3 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
xv 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
xvi 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ão­funcionais......................................................................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
xvii 5.3. CONSTRUÇÃO.........................................................................................138 5.3.1 Diagrama de Componentes .................................................................138 5.3.2 Modelo Entidade­Relacionamento.......................................................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
xviii 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 eletro­eletrô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 Layer­3 (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 inter­rede e depois como Internet (TANENBAUM, 1997). O protocolo Transmission Control Protocol/Internet Protocol (TCP/IP) tornou­se 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 on­line 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 norte­americanas (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 foto­copiadora: permite copiar de forma não autorizada um livro, revista, artigo.
·
Radio­gravador: permite copiar as músicas de um CD para uma fita­cassete de áudio sem prévia autorização.
·
Vídeo­cassete, 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 norte­americanas 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 concentrar­se 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 mini­projetos. Assim cada mini­projeto é 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 tornam­se 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 molda­se 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 baseando­se 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 baseia­se 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: Amplia­se 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 pode­se 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 torna­se 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. Pode­se 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 vice­versa. 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 torna­se 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. Identificador RF01 Tabela 1 – Requisitos funcionais Requisito Funcional Prioridade Permitir ao administrador do sistema acesso ao sistema Essencial
por meio de uma sessão com login e senha. 51 Identificador RF02 Requisito Funcional Prioridade Permitir ao administrador do sistema realizar o logout na Essencial sessão do sistema. RF03 Permitir ao administrador alterar a senha de acesso. Essencial RF04 Permitir ao administrador do sistema inserir, alterar e Essencial excluir um registro de um disco no sistema. RF05 Permitir ao administrador do sistema listar os discos Essencial cadastrados no sistema. RF06 Permitir ao administrador do sistema inserir, alterar e Essencial excluir uma música no sistema. RF07 Permitir ao administrador do sistema listar todas as Essencial músicas cadastradas no sistema. RF08 Permitir ao administrador do sistema relacionar uma Essencial música cadastrada no sistema a um disco já cadastrado no sistema. RF09 Permitir ao administrador do sistema gerar, inserir, e Essencial 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. RF10 Permitir ao administrador do sistema buscar uma senha Essencial cadastrada no sistema por meio de um filtro de busca. RF11 Permitir ao administrador do sistema listar, excluir e Essencial
visualizar registros de usuários cadastrados no sistema. 52 Identificador RF12 RF13 Requisito Funcional Prioridade Permitir ao administrador do sistema listar, excluir e Essencial visualizar as aquisições de músicas realizadas por usuários do sistema. Permitir ao usuário do sistema acesso ao sistema por Essencial meio de uma sessão com login e senha. RF14 Permitir ao usuário do sistema realizar um cadastro Essencial pessoal no sistema e alterar o mesmo. RF15 Permitir ao usuário do sistema realizar o logout da Essencial sessão no sistema. RF16 Permitir ao usuário do sistema visualizar os discos Essencial cadastrados no sistema. RF17 Permitir ao usuário do sistema visualizar as músicas Essencial cadastradas para cada um dos discos do sistema. RF18 Permitir ao usuário do sistema informar uma senha e Essencial realizar o download da música cadastrada no sistema. RF19 Realizar o débito de um crédito na senha informada pelo Essencial usuário no momento do download de uma música cadastrada no sistema. 5.1.2 Requisitos não­funcionais 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ão­funcionais:
·
Usabilidade
53
·
Padronização
·
Segurança
·
Desempenho
·
Implantação
·
Robustez/confiabilidade A Tabela 2 mostra os requisitos não­funcionais identificados com os clientes do sistema. Identificador RNF01 Tabela 2 – Requisitos não­funcionais Requisito não­funcional Categoria O sistema desenvolvido deverá ser acessado por Usabilidade um navegador de Internet. RNF02 O sistema desenvolvido deverá conter um banco de Padronização dados free para o armazenamento das informações. 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. Identificador Tabela 3 – Casos de uso identificados 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ós­condiçõ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ós­condiçõ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. Fluxo Alternativo 2: 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 Atores: Administrador 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ós­condições: Nenhuma. Fluxo Alternativo 1: 1. O Administrador pode fechar a tela do navegador. Fluxo Alternativo 2: 1. O Administrador pode ir para outro website. Tabela 6 – Especificação do caso de uso Alterar senha de Administrador Caso de uso: Alterar senha de Administrador Identificador: UC3 Atores: Administrador Pré­condições: Ter realizado o caso de uso UC1. 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ós­condiçõ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.
63 Fluxo Alternativo 1: 1. O Administrador pode fechar a tela do navegador. Fluxo Alternativo 2: 1. O Administrador pode ir para outro website. Fluxo Alternativo 3: 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 Atores: Administrador Pré­condições: Ter realizado o caso de uso UC1. 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ós­condições: 1. Se a operação for realizada com sucesso é exibida a tela de inserção novamente com a mensagem de sucesso. 2. Se não é exibida a tela de erro.
64 Fluxo Alternativo 1: 1. O Administrador pode fechar a tela do navegador. Fluxo Alternativo 2: 1. O Administrador pode ir para outro website. Fluxo Alternativo 3: 1. O Administrador pode cancelar a operação. Caso de uso: Alterar Disco Identificador: UC4.2 Atores: Administrador 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ós­condições: 1. Se a operação for realizada com sucesso é exibida novamente a tela de alteração com a mensagem de sucesso. 2. Se não é exibida a tela de erro. Fluxo Alternativo 1: 1. O Administrador pode fechar a tela do navegador. Fluxo Alternativo 2: 1. O Administrador pode ir para outro website.
65 Fluxo Alternativo 3: 1. O Administrador pode cancelar a operação. Caso de uso: Excluir Disco Identificador: UC4.3 Atores: Administrador Pré­condições: Ter realizado o caso de uso UC4.4. Fluxo de eventos: 1. O Administrador clica no botão Excluir. 2. O Sistema exclui o Disco do banco de dados. Pós­condições: 1. Se a operação for realizada com sucesso é exibida a tela de listagem de Discos. 2. Se não é exibida a tela de erro. Fluxo Alternativo 1: 1. O Administrador pode fechar a tela do navegador. Fluxo Alternativo 2: 1. O Administrador pode ir para outro website. Caso de uso: Listar Discos Identificador: UC4.4 Atores: Administrador Pré­condições: Ter realizado o caso de uso UC1. Fluxo de eventos: 1. O Administrador clica no botão Listar Discos. 2. O Sistema realiza a listagem dos Discos cadastrados.
66 Pós­condições: 1. Se a operação for realizada com sucesso é exibida a tela de listagem de Discos. 2. Se não é exibida a tela de erro. Fluxo Alternativo 1: 1. O Administrador pode fechar a tela do navegador. Fluxo Alternativo 2: 1. O Administrador pode ir para outro website. Tabela 8 ­ Especificação do caso de uso Gerenciar Musicas Caso de uso: Gerenciar Músicas Identificador: UC5. Caso de uso: Cadastrar Música Identificador: UC5.1 Atores: Administrador Pré­condições: Ter realizado o caso de uso UC1. 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. 4. O Sistema valida as informações e insere as mesmas no banco de dados. Pós­condições: 1. Se a operação for realizada com sucesso é exibida novamente a tela de inserção com a mensagem de sucesso.
67 2. Se não é exibida a tela de erro. Fluxo Alternativo 1: 1. O Administrador pode fechar a tela do navegador. Fluxo Alternativo 2: 1. O Administrador pode ir para outro website. Fluxo Alternativo 3: 1. O Administrador pode cancelar a operação. Caso de uso: Alterar Música Identificador: UC5.2 Atores: Administrador Pré­condições: Ter realizado o caso de uso UC5.4. 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ós­condições: 1. Se a operação for realizada com sucesso é exibida novamente a tela de alteração com a mensagem de sucesso. 2. Se não é exibida a tela de erro. Fluxo Alternativo 1: 1. O Administrador pode fechar a tela do navegador. Fluxo Alternativo 2:
68 1. O Administrador pode ir para outro website. Fluxo Alternativo 3: 1. O Administrador pode cancelar a operação. Caso de uso: Excluir Música Identificador: UC5.3 Atores: Administrador Pré­condições: Ter realizado o caso de uso UC5.4. Fluxo de eventos: 1. O Administrador clica no botão Excluir. 2. O Sistema exclui a Música do banco de dados. Pós­condições: 1. Se a operação for realizada com sucesso é exibida a tela de listagem de Músicas. 2. Se não é exibida a tela de erro. Fluxo Alternativo 1: 1. O Administrador pode fechar a tela do navegador. Fluxo Alternativo 2: 1. O Administrador pode ir para outro website. Caso de uso: Listar Músicas Identificador: UC5.4 Atores: Administrador Pré­condições: Ter realizado o caso de uso UC1. 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ós­condições: 1. Se a operação for realizada com sucesso é exibida a tela de listagem de Músicas. 2. Se não é exibida a tela de erro. Fluxo Alternativo 1: 1. O Administrador pode fechar a tela do navegador. Fluxo Alternativo 2: 1. O Administrador pode ir para outro website. Caso de uso: Visualizar Música Identificador: UC5.5 Atores: Administrador Pré­condições: Ter realizado o caso de uso UC5.4. 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ós­condições: 1. Se a operação for realizada com sucesso é exibida a tela de visualização de Música. 2. Se não é exibida a tela de erro. Fluxo Alternativo 1: 1. O Administrador pode fechar a tela do navegador. Fluxo Alternativo 2:
70 1. O Administrador pode ir para outro website. Tabela 9 ­ Especificação do caso de uso Gerenciar Senhas Caso de uso: Gerenciar Senhas Identificador: UC6. Caso de uso: Gerar Senha(s) Identificador: UC6.1 Atores: Administrador Pré­condições: Ter realizado o caso de uso UC1. 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ós­condições: 1. Se a operação for realizada com sucesso é exibida novamente a tela de geração e cadastro de Senhas com as Senhas geradas. 2. Se não é exibida a tela de erro. Fluxo Alternativo 1: 1. O Administrador pode fechar a tela do navegador. Fluxo Alternativo 2: 1. O Administrador pode ir para outro website. Fluxo Alternativo 3: 1. O Administrador pode cancelar a operação.
71 Caso de uso: Cadastrar Senha(s) Identificador: UC6.2 Atores: Administrador Pré­condições: Ter realizado o caso de uso UC6.1. Fluxo de eventos: 1. O Administrador informa os dados da(s) Senha(s) e clica no botão Inserir. 2. O Sistema valida as informações e insere as mesmas no banco de dados. Pós­condiçõ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. 2. Se não é exibida a tela de erro. Fluxo Alternativo 1: 1. O Administrador pode fechar a tela do navegador. Fluxo Alternativo 2: 1. O Administrador pode ir para outro website. Fluxo Alternativo 3: 1. O Administrador pode cancelar a operação. Caso de uso: Excluir Senha Identificador: UC6.3 Atores: Administrador Pré­condições: Ter realizado o caso de uso UC6.4.
72 Fluxo de eventos: 1. O Administrador clica no botão Excluir. 2. O Sistema exclui a Senha do banco de dados. Pós­condições: 1. Se a operação for realizada com sucesso é exibida a tela de busca de Senhas com a mensagem de sucesso. 2. Se não é exibida a tela de erro. Fluxo Alternativo 1: 1. O Administrador pode fechar a tela do navegador. Fluxo Alternativo 2: 1. O Administrador pode ir para outro website. Caso de uso: Buscar Senha Identificador: UC6.4 Atores: Administrador Pré­condições: Ter realizado o caso de uso UC1. 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ós­condições: 1. Se a operação for realizada com sucesso é exibida a tela de busca de Senhas com o resultado da busca.
73 2. Se não é exibida a tela de erro. Fluxo Alternativo 1: 1. O Administrador pode fechar a tela do navegador. Fluxo Alternativo 2: 1. O Administrador pode ir para outro website. 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 Identificador: UC7.1 Atores: Administrador Pré­condições: Ter realizado o caso de uso UC1. Fluxo de eventos: 1. O Administrador clica no botão Listar Usuários. 2. O Sistema realiza a listagem dos Usuários cadastrados. Pós­condições: 1. Se a operação for realizada com sucesso é exibida a tela de listagem de Usuários. 2. Se não é exibida a tela de erro. Fluxo Alternativo 1: 1. O Administrador pode fechar a tela do navegador. Fluxo Alternativo 2: 1. O Administrador pode ir para outro website.
74 Caso de uso: Visualizar Usuário Identificador: UC7.2 Atores: Administrador Pré­condições: Ter realizado o caso de uso UC7.1. Fluxo de eventos: 1. O Administrador clica no botão Visualizar. 2. O Sistema recupera os dados do Usuário cadastrado. Pós­condições: 1. Se a operação for realizada com sucesso é exibida a tela de visualização de Usuário. 2. Se não é exibida a tela de erro. Fluxo Alternativo 1: 1. O Administrador pode fechar a tela do navegador. Fluxo Alternativo 2: 1. O Administrador pode ir para outro website. Caso de uso: Excluir Usuário Identificador: UC7.3 Atores: Administrador Pré­condições: Ter realizado o caso de uso UC7.1. Fluxo de eventos: 1. O Administrador clica no botão Excluir. 2. O Sistema exclui o Usuário do banco de dados. Pós­condições: 1. Se a operação for realizada com sucesso é exibida a tela de
75 listagem de Usuários. 2. Se não é exibida a tela de erro. Fluxo Alternativo 1: 1. O Administrador pode fechar a tela do navegador. Fluxo Alternativo 2: 1. O Administrador pode ir para outro website. 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 Identificador: UC8.1 Atores: Administrador Pré­condições: Ter realizado o caso de uso UC1. Fluxo de eventos: 1. O Administrador clica no botão Listar Aquisições. 2. O Sistema realiza a listagem das Aquisições cadastradas. Pós­condições: 1. Se a operação for realizada com sucesso é exibida a tela de listagem de Aquisições. 2. Se não é exibida a tela de erro. Fluxo Alternativo 1: 1. O Administrador pode fechar a tela do navegador. Fluxo Alternativo 2:
76 1. O Administrador pode ir para outro website. Caso de uso: Visualizar Aquisição Identificador: UC8.2 Atores: Administrador Pré­condições: Ter realizado o caso de uso UC8.1. Fluxo de eventos: 1. O Administrador clica no botão Visualizar. 2. O Sistema recupera os dados da Aquisição cadastrada. Pós­condições: 1. Se a operação for realizada com sucesso é exibida a tela de visualização de Aquisição. 2. Se não é exibida a tela de erro. Fluxo Alternativo 1: 1. O Administrador pode fechar a tela do navegador. Fluxo Alternativo 2: 1. O Administrador pode ir para outro website. Caso de uso: Excluir Aquisição Identificador: UC8.3 Atores: Administrador Pré­condições: Ter realizado o caso de uso UC8.1. Fluxo de eventos: 1. O Administrador clica no botão Excluir. 2. O Sistema exclui a Aquisição do banco de dados. Pós­condições:
77 1. Se a operação for realizada com sucesso é exibida a tela de listagem de Aquisições. 2. Se não é exibida a tela de erro. Fluxo Alternativo 1: 1. O Administrador pode fechar a tela do navegador. Fluxo Alternativo 2: 1. O Administrador pode ir para outro website. Tabela 12 ­ Especificação do caso de uso Logar no Sistema Caso de uso: Logar no Sistema Identificador: UC9 Atores: Usuário WEB Pré­condições: Nenhuma 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ós­condições: 1. Se a operação for realizada com sucesso é exibida a tela principal do website novamente. 2. Se não é exibida a tela de erro.
78 Fluxo Alternativo 1: 1. O Usuário WEB pode fechar a tela do navegador. Fluxo Alternativo 2: 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 Atores: Usuário WEB Pré­condições: Ter realizado o caso de uso UC9. 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ós­condições: Nenhuma. Fluxo Alternativo 1: 1. O Usuário WEB pode fechar a tela do navegador. Fluxo Alternativo 2: 1. O Usuário WEB pode ir para outro website. Tabela 14 ­ Especificação do caso de uso Cadastrar Usuário Caso de uso: Cadastrar Usuário Identificador: UC11 Atores: Usuário WEB
79 Pré­condições: Nenhuma 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ós­condições: 1. Se a operação for realizada com sucesso é exibida a tela principal do website novamente. 2. Se não é exibida a tela de erro. Fluxo Alternativo 1: 1. O Usuário WEB pode fechar a tela do navegador. Fluxo Alternativo 2: 1. O Usuário WEB pode ir para outro website. Fluxo Alternativo 3: 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 Atores: Usuário WEB Pré­condições: Ter realizado o caso de uso UC9.
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ós­condições: 1. Se a operação for realizada com sucesso é exibida a tela de sucesso de operação. 2. Se não é exibida a tela de erro. Fluxo Alternativo 1: 1. O Usuário WEB pode fechar a tela do navegador. Fluxo Alternativo 2: 1. O Usuário WEB pode ir para outro website. Fluxo Alternativo 3: 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 Identificador: UC13.1 Atores: Usuário WEB
81 Pré­condições: Ter realizado o caso de uso UC9. 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ós­condições: 1. Se a operação for realizada com sucesso é exibida tela com a listagem dos Discos. 2. Se não é exibida a tela de erro. Fluxo Alternativo 1: 1. O Usuário WEB pode fechar a tela do navegador. Fluxo Alternativo 2: 1. O Usuário WEB pode ir para outro website. Caso de uso: Listar Músicas cadastradas Identificador: UC13.2 Atores: Usuário WEB Pré­condições: Ter realizado o caso de uso UC13.1. 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ós­condições: 1. Se a operação for realizada com sucesso é exibida tela com a listagem das Músicas do Disco. 2. Se não é exibida a tela de erro.
82 Fluxo Alternativo 1: 1. O Usuário WEB pode fechar a tela do navegador. Fluxo Alternativo 2: 1. O Usuário WEB pode ir para outro website. Fluxo Alternativo 3: 1. O Usuário WEB pode ir para outra área do website. Caso de uso: Exibir Download de Música Identificador: UC13.3 Atores: Usuário WEB Pré­condições: Ter realizado o caso de uso UC13.2. 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ós­condições: 1. Se a operação for realizada com sucesso é exibida a tela de download ao Usuário WEB. 2. Se não é exibida a tela de erro. Fluxo Alternativo 1: 1. O Usuário WEB pode fechar a tela do navegador. Fluxo Alternativo 2: 1. O Usuário WEB pode ir para outro website. Caso de uso: Download de Música Identificador: UC13.4
83 Atores: Usuário WEB Pré­condições: Ter realizado o caso de uso UC13.3. 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ós­condições: 1. Se a operação for realizada com sucesso sistema retorna ao Usuário WEB o arquivo de música para o download. 2. Se não é exibida a tela de erro. Fluxo Alternativo 1: 1. O Administrador pode fechar a tela do navegador. Fluxo Alternativo 2: 1. O Administrador pode ir para outro website. 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 Entidade­Relacionamento O modelo de dados entidade­relacionamento 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 Entidade­Relacionamento do sistema desenvolvido neste trabalho. IDMUSICA NOMEMUSICA IDDISCO IDMUSICA IDUSUARIO IDSENHA IDAQUISICAO IDUSUARIO DATA USUARIO SENHA PATHMUSICA MUSICAS 1 ESTÁ N AQUISICOES N FAIXA FAZ N 1 USUARIOS NOME N EMAIL TELEFONE ESTÁ TEM TIPO ANO 1 DISCOS 1 IDSENHA SENHAS LOCALDISTRIB IMAGEM SENHA NOMEDISCO QTDECREDITOSATUAL IDDISCO DATACRIACAO QTDECREDITOS Figura 78 – Modelo Entidade­Relacionamento
ONDEADQUIRIU DATANASC 141 5.3.3. Testes 5.3.3.1 Teste de Caixa Preta Os métodos de teste de caixa preta concentram­se 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ós­condiçõ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 menu de administraçã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. Responsável: Alberto Luiz da Silva Caso de uso: UC2 Abordagem: Caixa Preta Técnica: Manual Pré­condições: Ter realizado o caso de uso UC1. Passos:
143 1. Clicar no botão Logout. Pós­condiçõ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. Responsável: Alberto Luiz da Silva Caso de uso: UC3 Abordagem: Caixa Preta Técnica: Manual Pré­condições: Ter realizado o caso de uso UC1. 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ós­condiçõ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
144 menu de administração. 2. Caso contrário o usuário administrador será redirecionado para uma página de erro. Tabela 20 – Caso de Teste Cadastrar Disco Caso de teste: Cadastrar Disco Identificador: TC4 Descrição: Por meio deste caso de uso o usuário administrador poderá cadastrar um Disco no Sistema. Responsável: Alberto Luiz da Silva Caso de uso: UC4.1 Abordagem: Caixa Preta Técnica: Manual Pré­condições: Ter realizado o caso de uso UC1. 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ós­condições: 1. Se a operação for realizada com sucesso e o usuário administrador informar dados corretos, o mesmo será redirecionado novamente a tela de inserção de Disco. 2. Caso contrário o usuário administrador será redirecionado para uma página de erro.
145 Tabela 21 – Caso de Teste Alterar Disco Caso de teste: Alterar Disco Identificador: TC5 Descrição: Por meio deste caso de uso o usuário administrador poderá alterar o cadastro de um Disco no Sistema. Responsável: Alberto Luiz da Silva Caso de uso: UC4.2 Abordagem: Caixa Preta Técnica: Manual Pré­condições: Ter realizado o caso de uso UC4.4. Passos: 1. Clicar em um botão Alterar na tela de listagem de Discos. 2. Informar os novos dados do Disco que será alterado. 3. Clicar no botão Alterar. Pós­condições: 1. Se a operação for realizada com sucesso e o usuário administrador informar dados corretos, o mesmo será redirecionado novamente a tela de alteração de Disco. 2. Caso contrário o usuário administrador será redirecionado para uma página de erro. Tabela 22 – Caso de Teste Excluir Disco Caso de teste: Excluir Disco Identificador: TC6 Descrição: Por meio deste caso de uso o usuário administrador poderá
146 excluir um Disco do Sistema. Responsável: Alberto Luiz da Silva Caso de uso: UC4.3 Abordagem: Caixa Preta Técnica: Manual Pré­condições: Ter realizado o caso de uso UC4.4. Passos: 1. Clicar em um botão Excluir na tela de listagem de Discos. Pós­condições: 1. Se a operação for realizada com sucesso o usuário administrador será redirecionado novamente a tela de listagem de Discos. 2. Caso contrário o usuário administrador será redirecionado para uma página de erro. Tabela 23 – Caso de Teste Listar Discos Caso de teste: Listar Discos Identificador: TC7 Descrição: Por meio deste caso de uso o usuário administrador poderá listar os Discos cadastrados no Sistema. Responsável: Alberto Luiz da Silva Caso de uso: UC4.4 Abordagem: Caixa Preta Técnica: Manual
147 Pré­condições: Ter realizado o caso de uso UC1. Passos: 1. Clicar no botão Listar Discos do menu de administração. Pós­condições: 1. Se a operação for realizada com sucesso o usuário administrador será redirecionado a tela de listagem de Discos. 2. Caso contrário o usuário administrador será redirecionado para uma página de erro. Tabela 24 – Caso de Teste Cadastrar Música Caso de teste: Cadastrar Música Identificador: TC8 Descrição: Por meio deste caso de uso o usuário administrador poderá cadastrar uma Música no Sistema. Responsável: Alberto Luiz da Silva Caso de uso: UC5.1 Abordagem: Caixa Preta Técnica: Manual Pré­condições: Ter realizado o caso de uso UC1. Passos: 1. Clicar no botão Inserir Música do menu de administração. 2. Informar os dados da Música que será cadastrada. 3. Clicar no botão Inserir. Pós­condições:
148 1. Se a operação for realizada com sucesso e o usuário administrador informar dados corretos, o mesmo será redirecionado novamente a tela de inserção de Música. 2. Caso contrário o usuário administrador será redirecionado para uma página de erro.
Tabela 25 – Caso de Teste Alterar Música Caso de teste: Alterar Música Identificador: TC9 Descrição: Por meio deste caso de uso o usuário administrador poderá alterar o cadastro de uma Música no Sistema. Responsável: Alberto Luiz da Silva Caso de uso: UC5.2 Abordagem: Caixa Preta Técnica: Manual Pré­condições: Ter realizado o caso de uso UC5.4. 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. 3. Clicar no botão Alterar. Pós­condições: 1. Se a operação for realizada com sucesso e o usuário administrador informar dados corretos, o mesmo será redirecionado novamente a tela de alteração de Música.
149 2. Caso contrário o usuário administrador será redirecionado para uma página de erro.
Tabela 26 – Caso de Teste Excluir Música Caso de teste: Excluir Música Identificador: TC10 Descrição: Por meio deste caso de uso o usuário administrador poderá excluir uma Música do Sistema. Responsável: Alberto Luiz da Silva Caso de uso: UC5.3 Abordagem: Caixa Preta Técnica: Manual Pré­condições: Ter realizado o caso de uso UC5.4. Passos: 1. Clicar em um botão Excluir na tela de listagem de Músicas. Pós­condições: 1. Se a operação for realizada com sucesso o usuário administrador será redirecionado novamente a tela de listagem de Músicas. 2. Caso contrário o usuário administrador será redirecionado para uma página de erro.
Tabela 27 – Caso de Teste Listar Músicas Caso de teste: Listar Músicas Identificador: TC11
150 Descrição: Por meio deste caso de uso o usuário administrador poderá listar a Músicas cadastradas no Sistema. Responsável: Alberto Luiz da Silva Caso de uso: UC5.4 Abordagem: Caixa Preta Técnica: Manual Pré­condições: Ter realizado o caso de uso UC1. Passos: 1. Clicar no botão Listar Músicas do menu de administração. Pós­condições: 1. Se a operação for realizada com sucesso o usuário administrador será redirecionado a tela de listagem de Músicas. 2. Caso contrário o usuário administrador será redirecionado para uma página de erro. Tabela 28 – Caso de Teste Visualizar Música Caso de teste: Visualizar Música Identificador: TC12 Descrição: Por meio deste caso de uso o usuário administrador poderá visualizar uma Música cadastrada no Sistema. Responsável: Alberto Luiz da Silva Caso de uso: UC5.5 Abordagem: Caixa Preta
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ós­condições: 1. Se a operação for realizada com sucesso o usuário administrador será redirecionado a tela de visualização de Música. 2. Caso contrário o usuário administrador será redirecionado para uma página de erro. Tabela 29 – Caso de Teste Gerar Senha(s) Caso de teste: Gerar Senha(s) Identificador: TC13 Descrição: Por meio deste caso de uso o usuário administrador poderá gerar Senhas que serão utilizadas nos cartões MP3CARD’s. Responsável: Alberto Luiz da Silva Caso de uso: UC6.1 Abordagem: Caixa Preta Técnica: Manual Pré­condições: Ter realizado o caso de uso UC1. 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ós­condições: 1. Se a operação for realizada com sucesso o usuário administrador será redirecionado novamente a tela de geração de Senhas com a lista de Senhas geradas. 2. Caso contrário o usuário administrador será redirecionado para uma página de erro. Tabela 30 – Caso de Teste Cadastrar Senha(s) Caso de teste: Cadastrar Senha(s) Identificador: TC14 Descrição: Por meio deste caso de uso o usuário administrador poderá cadastrar Senhas no sistema. Responsável: Alberto Luiz da Silva Caso de uso: UC6.2 Abordagem: Caixa Preta Técnica: Manual Pré­condições: Ter realizado o caso de uso UC6.1. Passos: 1. Informar os dados das Senhas que serão cadastradas. 2. Clicar no botão Inserir. Pós­condições: 1. Se a operação for realizada com sucesso o usuário administrador será redirecionado a tela de visualização de Senhas cadastradas com a lista de Senhas que foram cadastradas na operação.
153 2. Caso contrário o usuário administrador será redirecionado para uma página de erro.
Tabela 31 – Caso de Teste Excluir Senha Caso de teste: Excluir Senha Identificador: TC15 Descrição: Por meio deste caso de uso o usuário administrador poderá excluir uma Senha do Sistema. Responsável: Alberto Luiz da Silva Caso de uso: UC6.3 Abordagem: Caixa Preta Técnica: Manual Pré­condições: Ter realizado o caso de uso UC6.4. Passos: 1. Clicar em um botão Excluir na tela de listagem de Senhas. Pós­condições: 1. Se a operação for realizada com sucesso o usuário administrador será redirecionado novamente a tela de busca de Senhas. 2. Caso contrário o usuário administrador será redirecionado para uma página de erro.
Tabela 32 – Caso de Teste Buscar Senha Caso de teste: Buscar Senha Identificador: TC16
154 Descrição: Por meio deste caso de uso o usuário administrador poderá buscar uma Senha cadastrada no Sistema por meio de um filtro de busca. Responsável: Alberto Luiz da Silva Caso de uso: UC6.4 Abordagem: Caixa Preta Técnica: Manual Pré­condições: Ter realizado o caso de uso UC1. 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ós­condições: 1. Se a operação for realizada com sucesso o usuário administrador será redirecionado novamente a tela de busca de Senhas com o resultado da busca realizada. 2. Caso contrário o usuário administrador será redirecionado para uma página de erro. Tabela 33 – Caso de Teste Listar Usuários Caso de teste: Listar Usuários Identificador: TC17 Descrição: Por meio deste caso de uso o usuário administrador poderá listar os Usuários cadastrados no Sistema. Responsável: Alberto Luiz da Silva
155 Caso de uso: UC7.1 Abordagem: Caixa Preta Técnica: Manual Pré­condições: Ter realizado o caso de uso UC1. Passos: 1. Clicar no botão Listar Usuários do menu de administração. Pós­condições: 1. Se a operação for realizada com sucesso o usuário administrador será redirecionado a tela de listagem de Usuários. 2. Caso contrário o usuário administrador será redirecionado para uma página de erro. Tabela 34 – Caso de Teste Visualizar Usuário Caso de teste: Visualizar Usuário Identificador: TC18 Descrição: Por meio deste caso de uso o usuário administrador poderá visualizar um Usuário cadastrado no Sistema. Responsável: Alberto Luiz da Silva Caso de uso: UC7.2 Abordagem: Caixa Preta Técnica: Manual Pré­condições: Ter realizado o caso de uso UC7.1. Passos: 1. Clicar em um botão Visualizar na tela de listagem de Usuários.
156 Pós­condições: 1. Se a operação for realizada com sucesso o usuário administrador será redirecionado a tela de visualização de Usuário. 2. Caso contrário o usuário administrador será redirecionado para uma página de erro. Tabela 35 – Caso de Teste Excluir Usuário Caso de teste: Excluir Usuário Identificador: TC19 Descrição: Por meio deste caso de uso o usuário administrador poderá excluir um Usuário do Sistema. Responsável: Alberto Luiz da Silva Caso de uso: UC7.3 Abordagem: Caixa Preta Técnica: Manual Pré­condições: Ter realizado o caso de uso UC7.1. Passos: 1. Clicar em um botão Excluir na tela de listagem de Usuários. Pós­condições: 1. Se a operação for realizada com sucesso o usuário administrador será redirecionado novamente a tela de listagem de Usuários. 2. Caso contrário o usuário administrador será redirecionado para uma página de erro.
157 Tabela 36 – Caso de Teste Listar Aquisições Caso de teste: Listar Aquisições Identificador: TC20 Descrição: Por meio deste caso de uso o usuário administrador poderá listar as Aquisições cadastradas no Sistema. Responsável: Alberto Luiz da Silva Caso de uso: UC8.1 Abordagem: Caixa Preta Técnica: Manual Pré­condições: Ter realizado o caso de uso UC1. Passos: 1. Clicar no botão Listar Aquisições do menu de administração. Pós­condições: 1. Se a operação for realizada com sucesso o usuário administrador será redirecionado a tela de listagem de Aquisições. 2. Caso contrário o usuário administrador será redirecionado para uma página de erro. Tabela 37 – Caso de Teste Visualizar Aquisição Caso de teste: Visualizar Aquisição Identificador: TC21 Descrição: Por meio deste caso de uso o usuário administrador poderá visualizar uma Aquisição cadastrada no Sistema. Responsável: Alberto Luiz da Silva
158 Caso de uso: UC8.2 Abordagem: Caixa Preta Técnica: Manual Pré­condições: Ter realizado o caso de uso UC8.1. Passos: 1. Clicar em um botão Visualizar na tela de listagem de Aquisições. Pós­condições: 1. Se a operação for realizada com sucesso o usuário administrador será redirecionado a tela de visualização de Aquisição. 2. Caso contrário o usuário administrador será redirecionado para uma página de erro. Tabela 38 – Caso de Teste Excluir Aquisição Caso de teste: Excluir Aquisição Identificador: TC22 Descrição: Por meio deste caso de uso o usuário administrador poderá excluir uma Aquisição do Sistema. Responsável: Alberto Luiz da Silva Caso de uso: UC8.3 Abordagem: Caixa Preta Técnica: Manual Pré­condições: Ter realizado o caso de uso UC8.1. Passos: 1. Clicar em um botão Excluir na tela de listagem de Aquisições.
159 Pós­condições: 1. Se a operação for realizada com sucesso o usuário administrador será redirecionado novamente a tela de listagem de Aquisições. 2. Caso contrário o usuário administrador será redirecionado para uma 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. Responsável: Alberto Luiz da Silva Caso de uso: UC9 Abordagem: Caixa Preta 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ós­condiçõ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. Responsável: Alberto Luiz da Silva Caso de uso: UC10 Abordagem: Caixa Preta Técnica: Manual Pré­condições: Ter realizado o caso de uso UC9. Passos: 3. Clicar no botão Logout. Pós­condiçõ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 Responsável: Alberto Luiz da Silva Caso de uso: UC11 Abordagem: Caixa Preta 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ós­condições: 1. Se a operação for realizada com sucesso e o usuário informar dados corretos, o mesmo será redirecionado a tela de sucesso de operação. 2. Caso contrário o usuário será redirecionado para uma página de 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. Responsável: Alberto Luiz da Silva Caso de uso: UC12 Abordagem: Caixa Preta Técnica: Manual
162 Pré­condições: Ter realizado o caso de uso UC9. Passos: 1. Clicar no botão Cadastro. 2. Informar os novos dados do usuário cadastrado. 3. Clicar no botão Alterar. Pós­condições: 1. Se a operação for realizada com sucesso e o usuário informar dados corretos, o mesmo será redirecionado a tela de sucesso de operação. 2. Caso contrário o usuário será redirecionado para uma página de 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. Responsável: Alberto Luiz da Silva Caso de uso: UC13.1 Abordagem: Caixa Preta Técnica: Manual Pré­condições: Ter realizado o caso de uso UC9. Passos: 1. Clicar no botão Músicas. Pós­condiçõ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. 2. Caso contrário o usuário será redirecionado para uma página de 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. Responsável: Alberto Luiz da Silva Caso de uso: UC13.2 Abordagem: Caixa Preta Técnica: Manual Pré­condições: Ter realizado o caso de uso UC13.1. Passos: 1. Clicar no botão referente a um Disco listado na tela. Pós­condições: 1. Se a operação for realizada com sucesso o usuário será redirecionado a tela de listagem de Músicas cadastradas para o Disco selecionado no Sistema. 2. Caso contrário o usuário será redirecionado para uma página de 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. Responsável: Alberto Luiz da Silva Caso de uso: UC13.3 Abordagem: Caixa Preta Técnica: Manual Pré­condições: Ter realizado o caso de uso UC13.2. Passos: 1. Clicar no botão Download referente a uma listada na tela. Pós­condições: 1. Se a operação for realizada com sucesso o usuário será redirecionado a tela de Download de Música cadastrada. 2. Caso contrário o usuário será redirecionado para uma página de 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 Responsável: Alberto Luiz da Silva Caso de uso: UC13.4 Abordagem: Caixa Preta Técnica: Manual Pré­condições: Ter realizado o caso de uso UC13.3. Passos: 1. Inserir a senha do MP3CARD. 2. Clicar no botão Download. Pós­condiçõ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. 2. Caso contrário o usuário será redirecionado para uma página de 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 1 Iteração Elaboração 2 Iterações Construção 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. 63­70, Outubro 1999. 8. CARLSON, D. Modelagem de Aplicações XML com UML: Aplicações práticas de e­business. 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. Dow nload: 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 ALBERTO LUIZ DA SILVA 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 ALBERTO LUIZ DA SILVA Sistema de vendas de música na internet através de cartão “MP3 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 Layer­3 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 Sistema de vendas de música na internet através de cartão “MP3 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 deu­se 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.