GERENCIAMENTO DE TEXTURAS PARA APLICAÇÕES DE...
Transcript of GERENCIAMENTO DE TEXTURAS PARA APLICAÇÕES DE...
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
Carlos Alberto Fernandes Neves Filho
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:
Carlos Alberto Fernandes Neves Filho
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.
Carlos Alberto Fernandes Neves Filho
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
id Chave primária Inteiro
name Nome do módulo String
price Preço Double
enable Ativo Boolean
creation Data da criação Data
tb_file
id Chave primária Inteiro
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
enable Ativo Boolean
tb_purchased_module
tb_module_id Chave primária e
estrangeira Inteiro
tb_person_id Chave primária e
estrangeira Inteiro
purchase_date Data de compra Data
paid Valor pago Double
tb_rating_module
id Chave primária Inteiro
tb_module_id Chave primária e
estrangeira Inteiro
tb_person_id Chave primária e
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
(<dataini></dataini><datafim></datafim><nome></nome>) selecionados para
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
Pós-condição: O Dono ou Cliente recebe o xml resposta
(<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
(<dataini></dataini><datafim></datafim><nome></nome>) selecionados para
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
Pós-condição: O Dono ou Cliente recebe o xml resposta
(<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).
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` (
`id` INT NOT NULL AUTO_INCREMENT,
`pwd` VARCHAR(10) NOT NULL,
`login` VARCHAR(10) NOT NULL,
`enable` TINYINT(1) NOT NULL,
`creation` DATETIME NOT NULL DEFAULT now(),
PRIMARY KEY (`id`))
ENGINE = InnoDB;
-- -----------------------------------------------------
-- Table `db_ws_contador`.`tb_module`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `db_ws_contador`.`tb_module` (
`id` INT NOT NULL AUTO_INCREMENT,
`name` VARCHAR(150) NOT NULL,
`price` DOUBLE NOT NULL,
`enable` TINYINT(1) NOT NULL,
`creation` DATETIME NOT NULL DEFAULT now(),
PRIMARY KEY (`id`))
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` (
`id` INT NOT NULL AUTO_INCREMENT,
`tb_module_id` INT NOT NULL,
`name` VARCHAR(150) NOT NULL,
PRIMARY KEY (`id`, `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` (`id`)
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_module_id` INT NOT NULL,
`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`
FOREIGN KEY (`tb_module_id`)
REFERENCES `db_ws_contador`.`tb_module` (`id`)
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` (`id`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
-- -----------------------------------------------------
-- Table `db_ws_contador`.`tb_rating_module`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `db_ws_contador`.`tb_rating_module` (
`id` INT NOT NULL AUTO_INCREMENT,
`tb_module_id` INT NOT NULL,
`tb_person_id` INT NOT NULL,
`price` DOUBLE NOT NULL,
`creation` DATETIME NOT NULL DEFAULT now(),
PRIMARY KEY (`id`, `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`
FOREIGN KEY (`tb_module_id`)
REFERENCES `db_ws_contador`.`tb_module` (`id`)
ON DELETE NO ACTION
47
ON UPDATE NO ACTION,
CONSTRAINT `fk_tb_rating_module_tb_person1`
FOREIGN KEY (`tb_person_id`)
REFERENCES `db_ws_contador`.`tb_person` (`id`)
ON DELETE NO ACTION
ON UPDATE NO ACTION)
ENGINE = InnoDB;
-- -----------------------------------------------------
-- Table `db_ws_contador`.`tb_module_person`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `db_ws_contador`.`tb_module_person` (
`tb_module_id` INT NOT NULL,
`tb_person_id` INT NOT NULL,
`owner` TINYINT(1) NOT NULL,
`enable` 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`
FOREIGN KEY (`tb_person_id`)
REFERENCES `db_ws_contador`.`tb_person` (`id`)
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_tb_person_person_tb_module1`
FOREIGN KEY (`tb_module_id`)
REFERENCES `db_ws_contador`.`tb_module` (`id`)
ON DELETE NO ACTION
ON UPDATE 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