GERENCIAMENTO DE TEXTURAS PARA APLICAÇÕES DE …monografias.poli.ufrj.br/monografias/monopoli10020507.pdf · SISTEMA GERENCIADOR DE DOWNLOAD DE ... autor da monografia Sistema Gerenciador

SISTEMA GERENCIADOR DE DOWNLOAD DE

ARQUIVOS PARA UM SITE NA INTERNET

Carlos Alberto Fernandes Neves Filho

Projeto de Graduação apresentado ao Curso de

Engenharia Eletrônica e de Computação da Escola

Politécnica, Universidade Federal do Rio de

Janeiro, como parte dos requisitos necessários à

obtenção do título de Engenheiro.

Orientador: Flávio Luis de Mello

Rio de Janeiro

Fevereiro de 2017

ii

SISTEMA GERENCIADOR DE DOWNLOAD DE

ARQUIVOS PARA UM SITE NA INTERNET


PROJETO DE GRADUAÇÃO SUBMETIDO AO CORPO DOCENTE DO CURSO DE

ENGENHARIA ELETRÔNICA E DE COMPUTAÇÃO DA ESCOLA POLITÉCNICA

DA UNIVERSIDADE FEDERAL DO RIO DE JANEIRO COMO PARTE DOS

REQUISITOS NECESSÁRIOS PARA A OBTENÇÃO DO GRAU DE ENGENHEIRO

ELETRÔNICO E DE COMPUTAÇÃO

Autor:


Orientador:

Examinador:

Prof. Ricardo RhombergMartins, D. sc.

Examinador:

Prof. Heraldo Luis Silveira de Almeida, D. sc.

Rio de Janeiro – RJ, Brasil

Fevereiro de 2017

iii

Declaração de Autoria e de Direitos

Eu, Carlos Alberto Fernandes Neves Filho CPF 025.947.017-18, autor da monografia

Sistema Gerenciador de Download de Arquivos para um Site na Internet, subscrevo para

os devidos fins, as seguintes informações:

1. O autor declara que o trabalho apresentado na disciplina de Projeto de Graduação

da Escola Politécnica da UFRJ é de sua autoria, sendo original em forma e

conteúdo.

2. Excetuam-se do item 1. Eventuais transcrições de texto, figuras, tabelas,

conceitos e ideias, que identifiquem claramente a fonte original, explicitando as

autorizações obtidas dos respectivos proprietários, quando necessárias.

3. O autor permite que a UFRJ, por um prazo indeterminado, efetue em qualquer

mídia de divulgação, a publicação do trabalho acadêmico em sua totalidade, ou em

parte. Essa autorização não envolve ônus de qualquer natureza à UFRJ, ou aos seus

representantes.

4. O autor pode, excepcionalmente, encaminhar à Comissão de Projeto de

Graduação, a não divulgação do material, por um prazo máximo de 01 (um) ano,

improrrogável, a contar da data de defesa, desde que o pedido seja justificado, e

solicitado antecipadamente, por escrito, à Congregação da Escola Politécnica.

5. O autor declara, ainda, ter a capacidade jurídica para a prática do presente ato,

assim como ter conhecimento do teor da presente Declaração, estando ciente das

sanções e punições legais, no que tange a cópia parcial, ou total, de obra intelectual,

o que se configura como violação do direito autoral previsto no Código Penal

Brasileiro no art.184 e art.299, bem como na Lei 9.610.

6. O autor é o único responsável pelo conteúdo apresentado nos trabalhos

acadêmicos publicados, não cabendo à UFRJ, aos seus representantes, ou ao(s)

orientador(es), qualquer responsabilização/ indenização nesse sentido.

7. Por ser verdade, firmo a presente declaração.


iv

UNIVERSIDADE FEDERAL DO RIO DE JANEIRO

Escola Politécnica – Departamento de Eletrônica e de Computação

Centro de Tecnologia, bloco H, sala H-217, Cidade Universitária

Rio de Janeiro – RJ CEP 21949-900

Este exemplar é de propriedade da Universidade Federal do Rio de Janeiro, que

poderá incluí-lo em base de dados, armazenar em computador, microfilmar ou adotar

qualquer forma de arquivamento.

É permitida a menção, reprodução parcial ou integral e a transmissão entre

bibliotecas deste trabalho, sem modificação de seu texto, em qualquer meio que esteja ou

venha a ser fixado, para pesquisa acadêmica, comentários e citações, desde que sem

finalidade comercial e que seja feita a referência bibliográfica completa.

Os conceitos expressos neste trabalho são de responsabilidade do(s) autor(es).

v

DEDICATÓRIA

Dedico este trabalho ao povo brasileiro e a todos que contribuíram para o seu

sucesso.

vi

AGRADECIMENTO

Agradeço primeiramente ao povo brasileiro que garantiu a minha estada nesta

Universidade.

A meus mestres, em especial ao Professor Osvaldo Pereira Filho e ao falecido

Professor Sergio Barbosa Villas-Boas, que acreditaram em mim, apesar de todas as

dificuldades, para a conclusão da minha formação nesta Universidade.

Ao Professor Flávio Luis de Mello que resolveu ser meu orientador em

substituição ao falecido Professor Sergio Barbosa Villas-Boas permitindo de forma

dedicada a conclusão deste trabalho.

A todos os alunos e funcionários que conheci durante a minha graduação que

ficaram no anonimato.

vii

RESUMO

Este trabalho tem como objetivo implementar um sistema (web-service), com um

custo bem baixo, que permita a um ou mais usuários gerenciar o controle de downloads

de seus arquivos publicados em um site instalado na internet, podendo saber quem fez,

quanto e quando pagou para realizar o download. Os arquivos podem ser: vídeos,

apostilas, músicas, apresentações e etc. Os usuários podem ser pessoas que

disponibilizam e/ou têm autorização para baixar os arquivos da Internet. O web-service

foi implementado usando tecnologias baseadas na linguagem java como a engine Axis2

da Fundação Apache que é de código aberto e a IDE NetBeans com o respectivo plugin

que é gratuita e feita em Java da Oracle. Já a aplicação que vai consumir o web-service

para fins de teste foi implementada com o PHP versão 7 que é gratuito. As informações

dos usuários e arquivos ficam armazenadas num banco de dados MySql que também é

gratuito da Oracle. Na aplicação, um usuário, que podemos chamar de dono, pode criar

módulos onde cada um contém um grupo de arquivos. Cada módulo tem um preço e

usuário que tem permissão de poder comprá-los para futuros downloads dos seus

arquivos. Aos módulos já criados podem ser acrescentados arquivos, habilitar e

desabilitar usuários, acrescentar novos usuários ou alterar os preços a qualquer momento.

Um usuário também pode ler a lista de módulos e arquivos disponíveis para compra ou

já comprados, bem como, o histórico de preços dos módulos. Tudo isto é feito através da

API que foi criada do web-service utilizando XML. Na aplicação do PHP existe uma tela

de login onde usuários (donos ou clientes) podem se logar para comprar, baixar ou

gerenciar (criar, alterar) os seus respectivos módulos. Todas estas operações são feitas

dentro do PHP através de chamadas ao web-service a partir de uma tela em HTML do

navegador.

Palavras-chave: trabalho, resumo, interesse, projeto final, web-services, SOA.

vii

i

ABSTRACT

The purpose of this paper is to implement a low cost web-services system that will

enable one or more users to manage the download control of their internet published files.

It will allow them to know who conceived and financed the system and when the

download took place. Files could be vídeos, outlines, tunes, work presentations etc. Users

can make available/or are duly authorized to download internet files. Web-services

system is designed with technologies such as open source Java Axis2 engine (Apache

Fundation) and IDE NetBeans with its free plugin (Oracle’s Java software). Likewise, the

application which will consume the web-services system, for the testing purposes, was

implemented with the free PHP version 7. Users’ informations and files are stored in

Oracle MySql data bank which is also free. During the application, the user (we may call

the “owners”), can create modules. A module has a set of files. Each has a price and the

user will be authorized to buy they for future downloads of their files. Once set, new files

can be added to the modules, users can be abled and enabled, new users can be added and

prices can be changed at any time. An user can also see a list of modules available for

sales and/or a list of those items already purchased, as well as the price and dates modules

were bought.. All these features are made available by an API created by the web-

services system based on XML. In the application of the PHP there is a login screen

where users (owners or clientes) can login to buy, download or manage (design and

change) their own modules. All such operations are made with PHP through a web-

service call originating from a screen in the HTML navigator.

Key-words: work, outline, interest, final Project, web-services, SOA.

ix

SIGLAS

Axis2 - Engine para web-services da Fundação Apache de código aberto

HTML – HyperText Markup Language

MySql - Banco de dados da Oracle de código aberto

NetBeans – IDE em Java da Oracle de código aberto

OASIS - Organization for the Advancement of Structured Information Standards

PHP - Hypertext Preprocessor

REST - Representational State Transfer

SAML - Security Assertion Markup Language

SOA - Service Oriented Architecture

SOAP - Simple Object Access Protocol

SSL - Secure Socket Layer

UDDI - Universal Description, Discovery and Integration

UFRJ – Universidade Federal do Rio de Janeiro

W3C - World Wide Web Consortium

WSDL - Webservice Description Language

WS-Security - Web Services Security

XML - eXtensible Markup Language

x

Sumário

1 Introdução 1

1.1 - Tema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 - Delimitação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 - Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.4 - Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.5 - Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.6 - Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Fundamentação Teórica 4

2.1 - Web Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 - Dados acessíveis via HTTP . . . . . . . . . .. . .. . . . . . . . . . . . . . 7

2.3 - Scrum Academic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 Solução Proposta 15

3.1 - Descrição do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2 - Arquitetura da Solução . . . . . . . . . .. . .. . .. . .. .. . . . . . . . . . . 15

3.3 - Implementação da Solução . . . . . . . . . . . .. . . . . . . . . . . . . . . 23

3.4 - Análise e Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4 Conclusão 38

4.1 - Conclusões . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . 38

xi

4.2 - Trabalhos Futuros . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Bibliografia 40

A Método Scrum Academic 42

B Script MySql 45

C WSDL 48

xii

Lista de Figuras

2.1 – Arquitetura SOA “web-services”. . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 – Relacionamento entre especificações de primeira geração . . . . . . . . . . . . . 8

2.3 – Formato de mensagem do SOAP. . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4 – Exemplo de um SOAP. . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . 10

2.5 – Atividade e Artefatos Scrum. . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1 – DER do banco de dados.. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2 – Casos de uso do web-service. . . . .. . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . 18

3.3 – Dados (beans) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.4 – Serviços . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.5 – Projeto do NetBeans.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.6 – Arquivos em PHP. . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.7 – Tela de login PHP . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.8 – Cadastros de Pessoas.. . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.9 – Cadastrar Módulos do Professor 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.10 – Cadastrar Módulos do Professor 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.11 – Gerenciar Módulos do Professor 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.12 – Gerenciar Módulos do Professor 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.13 – Lista de Módulos do Aluno 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.14 – Confirmação de uma Compra do Aluno 5 . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.15 – Lista de Módulos das Compras do Aluno 5 . . . . . . . . . . . . . . . . . . . . . . . . 36

xii

i

3.16 – Histórico dos Módulos do Professor 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

xi

v

Lista de Tabelas

Tabela 3.1 – Descrições das tabelas do banco de dados . . . . . . . . . . . . . . . . . . . . . 17

Tabela 3.2 – Descrições das classes utilitárias. . . . . . . . . .. . . . .. . . . . . . . . . . . . . . 24

Tabela 3.3 – Descrições das funções dos arquivos PHP. . . . . . . . . . . . . . . . . . . . . 28

Capítulo 1

Introdução

1.1 – Tema

O tema deste trabalho vem da necessidade de muitos usuários terem um

repositório de arquivos, de fácil acesso a todos, com um controle de quais foram usados

por seus clientes para fins estatísticos e/ou financeiros. Desta forma, o problema é

implementar um web-service para se ter esta informação de quem, quando e quanto pagou

para realizar downloads de determinados arquivos instalados em um site na web.

1.2 – Delimitação

Este web-service pode ser utilizado por vários tipos de usuários que precisam ter

um controle de quem pagou para fazer os downloads da internet, como por exemplo,

professores, cursos, universidades, programadores, empresas de informática, empresas de

entretenimento e etc. Não necessita de nenhum custo adicional de licença do software

usado em seu desenvolvimento por ter sido feito com tecnologia de código aberto. O

usuário terá somente que se preocupar com o custo do servidor do site da internet que

deve prover as seguintes tecnologias : Tomcat versão 8 e o banco de dados MySql versão

5.7.16 ou compatível.

1.3 – Justificativa

Muitos usuários como, professores, cursos, universidades, programadores,

empresas de informática, empresas de entretenimento, etc, precisam ter um controle de

quantos e quando seus arquivos foram usados pelos seus clientes, tanto para fins

2

estatísticos como comerciais, bem como, ter um local de fácil acesso para disponibilizar

estes mesmos.

Neste sentido, torna-se desejável implementar um sistema na nuvem (internet),

com tecnologia web-services que possa ser instalado no servidor de onde estes arquivos

estão armazenados de forma que um ou mais usuário acessem, tanto para baixar como

para obter as informações necessárias dos downloads. A vantagem de utilizar tecnologias

de código aberto diminui drasticamente os custos de implementação e de instalações

tornando este bem acessível a qualquer tipo de usuário, desde aquele com poucos recursos

até o mais abastado.

1.4 – Objetivos

O objetivo será então implementar um sistema na nuvem (internet), com

tecnologia webservices, com uma API que permita a um usuário acessar de qualquer

lugar, desde que tenha acesso a internet, através de uma aplicação cliente que pode ser

completa ou simplesmente um receptor e leitor de XML.

Pelos seguintes passos:

1. Fazer o levantamento dos requisitos.

2. Modelar o web-service (casos de uso).

3. Modelar o banco de dados.

4. Implementar e testar o web-service.

5. Fazer um esboço do necessário para implementar uma aplicação

em PHP que consuma este web-service.

6. Implementar e testar a aplicação em PHP.

7. Homologar o web-service e a aplicação em PHP.

1.5 – Metodologia

A metodologia de trabalho usada é a Scrum Academic (Apêndice A) idealizada

pelo Prof. Sergio Barbosa Villas-Boas que faleceu durante a realização deste projeto que

é uma variação do Scrum.

Serão utilizadas arquiteturas de código aberto para reduzir o custo de

desenvolvimento e implementação. Será feito uma API para se acessar estas informações

3

que serão descritas por WSDL (Webservice Description Language) de forma a se poder

acessar pela internet por qualquer outro usuário via XML usando o protocolo SOAP.

Será feita também uma aplicação web em PHP 7 que vai consumir os serviços do

nosso web-service, de modo, a se ter uma forma de validar o nosso sistema em questão.

1.6 – Descrição

No capítulo 2 falarei da fundamentação teórica envolvida na solução do trabalho.

No capítulo 3 será apresentada como foi a implementação propriamente dita, ou melhor,

a solução prática desta realização de modo a se saber se realmente é viável. Por fim no

capítulo 4 é apresentada a conclusão, bem como, possíveis melhorias que podem ter sido

levantadas durante a etapa de implementação e teste.

4

Capítulo 2

Fundamentação Teórica

2.1 – Web Service

A arquitetura SOA (Service Oriented Architecture), ou em português arquitetura

orientada a serviços, define um estilo de arquitetura de software no qual podem existir

várias aplicações diferentes se comunicando para a realização de uma determinada

função. Cada aplicação desta executa ao que denominamos de serviços que se comunicam

através de uma rede.

Nesta arquitetura cada aplicação disponibiliza os seus serviços, de forma que um

cliente possa utilizá-los para sua própria necessidade sem se preocupar como eles foram

implementados e onde estão sendo executados. Para isto é necessário que utilizem das

mesmas formas de trocas de dados, chamadas aos serviços e que estejam conectadas por

um mesmo barramento de serviços, isto é, que possuam uma interface pré-definida para

se comunicarem. Pode-se dizer que tem-se uma arquitetura de n-camadas onde numa

camada se encontra os serviços que podem ser acessados, ou melhor, consumidos por

qualquer cliente de outra camada ou até por um outro serviço funcionando como cliente

de uma outra camada.

O conceito de serviços em uma aplicação já existe a muito tempo. Serviços são

parecidos com componentes de forma que ao se juntarem todos eles podem constituir

uma aplicação completa. Os serviços são geralmente caracterizados como funções

disponibilizadas para outros sistemas, como por exemplo: o preenchimento de um

formulário, extrato bancário, reserva de um quarto de hotel, compra de uma passagem de

avião e etc ... Observe que geralmente serviços são de baixo acoplamento, isto é, eles são

muito independentes, um não necessariamente precisa do outro. Neste sentido, eles

podem ser implementados por diferentes linguagens e tecnologias, isto é, eles encapsulam

a lógica de forma que cada serviço realize uma tarefa específica. Claro que pode existir

um serviço que realiza toda a tarefa por englobar a lógica de todos os outros serviços.

Desta forma pode-se dizer que em SOA os serviços são projetados para:

5

Ter um baixo acoplamento.

Ter um meio de acesso a esse serviço.

Ter uma autonomia pela lógica que encapsulam.

Esconder a sua lógica do mundo exterior.

Permitir o reuso.

Serem agrupados para formar um serviço composto.

Minimizar a retenção da informação em determinada atividade.

Poderem ser exteriormente descritos, de forma a ser encontrados e

avaliados por mecanismos de descoberta distintos.

O Web-service, por sua vez, é uma solução que utiliza a arquitetura SOA,

padronizado pelo W3C e OASIS, para serviços via web que não se preocupam com quais

tecnologias foram usadas para a implementação. Esta tecnologia (web-services) começou

a aparecer no final da década de 90 com a necessidade de vários sistemas diferentes

precisarem se comunicar através de uma mesma rede, assim, o seu uso permite que

plataformas heterogêneas de software e hardware sejam integradas de forma transparente.

O W3C (2004) define web-service da seguinte maneira:

“Um Web-Service é um sistema de software desenvolvido para permitir

interações máquina-máquina através de uma rede. É uma interface descrita para

ser consumida por máquinas (WSDL). Outros sistemas interagem com o Web-

Service através de mensagens SOAP, geralmente enviadas através de HTTP em

conjunto com outros padrões relacionados à web [9] (2004). ”

Tanto o WSDL, XML e SOAP são padrões largamente utilizados no web-

services, sendo o WSDL um descritor da API utilizada, XML uma linguagem utilizada

na internet e o SOAP um protocolo de comunicação.

Existe um outro estilo de web-service chamado de REST que anda sendo muito

utilizado. Ele foi criado por Roy Fielding em sua dissertação de pós-doutorado[13], no

ano 2000. Ele não é uma tecnologia e nem um protocolo e sim um conjunto de princípios

que, quando implementados, trazem algumas vantagens e restrições ao projeto. Este estilo

tira o máximo de proveito da arquitetura web já existente. Ele é implementado, da mesma

forma de como a web funciona para páginas em HTML, utilizando de hyperlinks via

HTTP para a chamada de serviços possibilitando trocas de dados de suas informações.

6

O web-services SOAP é implementado em camadas que se comunicam através do

uso de interfaces onde ele fica numa camada inferior provendo serviços a várias camadas

superiores chamadas de clientes que podem ser: Tablet, PC (GUI), Smatphones, web-

services e etc., conforme mostrado na figura 2.1 abaixo:

Figura 2.1 – Arquitetura SOA “web-services”

As vantagens desta arquitetura para o web-service são:

As regras de negócios são escritas somente uma vez para vários clientes

distintos.

Não é necessário implementar todos os clientes de uma vez, eles podem ser

implementados somente quando se tornam necessários.

O mesmo serviço pode ser usado por diferentes clientes.

Com esta arquitetura fica separado o desenvolvimento das regras de negócios da

apresentação, podendo assim, separar os desenvolvedores em dois times, onde o

primeiro é tipicamente mais experiente e mais caro do que o segundo.

É possível ter diferentes páginas web (apresentações) usando o mesmo serviço.

O custo total de desenvolvimento é reduzido.

Com o web-service é possível publicar informações na Internet que estão isoladas da

base de dados oferecendo um certo tipo de segurança a seus clientes. Porém uma outra

questão relacionada a segurança do web-service são:

7

Autenticidade - ter a certeza que uma transação do Web Service ocorreu entre o

servidor e seu cliente.

Privacidade - todas as mensagens trocadas entre o servidor e o cliente não são

interceptadas por uma pessoa não autorizada.

Integridade - as mensagens enviadas tanto pelo servidor ao cliente, como o

contrário, devem permanecer inalteradas.

Para este tipo de problema ainda não se chegou a um padrão de qual mecanismo de

segurança deve ser usado, sendo ainda um ponto fraco da tecnologia. Atualmente os

principais mecanismos de segurança utilizados são:

SSL (Secure Socket Layer) [12 1996] – Fácil de ser configurado e permitindo

proteger muito bem as informações confidenciais, tendo um ponto negativo de ser

lento.

Xml signature [11][9 2000] – Define a sintaxe XML e regras de processamento

para criação e representação de assinatura digital.

Xml encryption [11][9 2002] – Permite criptografar dados dos XML.

Ws-security (Web Services Security) – é uma tentativa de fornecer uma forma de

criptografar as mensagens SOAP utilizando o Xml signature e Xml encryption

apoiadas pela Microsoft, IBM e Verisign.

SAML (Security Assertion Markup Language) [10 2001] – é um padrão que está

sendo muito utilizado para a autenticação e autorização de direitos entre diferentes

web-services.

2.2 – Dados acessíveis via HTTP

Atualmente comunicação do web-service é feita pela linguagem XML

transportada pela internet via HTTP ou HTTPS. O XML é montado de acordo com a

necessidade de se usar um determinado serviço do web-service com o formato

especificado pelo protocolo SOAP.

O protocolo SOAP foi aceito pelo W3C no ano de 2000 e vem sendo amplamente

adotado por vendedores e fornecedores de web-services, se tornando cada vez mais uma

8

tecnologia muito popular. Uma grande vantagem deste protocolo em relação a outros é

que ele estabelece uma estrutura de comunicação entre serviços via HTTP ou HTTPS não

amarrada a nenhum fornecedor, o que não ocorria com os outros protocolos. No ano

seguinte o W3C publicou a especificação WSDL que estabelece um padrão para se

descrever uma interface web-services e posteriormente a especificação UDDI (Universal

Description, Discovery and Integration) que permite a um mecanismo padrão de

descoberta dinâmica das descrições dos serviços. Foi, então, estabelecida a primeira

geração da plataforma web-services. Observe na figura 2.2 abaixo o nível de

relacionamento entre estes padrões.

Figura 2.2 - Relacionamento entre especificações de primeira geração

O WSDL é um padrão baseado em XML que define como os clientes vão se

comunicar com os web-services através dos seus serviços fornecidos. Ele na realidade

fornece a descrição completa do que os clientes precisam para acessarem os respectivos

serviços de um específico web-service, podendo, assim, consumi-los. Existem

9

ferramentas de apoio que usam o WSDL para facilitar o desenvolvimento de aplicações

clientes, ou melhor, o consumo do serviço. Por isso, na maioria dos casos, o

desenvolvedor não precisa trabalhar diretamente com o SOAP, ficando isto numa camada

inferior.

O SOAP baseia-se no procedimento de consumir um serviço de um específico

endereço. Ele define o serviço e os argumentos necessários para a sua execução, isto tudo

no formato XML, sendo, assim, independente de qual plataforma é usada em ambos. Pode

ser enviado pela web via HTTP, HTTPS, SMTP ou outro.

O SOAP define um formato de mensagem baseado em 3 partes: Envelope, Header

(opcional) e Body, conforme mostrado pela figura 2.3 abaixo.

Figura 2.3 – Formato de mensagem do SOAP

Como pode ser visto a tag “Envelop” é a raiz. Ela delimita toda a mensagem,

começo e fim, bem como, as declarações de namespace. Na tag “Header” é onde se

definem informações adicionais da mensagem para o servidor como a autenticação,

autorização, assinaturas digitais, configurações de segurança e etc. Esta tag é opcional. Já

na tag “Body” se encontra o corpo da mensagem que será entregue ao destinatário final

com o específico serviço e seus argumentos com o formato especificado no WSDL que

serão requisitados. No final há uma seção para envio de anexo SOAP que pode ser usada

para o envio de dados grandes. Abaixo é mostrado um exemplo de um SOAP a seguir:

10

Figura 2.4 – Exemplo de um SOAP

Neste exemplo definimos o header com as credenciais de o usuário e senha e no

body chamamos um serviço deste web-service chamado de “CadastrarPessoa” com duas

pessoas para serem cadastradas com seus respectivos parâmetros. Observe que a resposta

do web-service segue o mesmo formato.

O protocolo UDDI foi desenvolvido para a organização e registro de web-

services, mantido incialmente por um consórcio que envolve IBM, Microsoft e Arriba.

Ele nada mais é que um serviço aonde as empresas podem registrar e buscar serviços web.

Um registro de UDDI tem 3 tipos de informação:

Informações gerais de cada organização, tais como o nome, endereço e contatos.

Informações de organizações e serviços por categorias de negócios.

Informações técnicas sobre os serviços providenciados pelas organizações.

O UDDI prove 3 tipos de funções: publicação (uma forma de divulgação do

serviço), descoberta (uma forma de procurar um serviço) e ligação (permite o uso do

serviço).

11

2.3 – Scrum Academic

Para tratar do assunto Scrum Academic é necessário inicialmente apresentar o

Scrum, visto que o primeiro é uma variação do segundo.

O Scrum não é um processo padronizado em que se seguem passos pré-definidos

que garantem que no final se conclua um projeto no prazo e dentro do orçamento com

uma alta qualidade. O Scrum na realidade é um framework de desenvolvimento iterativo

e incremental utilizado no gerenciamento de projeto alinhado com a prática de software

ágil. Pode-se dizer que: “O framework Scrum é um conjunto de valores, princípios e

práticas que fornecem a base para que a sua organização adicione suas práticas

particulares de engenharia e gestão e que sejam relevantes para a realidade da sua

empresa. O resultado será uma versão de Scrum que é exclusivamente sua.”[7].

O Scrum foi incialmente projetado por Takeuchi e Nonaka em 1986 para o

gerenciamento de projetos em empresas de fabricação de automóveis e produtos de

consumo, aonde foi notado uma melhora significativamente nos resultados. Em 1994 Jeff

Sutherland, John Scumniotales e Jeff McKenna conceberam, documentaram e

implementaram o Scrum na empresa Easel Corporation. Já em 1995 Ken Schwaber

formalizou a definição de Scrum e ajudou a implantá-lo na gerência de desenvolvimento

de softwares em todo o mundo. O Scrum pode ser usado para outros tipos de gerência de

projeto não só o de software como no início de sua concepção.

A base fundamental do Scrum é dividida nas seguintes práticas:

Papéis fundamentais.

Product Owner:

Scrum Master

Time Scrum

Atividades básicas.

Planning e Execução do Sprint

Daily Scrum e Sprint Review

Sprint Retrospective e Product Backlog Grooming

12

Documentos (Arterfatos)

Product Backlog

Sprint Backlog

Definition of Done

O Product Owner é quem define o que será alcançado, como será o produto final.

É responsável por informar a toda a equipe sobre o que querem alcançar com detalhes,

colaborando ativamente com o Scrum Master e o Time Scrum.

O Scrum Master tem o papel de coordenar toda a equipe de forma a estarem mais

adequados ao conjunto de prática, princípios e valores do Scrum a fim de personalizar o

processo para ir de acordo com a organização especifica. O Time Scrum são todos os

profissionais de informática envolvidos no projeto. O Product Backlog é uma lista

priorizada com todas as funcionalidades necessárias a determinado produto podendo ser

modificada ao longo do processo.

O Sprint é uma célula de execução de trabalho que deverá ser feito em ciclos até

um determinado período de tempo de no máximo em 1 mês. O Sprint Planning é aonde

se define o subconjunto do Product Backlog a ser feito em um Sprint. O Daily Scrum é

uma reunião diária, geralmente no mesmo horário, com todos os membros da equipe. O

Sprint Review feito no final do Sprint para verificar as necessidades de adaptação do

produto. O Sprint Retrospective feito depois Sprint Review para verificar a necessidade

de adaptação do processo de trabalho. Já no Definition of Done se verifica se o Sprint

está terminado, atendendo as especificações.

A seguir, na figura 2.5, é apresentado um gráfico ilustrando a forma como são

feitas as atividades com os artefatos principais.

13

Figura 2.5 – Atividade e Artefatos Scrum

O Product Owner que tem a visão completa do projeto cria o Product Backlog, na

atividade denominada Grooming, aonde se cria uma lista priorizada de funcionalidades

necessária para a execução do produto final. Depois disto ele faz uma reunião para o

planejamento do Sprint (Sprint Planning) que irá definir o Sprint Backlog a ser executado

no Sprint. Reuniões diárias são feitas (Daily Scrum) para se ir acompanhando de como

está a execução do Sprint até terminá-lo e realizar as reuniões de revisão (Sprint Review)

e retrospectiva (Sprint Retrospective). Ficando por último a definição de pronto

(Definition of Done) aonde se conclui que o Sprint realmente terminou. Assim

sucessivamente até se chegar ao produto final.

Conforme mencionado antes o método utilizado é o Scrum Academic idealizado

pelo Prof. Sergio Barbosa Villas-Boas que pode ser encontrado uma descrição completa

feita pelo próprio autor no apêndice A. A seguir será realizada uma breve menção sobre

este método.

O Scrum Academic começa com a definição do que se quer fazer. A definição

deve ser escrita num documento denominado “Project Requisites”. O professor será o

“Client” ou “Paying Customer” do projeto. O professor tem que aprovar o documento

para que os desenvolvedores fiquem habilitados oficialmente a desenvolver o projeto, ele

fará isto com base na proposta do curso em questão avaliando se o grau de complexidade

é adequado.

14

O conceito de Sprint do Scrum também usado no Scrum Academic. A ideia é pré-

definir o menor número de encontros dos grupos de alunos de cada projeto, e não é

recomendável um valor menor que 3. Claro que isto pode ser personalizado para a

necessidade de cada curso pelo professor responsável.

Nos primeiros encontros o professor verifica se os alunos fizeram o programa

“hello word” com todos as dependências definidas no projeto. Neste Sprint é verificado

o ambiente de desenvolvimento, tal como, as bibliotecas, ferramentas e requisitos para

instalar e testar o “hello word”. Nos outros encontros os alunos vão apresentando as

implementações do que foi definido nos requisitos ordenados por prioridades, e o

professor vai avaliando se está tudo ocorrendo de forma planejada até chegar ao final.

Observe que a forma de trabalho do presente Projeto de Graduação é um Scrum

Academic Solo, porque só existe um aluno na equipe de desenvolvimento. No início o

aluno faz o documento de requisitos que é aprovado pelo professor e depois

frequentemente este aluno entra em contato com o professor para ir avançando no

desenvolvimento do projeto, como se fossem os encontros propostos pelo método. Nestes

“contatos” o aluno vai apresentando e discutindo o que já foi feito e o que tem para fazer

com professor até se chegar ao resultado final.

15

Capítulo 3

Solução Proposta

3.1 – Descrição do Problema

O problema a ser resolvido neste trabalho é implementar uma solução web-

services SOAP com serviços para o cadastramento de módulos, pessoas, listagens e

estatísticas. Serão necessários serviços para o cadastramento de pessoas com a inserção

e/ou alteração dos seus atributos, além de serviços para o cadastramento de módulos com

os seus respectivos arquivos. Adicionalmente, alguns serviços secundários também serão

necessários, a saber: serviços para a ativação ou não de clientes e módulos, serviços de

listagens de todos os arquivos com seus respetivos módulos cadastrados e comprados,

bem como, um histórico com as alterações destes módulos já existentes e serviços para a

realização de uma ou mais compras de módulos. Neste sentido, todos os serviços deverão

possuir credencias que possibilitem definir seus privilégios de usuários (administrador,

donos ou clientes).

Por fim, haverá a necessidade de desenvolver uma aplicação em PHP para

consumir todos estes serviços apresentando na tela seus resultados.

3.2 – Arquitetura da Solução

No web-service existem serviços para a execução do monitoramento dos arquivos

a serem baixados pela Internet. Toda a operação para baixar, cadastrar, comprar e

autorizar passa pelo web-service. Desta forma, o web-service é uma camada inferior com

cliente PHP numa camada superior, não precisando de mais nada ao não ser o web-

service para a execução da tarefa.

Neste web-service são definidos os usuários como pessoas, qualquer usuário

existente são derivados das pessoas. Assim, o Dono, o Cliente e o Root são descendentes

de pessoa. Um Dono é uma pessoa que possui módulos disponibilizados para a compra

na web. Já um Cliente é uma pessoa que pode comprar um ou mais módulos para baixar

16

da web. Um Dono pode também ser um Cliente. O Dono autoriza ou desautoriza quem

são os Clientes que podem comprar seus módulos. Agora o Root pode apenas cadastrar

pessoas que se tornam Clientes ou Donos no futuro, em contraste com o Dono que só

cadastra Clientes.

Quando se consome um serviço as credenciais serão pessoas que podem ser

interpretadas como Dono, Cliente ou Root. Os Donos é que gerenciam todo o processo

de cadastramento de arquivos, autorização para quem pode comprar, cadastrar pessoas e

ativar ou desativar módulos. O Dono tem acesso à lista de todos os módulos cadastrados,

disponíveis para compra dos que ainda não foram comprados, dos arquivos já comprados

para disponibilizá-los para baixar e dos históricos de mudança de preços.

Observe que um módulo pode ter vários Clientes mas somente um Dono. Ele

também pode ter vários arquivos, mas um arquivo só pode pertencer a um módulo. Agora

um Cliente pode adquirir qualquer módulo, desde que, o respectivo Dono autorize. Os

históricos de módulos vão sendo contabilizados ao se mudar os preços existentes, tendo

o direito adquirido por um Cliente que já os comprou, todos os possíveis novos arquivos

sem custos adicionais.

Sob esta ótica, é apresentado o diagrama de entidades do banco de dados

modelado na figura 3.1 e a Tabela 3.1 com as descrições sendo em seguida os 11 casos

de uso descritivos de modo mais formal e completo, já no apêndice B encontra-se o script

para a geração das tabelas pelo MySql Workbench.

Figura 3.1 – DER do banco de dados

17

Tabela 3.1 – Descrições das tabelas do banco de dados

Tabela Entidade Descrição Tipo

tb_person

id Chave primária Inteiro

pwd Senha String

login Login String

enable Ativo Boolean

creation Data de criação Data

tb_module


name Nome do módulo String

price Preço Double


creation Data da criação Data

tb_file


tb_module_id Chave estrangeira Inteiro

name Nome do arquivo String

tb_module_person

tb_module_id Chave primária e

estrangeira Inteiro

tb_person_id Chave primária e

estrangeira Inteiro

owner Dono do módulo Boolean


tb_purchased_module


estrangeira Inteiro


estrangeira Inteiro

purchase_date Data de compra Data

paid Valor pago Double

tb_rating_module



estrangeira Inteiro


estrangeira Inteiro

price Preço Double

creation Data da criação Data

18

Figura 3.2 – Casos de uso do web-service

CU001: Cadastrar Pessoas. Objetivo: Permitir que o root ou Dono cadastre ou recadastre, mudando atributos, de

Pessoas (Donos ou Clientes) no Web Services.

Atores: root, Dono.

Trigger: O root ou Dono gera um xml (<CadastraPessoas>conteúdo</

CadastraPessoas>) com suas credenciais.

Fluxo Principal:

1. O root ou Dono gera o conteúdo do xml com os respectivos atributos das

Pessoas <pessoa><login></login><senha></senha><ativo></ativo></pessoa>a

serem cadastrados ou recadastradas no Sistema

2. O Sistema lê o xml e cadastra ou recadastra as Pessoas no Web Services.

3. O Sistema retorna um xml (<RespCadastraPessoas>ok</

RespCadastraPessoas >) se as Pessoas foram cadastrados ou recadastradas com

sucesso ou retorna um xml (<RespCadastraPessoas >MsgErro</

19

RespCadastraPessoas >) se ocorreu algum erro sendo MsgErro a mensagem

explicando qual erro.

Pós-condição: O root ou Dono recebe o xml resposta

(<RespCadastraPessoas >conteúdo </ RespCadastraPessoas >).

CU002: Cadastrar arquivos.

Objetivo: Permitir que um Dono ou uma Pessoa cadastre ou recadastre os módulos com

os seus respectivos arquivos para baixar da web e suas configurações. Acrescentando os

módulos, seus arquivos e suas configurações que sejam novos, bem como, atualizando

os módulos já existentes.

Atores: Dono, Pessoa.

Trigger: Um Dono ou Pessoa gera um xml

(<CadastraArquivos>conteúdo</CadastraArquivos>)com suas credenciais.

Fluxo Principal:

4. O Dono ou Pessoa gera o conteúdo do xml com os respectivos módulos

(<modulo><nome></nome>

<ativo></ativo><cliente><login></login><senha></senha><ativo></ativo></cli

ente><preco></preco><arquivo><nome></nome><obj></obj></arquivo></mo

dulo>) onde contém os arquivos e seus respectivos parâmetros.

1. O Sistema lê o xml e cria ou atualiza os módulos com seus respectivos

parâmetros e arquivos que se encontram no conteúdo.

2. O Sistema retorna um xml

(<RespCadastraArquivos>ok</RespCadastraArquivos>) se os arquivos foram

cadastrados com sucesso ou retorna um xml

(<RespCadastraArquivos>MsgErro</RespCadastraArquivos>) se ocorreu algum

erro sendo MsgErro a mensagem explicando qual erro.

Pós-condição: O Dono ou Pessoa recebe o xml resposta

(<RespCadastraArquivos>conteúdo </RespCadastraArquivos>).

CU003: Autorizar ou desautorizar permissões de download.

Objetivo: Permitir que um Dono autorize ou desautoriza quais são os Clientes que

podem baixar os seus módulos da web.

Atores: Dono.

Trigger: Um Dono gera um xml (<AutorizarClientes>conteúdo</AutorizarClientes>)

com suas credenciais.

Fluxo Principal:

1. O Dono gera o conteúdo do xml com os respectivos módulos

(<modulo><nome></nome><cliente><login></login><ativo></ativo></cliente

></modulo>) onde contém o nome e logins dos Clientes que vão ter permissão

para baixa os arquivos.

2. O Sistema lê o xml e autoriza ou deautoriza os clientes de seus respectivos

módulos a baixar seus arquivos.

20

3. O Sistema retorna um xml (<RespAutorizarClientes>ok</

RespAutorizarClientes >) se os clientes foram autorizados com sucesso ou

retorna um xml (<RespAutorizarClientes >MsgErro</ RespAutorizarClientes >)

se ocorreu algum erro sendo MsgErro a mensagem explicando qual erro.

Pós-condição: O Dono recebe o xml resposta (<RespAutorizarClientes >conteúdo</

RespAutorizarClientes >).

CU004: Ativar ou desativar modulo de um Dono.

Objetivo: Permitir que um Dono ative ou desative um ou mais módulos seus da web.

Atores: Dono.

Trigger: Um Dono gera um xml (<AtivarModulos>conteúdo</AtivarModulos>) com

suas credenciais.

Fluxo Principal:

1. O Dono gera o conteúdo do xml com os respectivos nomes dos módulos

(<modulo><nome></nome><ativo></ativo></modulo>) que serão ativados ou

desativados

2. O Sistema lê o xml e ativa ou desativa os seus respectivos módulos.

3. O Sistema retorna um xml (<RespAtivarModulos >ok</ RespAtivarModulos >)

se os modulos foram ativados ou reativados com sucesso ou retorna um xml

(<RespAtivarModulos >MsgErro</ RespAtivarModulos >) se ocorreu algum

erro sendo MsgErro a mensagem explicando qual erro.

Pós-condição: O Dono recebe o xml resposta (<RespAtivarModulos >conteúdo </

RespAtivarModulos >).

CU005: Obter a lista de todos os módulos cadastrados com ou sem um intervalo de

data.

Objetivo: Obtém a lista de todos os módulos cadastrados, bem como, suas

configurações de um Dono com ou sem um intervalo de data.

Atores: Dono.

Trigger: Um Dono gera um xml (<LeModulos>conteúdo</LeModulos>) com suas

credenciais.

Fluxo Principal:

1. O Dono gera o conteúdo do xml com ou sem um intervalo de data

(<dataini></dataini> <datafim></datafim>) selecionados para ler os módulos.

2. O Sistema prepara os xmls

(<modulo><nome></nome><ativo></ativo><cliente><login>

</login><ativo></ativo></cliente><preco></preco></modulo>) com todos os

módulos (nomes, clientes e preço) cadastrados do Dono em questão com ou sem

um intervalo de data.

3. O Sistema retorna um xml (<RespLeModulos>conteúdo</RespLeModulos>

onde o conteúdo são todos os xmls preparados no passo 1.

Pós-condição: O Dono recebe o xml resposta

(<RespLeModulos>conteúdo</RespLeModulos>).

21

CU006: Obter a lista de todos os nomes dos arquivos cadastrados em um ou mais

módulo com ou sem um intervalo de data, disponíveis para serem comprados.

Objetivo: Obtém a lista de todos os nomes dos arquivos cadastrados de uma ou mais

módulos de um Dono ou Cliente com ou sem um intervalo de data, disponíveis para

serem comprados.

Atores: Dono, Cliente.

Trigger: Um Dono ou Cliente gera um xml (<LeArquivos>conteúdo</LeArquivos>)

com suas credenciais.

Fluxo Principal:

1. O Dono ou Cliente gera o conteúdo do xml com os respectivos nomes dos

módulos com ou sem um intervalo de data

(<dataini></dataini><datafim></datafim><nome></nome>) selecionados para

ler os nomes dos arquivos.

2. O Sistema prepara os xmls (<modulo><nome></nome><ativo></ativo>

<preco></preco><arquivo><nome></nome></arquivo></modulo>) com todos

os nomes dos arquivos dos seus respectivos módulos cadastrados do Dono ou

Cliente em questão.

3. O Sistema retorna um xml (<RespLeArquivos>conteúdo</RespLeArquivos>)

onde o conteúdo são todos os xmls preparados no passo 2.

Pós-condição: O Dono ou Cliente recebe o xml resposta

(<RespLeArquivos >conteúdo</ RespLeArquivos >).

CU007: Obter a lista de todos os módulos comprados com ou sem um intervalo de data.

Objetivo: Obtém a lista de todos os nomes dos módulos comprados com seus

respectivos preços, data de pagamento, arquivos e Cliente, se for Dono, com ou sem um

intervalo de data de um Dono ou Cliente.

Atores: Dono, Cliente

Trigger: Um Dono ou Cliente gera um xml (<LeModulosCompradosData>conteúdo</

LeModulosCompradosData>) com suas credenciais.

Fluxo Principal:

1. O Dono ou Cliente gera o conteúdo do xml com ou sem intervalo da data para

ler os respectivos atributos dos módulos


lista.

2. O Sistema prepara os xmls (<modulo><nome></nome><ativo></ativo>

<cliente><login></login></cliente><data><data><preco></preco>><arquivo><

nome></nome></arquivo></modulo>) com todos os nomes, data, cliente,

arquivos e preço total dos seus respectivos módulos cadastrados no intervalo de

data especificados do Dono ou Cliente em questão.

3. O Sistema retorna um xml (<RespLeModulosCompradosData>conteúdo</

RespLeModulosCompradosData >) onde o conteúdo são todos os xmls

preparados no passo 2.

22


(<RespLeModulosCompradosData >conteúdo</ RespLeModulosCompradosData >).

CU008: Obter a lista de todos os módulos já criados e atualizados de um intervalo de

data.

Objetivo: Obtém a lista de todos os nomes dos módulos já criados e atualizados com

seus respectivos preços, data de pagamento e Cliente de um intervalo de data de um

Dono.

Atores: Dono.

Trigger: Um Dono gera um xml (<LeModulosHistoricoData>conteúdo</

LeModulosHistoricoData >) com suas credenciais.

Fluxo Principal:

1. O Dono gera o conteúdo do xml com o intervalo da data para ler os respectivos

atributos dos módulos


lista.

2. O Sistema prepara os xmls

(<modulo><nome></nome><data><data><preco></preco> </modulo>) com

todos os nomes, data de criação e preço dos seus respectivos módulos

cadastrados no intervalo de data especificados do Dono em questão.

3. O Sistema retorna um xml (<RespLeModulosHistoricoData >conteúdo</

RespLeModulosHistoricoData >) onde o conteúdo são todos os xmls preparados

no passo 2.

Pós-condição: O Dono recebe o xml resposta

(<RespLeModulosHistoricoData >conteúdo</ RespLeModulosHistoricoData >).

CU009: Executa a compra de um ou mais módulos.

Objetivo: Executa a compra de um ou mais módulos de acordo com o preço total

informado de um Cliente ou Dono.

Atores: Dono, Cliente.

Trigger: Um Dono ou Cliente gera um xml (<ComprarModulos>conteúdo</

ComprarModulos>) com suas credenciais.

Fluxo Principal:

1. O Dono ou Cliente gera o conteúdo do xml com os nomes dos respectivos

módulos e o preço total da compra a ser

efetuada(<preco></preco><nome></nome>).

2. O Sistema executa a compra verificando se o preço total informado é suficiente

para realizar toda a compra, se não for cancela toda a compra.

3. O Sistema retorna um xml

(<RespComprarModulos>conteúdo</RespComprarModulos>) onde o conteúdo

pode ser Ok se a compra foi realizada com sucesso ou o Erro.

23


(<RespComprarModulos>conteúdo</ RespComprarModulos>).

CU010: Adquire um ou mais módulos.

Objetivo: Um cliente compra um ou mais módulos para baixar da web.

Atores: Cliente.

Trigger: Um Cliente se log no site da web.

Fluxo Principal:

1. O sistema exibe uma lista de módulos que o Cliente pode adquiri.

2. O Cliente escolhe um ou mais módulo para comprar.

Pós-condição: Um Cliente da logoff do site da web.

CU011: Baixar um ou mais arquivos.

Objetivo: Um cliente baixa um ou mais arquivos do(s) módulo(s) que comprou pela

web.

Atores: Cliente.

Trigger: Um Cliente se log no site da web.

Fluxo Principal:

1. O sistema exibe uma lista de módulos com seus respectivos arquivos que o

Cliente adquiriu.

2. O Cliente baixa um ou mais arquivos.

Pós-condição: Um Cliente da logoff do site da web.

3.3 – Implementação da Solução

A linguagem utilizada para a implementação do web-service foi o Java, com a

ferramenta Axis2. Inicialmente foram feitas seis classes (beans) para os argumentos

(dados) dos serviços de envio e resposta que estão listadas na figura 3.3 abaixo. Observe

que só foram listados os atributos deixando de mostrar os métodos set ou get que servem

para escrever e ler os respectivos atributos nas classes, como por exemplo, na classe

Pessoa teríamos para o atributo nome: setNome(String nome) e getNome().

24

Figura 3.3 – Dados (beans)

Foram implementadas algumas classes utilitárias com funções auxiliares para

serem usadas em todo o projeto. A descrição destas classes é apresentada na Tabela 3.2.

Tabela 3.2: Descrição das classes utilitárias

Classe Descrição

DBUtils.java Encapsula todo o acesso ao banco de dados

DFLongYear.java Converte a data para uma string como “dd/mm/aaaa”

e vice-versa.

DoubleFormat.java Converte um número double para uma string e vice-

versa

Global.java Classe com variáveis globais

25

Uma outra classe denominada de “ContadorArquivosBaixados.java” foi

implementada com todos os serviços do web-service listados na figura 3.4.

Figura 3.4 – Serviços

Estas classes são utilizadas com o Axis2 para gerar o web-service, e o WSDL está

listado no apêndice C. As classes listadas na figura 3.3 serão convertidas pelo Axis2 em

XML que servirão de argumentos para os serviços. Como exemplo, a classe Pessoa seria

em XML:

<pessoa>

<nome></nome>

<login></login>

<senha></senha>

<ativo></ativo>

</pessoa>

onde cada valor dentro destas tags seriam os valores dos atributos da classe Pessoa.

Observe que sempre que se pode usar mais de uma tag, coloca-se ela como um array em

Java, como por exemplo, no serviço CadastrarPessoas. O argumento Pessoa[] pessoa

possibilita cadastrar mais de uma pessoa ao mesmo tempo. O Axis2 faz toda a

transformação dos arrays e XMLs para os serviços, não precisando o desenvolvedor se

preocupar com isto.

Existe um arquivo denominado ser services.xml que possui todas as configurações

necessária para o Axis2 com o NetBeans gerar o arquivo binário do web-service

denonimado “meuWSContadorDeArquivos.aar”. Este arquivo tem que ficar dentro da

pasta “services” do axis2.war para ser feito o deploy no Tomcat. Observe que este

26

axis2.war tem toda a informação necessária para executar o web-service no Tomcat ou

similar. Na figura 3.5 abaixo é mostrada os arquivos no projeto completo no NetBeans.

Figura 3.5 – Projeto do NetBeans

O arquivo “PWServerHandler.java” na pasta “core” é aonde o Axis2 é

implementada a validação das credenciais dos serviços. Assim, tem-se tudo necessário

para gerar o web-service.

Em seguida, foi feita uma aplicação em PHP 7 para testar este web-service.

Inicialmente foi criado no arquivo mySoap.php uma classe denominada “WSCliente”

aonde se encontram todas as implementações para se conectar com o web-service. Cada

27

serviço está representado por um método com seus respectivos argumentos. As classes

do PHP “SoapClient” e “SoapHeader” tem todas as funções necessárias para se criar um

cliente que consume um web-service através do seu WSDL. Observe que em PHP

também utiliza-se de array como passagem dos argumentos para serviços. Por isto, dentro

desta classe em que foi criado o “WSCliente” existem métodos que foram implementados

para fazer a conversão de uma string em PHP com o XML para um array e vice-versa.

Na figura 3.6 está a lista completa de todos os arquivos PHP utilizados.

Figura 3.6 – Arquivos em PHP

28

A aplicação PHP começa com a tela de login que se encontra no arquivo

index.php.

Figura 3.7 – Tela de login PHP

Nesta tela o Cliente, Dono ou Root podem realizar o login preenchendo os campos

usuários, senha ou data (opcional) inicial e final. Observe que se quiser gerenciar os

módulos (usuário Dono) tem que pedir o login no modo administrativo, já se for só

comprar ou baixar, não é necessário escolher esta opção no login. Observe também que

existe a opção de Cadastrar Módulos que seria para um novo Dono, quero dizer, quando

o Dono ainda não existe no cadastro, cadastra-se este novo Dono com o usuário root e

depois usa está opção. Isto é feito por motivos de segurança para não permitir que um

Cliente se cadastre como Dono sem autorização do root. Se colocar o usuário como Root

ele automaticamente passa para a tela de cadastrar Pessoas. Veja na tabela abaixo a

descrição das funções dos arquivos PHP na aplicação.

Tabela 3.3 – Descrições das funções dos arquivos PHP

Arquivo Descrição

mySoap.php Cliente Soap

doCompra.php Confirma a compra

compra.php Realiza a compra

29

ativaDesativa.php Ativa e desativa Clientes e Módulos

listaHistoricoModulos.php Lista históricos dos módulos de um

Cliente e Dono

gerenciarModulos.php Gerencia módulo de um Dono

index.php Tela de login

doCadastrarPessoas.php Confirma o cadastro de um Dono ou

Cliente

cadastrarPessoas.php Realiza o cadastro de um Dono ou

Cliente

cadastrarModulos.php Cadastra módulos

doCadastrarModulos.php Confirma o cadastro de módulos

abertura.php Baixa ou compra arquivos

Observe que com todas estas funções pode-se consumir todo o web-service

permitindo, assim, fazer uma análise completa dos serviços.

3.4 – Análise e Testes

Para efeito de análise e teste será simulada uma situação onde professores

disponibilizam matérias para seus alunos. Serão utilizados nomes fictícios como:

Professor n, Aluno n, Matéria n, Apostila n, Exercícios n e Lista de Testes n, onde n é um

número inteiro sequencial começando por 1 com o valores máximos distintos.

Inicialmente serão cadastradas as pessoas: Professor 1, Professor 2, Professor 3,

Aluno 1, Aluno 2, Aluno 3, Aluno 4 e Aluno 5 (Figura 3.8).

30

Figura 3.8 – Cadastro de Pessoas

Nesta tela não existem ainda diferenças entre as pessoas, somente no nome. O

botão “Montar” envia o registro atual para a lista dos “Usuários montados” e somente no

final, ao acionar o botão “Adicionar”, é chamado o serviço “cadastraPessoas” para inserir

na base.

31

Feito isto, segue-se para o cadastro dos módulos (“Matéria”), efetuando o login

com o usuário “Professor 1”, “Professor 3”, acionado o botão “Cadastrar Módulos” da

própria tela inicial. Observe que isto é feito porque ainda não existe nenhum módulo com

o seu “Dono”, que neste caso seria um “Professor”. Desta forma é feita a montagem e

depois adiciona-se o módulo chamando o serviço “cadastraArquivos” (Figuras 3.9 e

3.10).

Figura 3.9 – Cadastrar Módulos do Professor 1

32

Figura 3.10 – Cadastrar Módulos do Professor 3

Feito isto, os usuários (Pessoa) “Professor 1” e “Professor 3” tornaram-se Donos

e os alunos seus clientes. Agora pode-se efetuar o login do usuário “Professor” no modo

administrativo para ter acesso a tela de gerenciamento da Figura 3.11.

Figura 3.11 – Gerenciar Módulos do Professor 3

33

Observa-se na lista a coluna “Módulo” com as matérias indicando se estão ativas

ou não. O cliente (Usuário) passa a estar habilitado para comprar ou baixar estes módulos,

além de saber se estão ativos ou não, e o seu respectivo preço. Para ativar ou desativar

Módulos ou Usuários basta acionar os botões a baixo com a seleção de um ou mais itens

na primeira coluna que chama os respectivos serviços “ativarModulos” ou

“autorizarClientes”, tendo como resultado a figura 3.12. Observe que para gerar esta lista

é utilizado o serviço “LeModulos”.

Figura 3.12 – Gerenciar Módulos do Professor 1

34

Em seguida, efetua-se o login como o “Aluno 5” (Cliente) para poder

comprar ou baixar os arquivos dos módulos (ver Figura 3.13).

Figura 3.13 – Lista de Módulos do Aluno 5

Na Figura 3.13 apresenta-se a lista de módulos com a quantidade de arquivos de

cada um e o seu preço. Nesta figura já estão selecionadas as matérias 1 e 3 para efetuar

uma compra. Ao acionar comprar tem-se.

35

Figura 3.14 – Confirmação de uma Compra do Aluno 5

Ao confirmar a operação é chamado o serviço “comprarModulos”. Ao término

dessa operação, apresenta-se a tela da lista de módulos do “Aluno 5”, conforme a Figura

3.15.

36

Figura 3.15 – Lista de Módulos das Compras do Aluno 5

Nesta tela encontra-se a lista de módulos comprados com o nome, link do arquivo

para baixar, data de compra e o preço pago. Para gerar estas listas são usados os serviços

“leArquivos” e “leModulosCompradosData”.

37

Ao se adicionar arquivos ao módulo “Matéria 4” com uma alteração de preço e

cadastrar mais a “Matéria 6”, ambas pelo “Professor 3”, pode-se ver o histórico na

Figura 3.16 que é gerado pelo serviço “leModulosHistoricoData”.

Figura 3.16 – Histórico dos Módulos do Professor 3

Observe que todas estas listagens podem ser feitas filtrando por data na tela de

login.

Assim, entende-se que todo o web-service foi testado. Também foi testada esta

aplicação com mais professores, alunos, matérias e arquivos.

A aplicação PHP funciona perfeitamente para acessar os serviços do web-service

sem nenhuma dependência de linguagem ou biblioteca externa. A aplicação utiliza XML

para estruturar o conteúdo a ser comunicado e uma API SOAP para transporte do mesmo,

ambos baseados em PHP. Os serviços estão em outra linguagem, rodando em outra

plataforma, sem saber quem é o cliente que os usa e sem precisar de mais nenhuma

informação ao não ser a que está contida no próprio XML. Fica assim, caracterizado um

ambiente de duas camadas aonde a camada superior (PHP) se comunica com a inferior

(web-service) por uma interface através de serviços independentes.

38

Capítulo 4

Conclusões

4.1 – Conclusões

O web-service e a aplicação em PHP foram desenvolvidos com sucesso. Foi

observado que a aplicação em camada orientada a serviço funcionou corretamente.

Verificou-se que os serviços têm baixo acoplamento, isto é, não dependem de outros para

serem executados, ficaram encapsulados, isto é, não precisam de nenhuma informação a

mais do que o XML de entrada do mundo exterior e podem ser utilizados perfeitamente

por outro cliente sem a necessidade de alteração do código. Neste sentido, fica bem

caracterizada a arquitetura SOA.

Também foi observado que a ferramenta utilizada (Axis2) é bem indicada para o

desenvolvimento do web-service, facilitando muito a sua implementação. Axis2 deixa

um pouco a desejar na documentação que poderia ser melhor e além disso foi sentida uma

dificuldade na implementação da parte de segurança. Já o cliente PHP 7 também tem um

bom suporte para implementar soluções clientes para web-services, possui ótima

documentação, além do fato de ambas serem gratuitas, assim tendo uma boa relação

custo/benefício. Chama-se a atenção para o fato de que o web-services, no geral, precisa

melhorar o suporte à segurança como validação das credenciais e criptografias que ainda

não tem um padrão único.

4.2 – Trabalhos Futuros

Como trabalhos futuros sugerem-se alguns pontos, a saber: Os parâmetros de

entrada e saída do XML podem necessitar de uma discriminação melhor para efeitos de

uma aplicação final a ser usada por alguém bem como, no serviço de comprar módulos

poderia ter a opção da precificação por módulo, já que aqui foram consideradas somente

os essenciais que são necessários para o nível do projeto. Uma outra sugestão seria com

relação a arquivos muito longos dando um devido suporte a eles já que aqui a sua

utilização não foi necessária.

39

40

Bibliografia

[1] SILVA, Ricardo Frenedodo da; GONÇALVES, PABLO RODRIGO, Web Services

– Uma Análise Comparativa, Revista das Faculdades Integradas Claretianas, n. 5 –

janeiro/dezembro de 2012.

[2] VILLAS-BOAS , SERGIO BARBOSA. SOA_MC Service Oriented Architecture –

Multiple Client, Version, 2013_03_04.

[3] DEVMEDIA, “Introdução às tecnologias Web Services: SOA, SOAP, WSDL e

UDDI”, http://www.devmedia.com.br/introducao-as-tecnologias-web-services-soa-

soap-wsdl-e-uddi-parte1/2873,(Acesso em 20 Janeiro 2017).

[4] WIKIPÉDIA, “Web service”, https://pt.wikipedia.org/wiki/Web_service,

2017,(Acesso em 15 Janeiro 2017).

[5] DEVMEDIA, “Implantando práticas do Scrum e do XP em um projeto de software”,

http://www.devmedia.com.br/implantando-praticas-do-scrum-e-do-xp-em-um-

projeto-de-software/37280,(Acesso em 17 Janeiro 2017).

[6] WIKIPÉDIA, “Scrum”, https://pt.wikipedia.org/wiki/Scrum_desenvolvimento_de_

software, 2017,(Acesso em 15 Janeiro 2017).

[7] MINDMASTER, “Scrum: A Metodologia Ágil Explicada de forma Definitiva”,

http://www.mindmaster.com.br/scrum, 2015, (Acesso em 20 Janeiro 2017).

[8] WIKIPÉDIA, “Service-oriented architecture”, https://pt.wikipedia.org/wiki/Service-

oriented_architecture, 2017,(Acesso em 12 Janeiro 2017).

[9] W3C, “World Wide Web Consortium”, https://www.w3.org/, 2017, (Acesso em 11

Janeiro 2017).

https://pt.wikipedia.org/wiki/Web_service

http://www.mindmaster.com.br/scrum

41

[10] OASIS, “Organization for the Advancement of Structured Information Standards”,

https://www.oasis-open.org/, 2017, (Acesso em 10 Janeiro 2017).

[11] IETF, “Internet Engineering Task Force”, http://ietf.org/, (Acesso em 10 Janeiro

2017).

[12] WIKIPÉDIA, “Netscape Navigator”, https://en.wikipedia.org/wiki/Netscape_

Navigator,2017, (Acesso em 10 Janeiro 2017).

[13] FIELDING, ROY THOMAS. Architetural Styles and the Design of Netword-based

Software Architetures. Dissertação (Doutorado em Filosofia da Computação).

Universidade da Califórnia. Irvine, 2000.

42

Apêndice A

Scrum Academic

by Sergio Barbosa Villas-Boas

Version 2013_04_23

1 Introduction Scrum is well known method for project management, with special application if the

project to be managed is related to software development. This document presents a

variation of the scrum method that is adapted to fit for academic usage. This is the case

when some academic class requires students to develop software as part of the students

duties of the class. This method shall be called “scrum academic”.

What is being proposed with this document has no guarantee of any kind. Whoever uses

this method will do it by his/her own risk. It is assumed that all people using this method

has a mind sufficiently clever to adapt anything to fit better their case.

It is my belief that any method to manage software development (actually any method)

can only be considered as “good” if it delivers the desirable results in practical usage.

Another way of saying it is that “a trustable management method is one forged from the

heat of practical usage”.

I created the “scrum academic” method to help me deal with some very practical and

tangible professional tasks that I have. The method is very similar and based on regular

Scrum method. One of my professional activities is to be a professor at UFRJ - one of

the most prestigious universities in Brazil. Among other tasks, I have to be ahead some

classes strongly related to software development. Some examples include software for

smartPhones, cloud computing, C++, Java and scientific software development.

I am almost always super duper busy. So any method I use must fit for my condition of

having so little time.

For a course to be successful, the students must be skilled on the topics of the course by

the end of it. To accomplish this, typically the course contains 2 parts: presentation /

enunciation part, and participative part. In the first part, the important aspects of the

course are presented to the students. In the second part, the students are required to

43

produce something out of what was previously presented to them. Typically, the students

are required to develop some software.

I am (obviously) interested in researching and discovering what are the practical items of

a method for managing software development. If the reader has some idea of how to

adapt what I proposed, or just want to send me a message commenting of his/her

experience on managing software development, I will be happy to read and respond it.

2 From Requisites to Deliver of Final Product The start scrum academic is the definition of the work to be done. The definition must be

a written document that shall be called “project requisites”. See the model o project

requisites in section 5. The responsible professor of the class behaves like the “client” or

“paying customer” of the project. The professor class must approve the document, so that

the team gets the official authorization to proceed with the development effort. The

approval of the professor is done so that the project’s scope is adequately fit for the

purpose of the course. Not too simple so that the project turns into a ridiculously trivial

task, not enough challenging to the students. And not too complex so that the students

will have no resources to accomplish all the requisites of the project.

3 Meetings The regular scrum method defines of a number of meetings when a partially finished

project - called “sprint” - is shown to the client. The concept is also used in scrum

academic. The idea is to set a pre-defined (and small) number of meetings for each project

(that is, for each group of students in the class). Considering the lack of time that is so

characteristic of the usual situation, I shall recommend the number of meetings to be 3,

with the scope defined by the description below. As it was already mentioned, the reader

can adapt the number of meetings and its scope to meet whatever need there is.

3.1 Requisites and Hello Environment

This meeting is to check that there is a written document of requisites and that the

students are already producing a “hello world” like program with all dependencies

defined in the project. That is all dependent libraries, tools and other needed software for

the project should be installed and have a test shown to present to the client (the

professor).

44

3.2 Several Features Implemented

In this meeting the students must show several of the features of the requisites already

working. There is no well established rule to define how much percent of the requisites

is to be already implemented for this meeting. But most of what is fundamental for the

project is to be prioritized and ideally be shown as already developed at this meeting.

The customer may take the opportunity of the meeting to state some opinions on how the

software is going to be.

3.3 Final Delivery This meeting is to show all working.

4 How to set a grade Since this is an academic project, it is expected that some sort of grade is to be produced

out of the process. The scrum academic recommends to set grades for each meeting, and

define the final grade as the mean of the grades for each meeting. Let the students see the

grades of each meeting and follow the expected final grade. If grades are not too good at

the beginning, students are expected to work harder, so that better results are shown to

the next meeting and make the mean go up.

5 Model of Project Requisites This document must contain the following sections:

1) Title (a small and concise description of the project to be done)

2) Date

3) Members (the names and contacts - email, phone number - of the team related the

project).

4) Name and code of class, and responsible professor.

5) Technology (the list of the technologies involved, mentioning the computer

language, interface type - web, GUI, line command, smartPhone, other - external

libraries, software architecture and other relevant information).

6) Requisites (this is a very important section where all the main features of the

software should be described, item by item).

45

Apêndice B

Script MySql

-- MySQL Script generated by MySQL Workbench

-- 01/31/17 19:51:04

-- Model: MediaControl Version: 1.0

-- MySQL Workbench Forward Engineering

SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0;

SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS,

FOREIGN_KEY_CHECKS=0;

SET @OLD_SQL_MODE=@@SQL_MODE,

SQL_MODE='TRADITIONAL,ALLOW_INVALID_DATES';

-- -----------------------------------------------------

-- Schema db_ws_contador

-- -----------------------------------------------------

-- -----------------------------------------------------

-- Schema db_ws_contador

-- -----------------------------------------------------

CREATE SCHEMA IF NOT EXISTS `db_ws_contador` DEFAULT CHARACTER SET

utf8 ;

USE `db_ws_contador` ;

-- -----------------------------------------------------

-- Table `db_ws_contador`.`tb_person`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `db_ws_contador`.`tb_person` (

ìd` INT NOT NULL AUTO_INCREMENT,

`pwd` VARCHAR(10) NOT NULL,

`login` VARCHAR(10) NOT NULL,

ènable` TINYINT(1) NOT NULL,

`creation` DATETIME NOT NULL DEFAULT now(),

PRIMARY KEY (ìd`))

ENGINE = InnoDB;

-- -----------------------------------------------------

-- Table `db_ws_contador`.`tb_module`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `db_ws_contador`.`tb_module` (


`name` VARCHAR(150) NOT NULL,

`price` DOUBLE NOT NULL,



PRIMARY KEY (ìd`))

ENGINE = InnoDB

COMMENT = 'big data part 1\nbig data part 2\nhtml\n';

46

-- -----------------------------------------------------

-- Table `db_ws_contador`.`tb_file`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `db_ws_contador`.`tb_file` (


`tb_module_id` INT NOT NULL,

`name` VARCHAR(150) NOT NULL,

PRIMARY KEY (ìd`, `tb_module_id`),

INDEX `fk_tb_file_tb_module_idx` (`tb_module_id` ASC),

CONSTRAINT `fk_tb_file_tb_module`

FOREIGN KEY (`tb_module_id`)

REFERENCES `db_ws_contador`.`tb_module` (ìd`)

ON DELETE NO ACTION

ON UPDATE NO ACTION)

ENGINE = InnoDB

COMMENT = 'file1.pdf\nfile2.pdf\n';

-- -----------------------------------------------------

-- Table `db_ws_contador`.`tb_purchased_module`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `db_ws_contador`.`tb_purchased_module` (


`tb_person_id` INT NOT NULL,

`purchase_date` DATETIME NOT NULL DEFAULT now(),

`paid` DOUBLE NOT NULL,

PRIMARY KEY (`tb_module_id`, `tb_person_id`),

INDEX `fk_tb_purchased_module_tb_person1_idx` (`tb_person_id`

ASC),

CONSTRAINT `fk_tb_person_module_tb_module1`



ON DELETE NO ACTION

ON UPDATE NO ACTION,

CONSTRAINT `fk_tb_purchased_module_tb_person1`

FOREIGN KEY (`tb_person_id`)

REFERENCES `db_ws_contador`.`tb_person` (ìd`)

ON DELETE NO ACTION


ENGINE = InnoDB;

-- -----------------------------------------------------

-- Table `db_ws_contador`.`tb_rating_module`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `db_ws_contador`.`tb_rating_module` (




`price` DOUBLE NOT NULL,


PRIMARY KEY (ìd`, `tb_module_id`, `tb_person_id`),

INDEX `fk_tb_rating_module_tb_module1_idx` (`tb_module_id` ASC),

INDEX `fk_tb_rating_module_tb_person1_idx` (`tb_person_id` ASC),

CONSTRAINT `fk_tb_rating_module_tb_module1`



ON DELETE NO ACTION

47


CONSTRAINT `fk_tb_rating_module_tb_person1`



ON DELETE NO ACTION


ENGINE = InnoDB;

-- -----------------------------------------------------

-- Table `db_ws_contador`.`tb_module_person`

-- -----------------------------------------------------

CREATE TABLE IF NOT EXISTS `db_ws_contador`.`tb_module_person` (



òwner` TINYINT(1) NOT NULL,


PRIMARY KEY (`tb_module_id`, `tb_person_id`),

INDEX `fk_tb_person_person_tb_person2_idx` (`tb_person_id` ASC),

INDEX `fk_tb_person_person_tb_module1_idx` (`tb_module_id` ASC),

CONSTRAINT `fk_tb_person_person_tb_person2`



ON DELETE NO ACTION


CONSTRAINT `fk_tb_person_person_tb_module1`



ON DELETE NO ACTION


ENGINE = InnoDB;

SET SQL_MODE=@OLD_SQL_MODE;

SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;

SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;

48

Apêndice C

WSDL

49

50

52

53

54

55

Documents

GERENCIAMENTO DE TEXTURAS PARA APLICAÇÕES DE …monografias.poli.ufrj.br/monografias/monopoli10020507.pdf · SISTEMA GERENCIADOR DE DOWNLOAD DE ... autor da monografia Sistema Gerenciador