Tp:;
RELATÓRIO DE ESTÁGIO
Curso Técnico Superior Profissional
em Desenvolvimento de Aplicações Informáticas
André Marcelino Baptista
Instituto Politécnico da Guarda
R E L A T Ó R I O D E E S T Á G I O
ANDRÉ MARCELINO BAPTISTA
RELATÓRIO PARA A OBTENÇÃO DO GRAU DE TÉCNICO SUPERIOR PROFISSIONAL
EM DESENVOLVIMENTO DE APLICAÇÕES INFORMÁTICAS Julho/2017
i
Ficha de Identificação
Estagiário: André Marcelino Baptista Nº de aluno: 1012022
Curso: TeSP de Desenvolvimento de Aplicações Informáticas
Instituição: Altran
Morada: Av. D. João II, Lote 1.07.2.1 Piso 2, 1990-096 Lisboa Localidade: Lisboa
Telefone: 210 331 600 Fax: 210 331 639
Data de início do estágio: 06/03/2017 Data de fim do estágio: 19/07/2017 Duração do estágio: 750 horas
Supervisor na Instituição: Fábio Costa Grau Académico do Supervisor: Mestre
Docente Orientador: Joaquim Mateus Grau Académico do Orientador: Doutor
ii
Agradecimentos
Com a finalização deste Relatório de Estágio Curricular não posso deixar de agradecer aos que, direta ou indiretamente, me ajudaram ao longo deste estágio.
Deste modo, agradeço:
À Altran Portugal por me possibilitar a oportunidade de estagiar numa equipa fantástica e de expandir o meu conhecimento com novas competências técnicas, pessoais e organizacionais.
À Dra. Ângela Marta por toda a atenção, compreensão e ajuda dada ao longo deste estágio.
Ao Engenheiro Fábio Costa por toda a disponibilidade e ajuda bem como por toda a formação e conhecimento transmitido.
A toda equipa do MediaLab pelo bom acolhimento, pela simpatia e pelo espírito de entreajuda. Ao Prof. Doutor Joaquim Mateus por toda a disponibilidade, preparação e ajuda na elaboração do relatório de estágio.
E por fim um agradecimento especial à minha família pela possibilidade que me proporcionou para integrar este estágio e por todo o apoio dado no decorrer do mesmo.
iii
Plano de Estágio:
O plano de estágio proposto pela Altran, tal como consta no Anexo 1 deste relatório, consiste na criação de uma plataforma web de gestão de dados relativos aos equipamentos do laboratório - MediaLab.
Assim foram delineados determinados requisitos para a construção da plataforma, divididos em três níveis de prioridade, sendo nível A requisitos indispensáveis à plataforma, nível B requisitos que são importantes, mas dispensáveis, e nível C os requisitos classificados como “nice to have”, que são requisitos que não são importantes.
(A) - A gestão do catálogo deverá ser feita através de uma plataforma web;
(A) - A solução deverá ser construída com tecnologias recentes e bastante utilizadas;
(A) - A plataforma web deverá ser capaz de adicionar, editar e consultar os equipamentos do catálogo;
(A) - A plataforma web deverá ter uma interface user-friendly e intuitiva;
(A) - Os identificadores dos equipamentos (na adição de novos elementos) deverão seguir as regras assentes do laboratório, e já utilizada no ficheiro Excel;
(B) - A plataforma web deverá também ser capaz de fazer requisições de material, bem como a visualização e devolução das mesmas;
(C) - A plataforma deverá também mostrar alertas para requisições com prazo de devolução expirado.
Tendo em conta os requisitos necessários para criação da plataforma, foi proposto a utilização das seguintes tecnologias:
Python/Django como tecnologia web a utilizar, com o apoio de MySQL para o armazenamento de dados;
Utilização de templates e/ou framework Bootstrap para a criação de interfaces user-frienly; Git para repositório de código e controlo de versões.
iv
Resumo do Trabalho Desenvolvido no Estágio:
O estágio decorreu no laboratório MediaLab da Altran Lisboa com início a 6 de março até 19 de julho de 2017.
O objetivo do estágio consistiu na criação de uma plataforma web onde se possa proceder ao registo e ordenação dos equipamentos existentes no laboratório MediaLab bem como aos pedidos de requisição do material. Pretende-se criar uma plataforma de fácil acesso e consulta a qualquer pessoa.
Dada a natureza do projeto que é um projeto de desenvolvimento, foi sugerido pela Altran optar por uma metodologia Agile. Assim a criação da plataforma teve várias fases que apresento de forma resumida:
- Enquadramento e contextualização com as tecnologias, ou seja um primeiro contacto com as tecnologias a usar, nomeadamente com Python e Django com o objetivo de aprender os conceitos chave e funcionamento das tecnologias;
- Construção da base da plataforma web, que consistiu no desenvolvimento das funcionalidades tais como visualização, adição e edição dos elementos da plataforma;
- Otimização da base da plataforma web, com o objetivo de assegurar o correto funcionamento das funcionalidades;
- Otimização da interface, que consiste na criação gráfica do website;
- Desenvolvimento das restantes funcionalidades, nomeadamente, relativas às requisições de material.
Palavras-Chave: Indústria, Informática, Serviços, Aplicações Web e Programação.
Jel Classification: L8 – Industry Studies: Services; L86 – Information and Internet Services –
v
Índice
Ficha de Identificação ... i
Agradecimentos ... ii
Plano de Estágio: ... iii
Resumo do Trabalho Desenvolvido no Estágio: ... iv
Índice ... v
Lista de Figuras ... vii
Glossário ... ix
Introdução ... 1
Capítulo I - Caracterização da Instituição de Estágio ... 3
1. Instituição ... 4 1.1. A Altran Group ... 4 1.2. A Altran em Portugal ... 4 1.3. A Altran Lisboa ... 5 1.4. MediaLab ... 6 Capítulo II - O Estágio ... 8
1. Objetivos do trabalho desenvolvido ... 9
2. Enquadramento e Contextualização com as Tecnologias ... 10
3. Formação e pré-requisitos ... 15
3.1. Formação em Python ... 15
3.2. Exercícios relacionados com Python ... 16
3.3. Formação e Exercícios de Django ... 16
4. Construção da base da plataforma web ... 17
4.1. Contextualização ... 17
4.2. Criação do Projeto ... 18
4.3. Desenvolvimento do Projeto ... 20
5. Outras tarefas realizadas ... 39
Conclusão ... 41
vi
Anexos ... 43
Anexo1 - Plano de Estágio ... 44
Anexo 2 - Representação da base de dados ... 54
Anexo 3 - Funcionamento da SideBar ... 56
Anexo 4 - Adicionar Equipamentos à base de dados ... 59
Anexo 5 - Ver detalhes dos equipamentos ... 65
Anexo 6 - Editar equipamentos ... 67
Anexo 7 - Adicionar e ver detalhes de requisições ... 71
Anexo 8 - Cancelar Requisição ... 75
Anexo 9 - Entregar equipamento requisitado ... 77
vii
Lista de Figuras
Figura 1 - Sede da Altran (Lisboa) ... 6
Figura 2 - Estrutura da equipa do MediaLab ... 6
Figura 3 - Python Logo ... 10
Figura 4 - Django Logo ... 11
Figura 5 - HTML Logo ... 11
Figura 6 - CSS Logo ... 12
Figura 7 - JavaScript Logo ... 12
Figura 8 - jQuery Logo ... 12
Figura 9 - MySQL Logo ... 13
Figura 10 - VirtualBox Logo ... 13
Figura 11 - Debian Logo ... 13
Figura 12 - Sublime Text Logo ... 14
Figura 13 - PyCharm Logo ... 14
Figura 14 - Codecademy Logo ... 15
Figura 15 – Codecacademy ... 16
Figura 16 - Tutorial Django ... 17
Figura 17 - Estrutura da pasta da plataforma web criada automaticamente... 18
Figura 18 - Estrutura da pasta da plataforma web depois de alterada ... 19
Figura 19 - App inserida em INSTALLED_APPS ... 19
Figura 20 - Parte do código do model CPE ... 20
Figura 21 - Exemplo de Migrations ... 21
Figura 22 - Parte do código do model form Hardware ... 23
Figura 23 - Urls presentes no ficheiro "urls" criado automaticamente ... 24
Figura 24 - Alguns dos urls presentes no ficheiro "urls" criado posteriormente ... 25
viii
Figura 26 - Código da função main ... 27
Figura 27 – Parte do código do template da lista de equipamentos ... 28
Figura 28 - Script “hw_change()” ... 28
Figura 29 – form ... 29
Figura 30 - Parte do código do template de adicionar equipamentos ... 30
Figura 31 - Alert box ... 31
Figura 32 - Código da função “add_item” que faz o get ... 32
Figura 33 - Código da função add_item que faz o post dos dados ... 32
Figura 34 – Código da função “add_item” que valida os dados inseridos ... 32
Figura 35 - Código da função “add_item” que cria e guarda os dados na base de dados ... 33
Figura 36 - Função “details” ... 34
Figura 37 - Código da função "edit_item" que trata do get ... 35
Figura 38 - Função “cancel_requisition” ... 36
Figura 39 - Código da função "deliver_form" que adiciona novos dados e altera o estado da requisição ... 37
Figura 40 - Código da função "deliver_form" que altera o estado dos equipamentos... 37
Figura 41 - Box 2.0 HD+ ... 39
ix
Glossário
ADMS – Altran Delivery Managemnet System CPE - Customer Premises Equipment
CSS - Cascading Style Sheets DRY – Don’t Repeat Yourself EC –Expertise Center
HTML - Hypertext Markup Language IDE - Integrated Development Environment SQL – Structured Query Language
URL - Uniform Resource Locator VM – Virtual Box
1
Introdução
O presente trabalho pretende descrever o estágio efetuado como parte integrante e conclusivo do Curso Técnico Superior Profissional (TeSP) em Desenvolvimento de Aplicações Informáticas, ministrado na Escola Superior de Tecnologia e Gestão do Instituto Politécnico da Guarda.
O Estágio Curricular é uma das principais etapas de preparação para o exercício de uma profissão, no qual colocamos em prática os conhecimentos e os conteúdos aprendidos durante a formação académica e que nos permite adquirir e desenvolver competências técnicas, relacionais e organizacionais relevantes para a inserção na vida ativa.
Assim, no presente relatório pretendo descrever as atividades desenvolvidas e os desafios que foram colocados, no decorrer do estágio realizado na Altran Lisboa, durante o período compreendido entre 6 de março e 19 de julho de 2017.
O objetivo principal do estágio centrou-se na criação de uma plataforma web que gerisse todos os dados relativos aos equipamentos da equipa em que estava inserido bem como requisições desses mesmos equipamentos.
Assim, este relatório encontra-se estruturado em 2 capítulos,” Caracterização da Instituição de Estágio” e “O Estágio”.
O primeiro capítulo é constituído somente por um subcapítulo chamado “Instituição” que está dividido em quatro pontos diferentes: “A Altran-Group”, “A Altran em Portugal”, “A Altran Lisboa” e “MediaLab”.
Neste capítulo é feita uma descrição da empresa, quer a nível internacional quer a nível nacional, sobre as áreas em que esta está envolvida bem como a sua estrutura. Por fim é descrita a equipa do MediaLab que foi onde estive inserido ao longo do estágio.
O segundo capítulo é constituído por quatro subcapítulos, “Objetivos do Trabalho Desenvolvido”, “Formação e Pré-requisitos”, “Construção da base da plataforma web” e “Outras Atividades Realizadas”.
No primeiro subcapítulo é descrito qual o propósito do estágio, a descrição do projeto, a explicação do problema que levou à necessidade da realização do projeto e quais as tecnologias usadas no desenvolvimento do projeto.
2
O subcapítulo “Formação e Pré-requisitos” está dividido em três pontos: “Formação em Python”, “Exercícios relacionados com Python” e “Formação e Exercícios de Django”. Neste subcapítulo é feita uma descrição relativa à formação que tive no início do estágio de forma a ficar familiarizado com as tecnologias que foram usadas na criação da plataforma web.
O seguinte subcapítulo, “Construção da base da plataforma web”, é constituído por quatro pontos diferentes: “Contextualização”, “Criação do projeto” e “Desenvolvimento do projeto”. Inicialmente é feita uma descrição sobre a plataforma web e o tipo de conteúdo que vai gerir. Após essa descrição inicial é descrito todo o processo sobre o desenvolvimento da plataforma web bem como certos conceitos importantes.
Já no último subcapítulo estão descritas outras tarefas que não faziam parte do plano de estágio, mas que foram realizadas durante o estágio por solicitação da equipa.
É apresentada uma conclusão sobre o trabalho desenvolvido evidenciando os aspetos relevantes do estágio.
3
Capítulo I
4
1. Instituição
11.1. A Altran Group
A Altran é uma empresa multinacional francesa, fundada em 1982, que atua no mercado da tecnologia e inovação, operando em mais de vinte países espalhados pela Europa, Ásia, América do Norte e América do Sul, com uma equipa de cerca de 26.000 colaboradores. Uma empresa de consultoria e engenharia de alta tecnologia que trabalha em diversas áreas chave /sectores:
- Aeronáutica Espacial e Defesa;
- Automóvel, Infraestruturas e Transportes; - Energia e Indústria;
- Serviços Financeiros; - Administração Pública;
- Saúde e Indústria Farmacêutica; - Transporte Ferroviário;
- Telecomunicações.
A Altran pretende continuar a crescer, prova disso é o seu Plano Estratégico para 2016-2020 designado Altran 2020 INIGTION, assente em cinco premissas fundamentais:
- Innovative Product Development - Valor acrescentado
- Globalshore Industrializado
- Expansão global para os mercados do E.U.A, Alemanha, China e India;
- Excelência operacional, que se traduz em disciplina de vanguarda e otimização de custos.
1.2. A Altran em Portugal
A Altran está presente no mercado Português desde 1998 e conta com mais de 1.000 colaboradores em território luso. Com sede em Lisboa a Altran expandiu a sua atividade no mercado português, abrindo uma filial no Porto em 2004 e em 2013 o Centro de Nearshore na cidade do Fundão.
A empresa está presente em vários sectores de atividades, assente na venda de soluções inovadoras em três grandes linhas de negócio:
- Consultoria tecnológica e de inovação;
5
- Consultoria organizacional;
- Consultoria em sistemas de informação.
A grande missão da AltranPortugal é apoiar as empresas na criação e desenvolvimento de novos produtos, procurando também a criação de soluções inovadoras a nível mundial.
Existem cinco valores nesta organização: excelência, inovação, responsabilidade, dinamismo e consideração.
1.3.
A Altran Lisboa
Na Altran existem três Diretores: - Diretor Geral;
- Diretor de Recursos Humanos e Financeiros; - Diretor de Marketing e Técnico.
Em Lisboa, a área de backoffice é constituída por nove departamentos: - Recursos Humanos
-Contabilidade - Payroll - Marketing
- Direção de Sistemas de Informação - Departamento Administrativo - Departamento Financeiro - Departamento de Vendas - Tesouraria
Na sede da Altran (figura 1) estão aproximadamente 130 colaboradores os quais estão distribuídos em diferentes áreas e equipas
Há também equipas nearshore, equipas essas que desenvolvem os projetos nas instalações da Altran, em vez de estarem nas instalações do cliente.
6
1.4.
MediaLab
MediaLab é um laboratório/equipa constituída por cerca de 15 elementos e em crescimento que é especializada na área de telecomunicações e foi o local onde eu realizei o meu estágio curricular. A equipa é multifacetada trabalhando aproximadamente em 13 projetos de 4/5 clientes diferentes e está estruturada conforme se apresenta na figura 2:
Figura 2 - Estrutura da equipa do MediaLab Fonte: Elaborada pelo aluno Figura 1 - Sede da Altran (Lisboa)
7
A equipa do MediaLab bem como os respetivos projetos em que a equipa trabalha são dirigidos pelo Project Director.
A angariação dos projetos/clientes é efetuada pelo Solution Manager, a quem é exigido um vasto conhecimento, neste caso na área das telecomunicações.
Uma vez que a equipa está inserida em diversos projetos, é necessário um responsável pela coordenação e distribuição de funções, o que cabe a um Project Manager.
Dada a complexidade dos projetos, assim como dos sistemas já existentes nos clientes, a equipa auxilia-se no system arquitecth, que analisa o projeto do ponto de vista técnico, as suas caraterísticas, a nível de software, e estrutura uma arquitetura, para que as novas ambições dos clientes consigam ser integradas nos seus sistemas atuais.
No laboratório é necessário existir um configuration manager que é responsável pela configuração de todos os projetos nas ferramentas utilizadas pela empresa e por garantir que os projetos cumprem os pressupostos Altran Delivery Managemnet System (ADMS) por forma a serem auditados com sucesso.
Por fim existem os testers e developers, que estão distribuídos pelos diversos projetos onde a equipa está integrada.
Os testers são responsáveis por testar os equipamentos (hardware e software) garantindo que os mesmos cumprem os requisitos dos clientes. Caso não cumpram, são abertos defects/bugs2, para que o cliente tenha conhecimento que num determinado test case3 o software não se comporta como é esperado. No final dos testes, os resultados são enviados aos clientes para que possam proceder às correções e reenviarem para novos testes.
Os developers têm como função desenvolver o software de acordo com os requisitos do projeto.
2
Erros que são verificados durante funcionamento de um software ou hardware que pode causar comportamentos inesperados, como resultados incorretos ou comportamentos indesejados.
8
Capítulo II
9
1.
Objetivos do trabalho desenvolvido
Tal como já foi referido o meu estágio decorreu no laboratório MediaLab da Altran. Este laboratório especializado em telecomunicações implementa projetos de desenvolvimento e testes de software na área mobile e dada a variedade de dispositivos móveis no MediaLab, é necessário proceder ao registo e ordenação dos equipamentos.
Por outro lado este laboratório possui uma rede própria que possibilita replicar a rede dos operadores, permitindo ligar os dispositivos que na maior parte dos casos estão na casa do cliente, tais como: computadores, smartphones, tablets, PlayStations e set-top-boxes, entre outros.
O objectivo final é testar os equipamentos submetendo-os a condições equiparáveis às encontradas nas casas dos clientes finais, por forma a antecipar e corrigir os problemas por estes encontrados. Estando a tecnologia nesta área em constante atualização, continuamente existem novos CPE’s para testar, bem como novos dispositivos (smartphones, consolas, etc).
Assim, existe uma enorme necessidade de gerir os equipamentos recebidos no laboratório provenientes de diversos clientes, bem como, os dispositivos utilizados para efetuar os testes e suporte e as requisições de material.
Atualmente, a gestão dos equipamentos do laboratório é feita através de um ficheiro Excel e as requisições de material são efetuadas através de formulários de papel.
Com o crescimento da empresa o número de dispositivos aumentou e o método de gestão utilizado passou a ser ineficiente, sendo necessário construir algo que facilite a gestão dos equipamentos.
10
2.
Enquadramento e Contextualização com as Tecnologias
Para criar uma plataforma web derivada de uma base de dados é preciso usar uma framework de construção de websites bem como uma base de dados.
Há diversas frameworks web disponíveis das quais se destacam o Apache, Django e Rails onde cada uma destas frameworks é escrita em diferentes linguagens.
Apache é a framework mais utilizada no mundo e escrita em PHP, django é escrita em Python e Rails em Ruby. E foi esta diferença de linguagens entre as frameworks que definiu a framework a ser usada no desenvolvimento da plataforma web.
Uma vez que a equipa do MediaLab está atualmente focada em desenvolver projetos em Python, a
framework escolhida foi o Django.
Já no que toca à escolha da base de dados, a escolha recaiu no MySQL uma vez que normalmente é a base de dados que a equipa usa nos projetos.
Por fim referir que a interface gráfica do website é baseada no template “sbAdmin”, ou seja tudo o que implique código HTML, CSS, JavaScript e jQuery tem por base este template já existente.
Web Platform:
Python
Trata-se de uma linguagem de alto nível com sintaxe intuitiva e simples de aprender. Esta é uma linguagem interpretada4,
de script5, orientada a objetos e usada não só no desenvolvimento web como em muitos outros tipos de aplicações. Python de acordo com Turing completude é considerada uma
linguagem de programação na medida em que através de funções, variáveis, entre outros e com um servidor previamente instalado e com tudo o que é necessário para funcionar corretamente tem a capacidade de criar dados e métodos, entre outro tipo de ações (figura3).
4 Linguagem interpretada é uma linguagem de programação em que o código fonte nessa linguagem é executado por um programa de
computador chamado interpretador, que em seguida é executado pelo sistema operativo ou processador.
5 Linguagem de script é qualquer linguagem usada para escrever um script. Um script por sua vez é um programa onde é escrito uma
sequência de comandos e tarefas que vão ser executadas pelo interpretador.
Figura 3 - Python Logo Fonte: httsp:www.python.org
11
Alan Turing criou o conceito de “Turing completude” que é um sistema de regras de manipulação de dados. Na prática, Turing criou uma máquina teórica mínima que permite fazer estas operações e para que uma linguagem seja considerada linguagem de programação, a mesma tem de ser capaz de realizar todas as operações da máquina de Turing.
Django
Django é uma framework gratuita open-source6 escrita em Python utilizada na criação de
aplicações web. Framework web é um conjunto de componentes que facilita a construção de
websites (figura 4). O Django utiliza o princípio Don’t Repeat Yourself (DRY), onde faz com que o programador aproveite ao máximo o código já desenvolvido, evitando a sua repetição.
Figura 4 - Django Logo Fonte: https:www.djangoproject.com
HTML
HTML é uma linguagem que é utilizada no desenvolvimento de páginas web. Esta linguagem é interpretada por navegadores web (Mozilla Firefox e Google Chrome) de forma a apresentar dados (figura 5). Porém as linguagens de marcação não têm a capacidade de criar dados, apenas de apresentar dados previamente escritos e criados por linguagens de programação.
6 Aplicação cujo código está "aberto". Ou seja, o utilizador pode contribuir para a própria evolução da ferramenta alterando o próprio
código.
Figura 5 - HTML Logo
12
CSS
Cascading Style Sheets (CSS) descreve o modo como os elementos HTML vão ser demonstrados. Através deste mecanismo é possível controlar fontes, cores, margens, linhas, imagens de fundo e posicionamentos, entre outros elementos HTML (figura 6).
JavaScript
JavaScript é uma linguagem de programação client-side7, utilizada para criar pequenos programas encarregues de realizar ações e comportamentos, bem como manipular CSS dentro de uma página web. Através desta linguagem é possível criar interações dinâmicas, como por exemplo definir ações quando se clica num botão, efeitos de cores, mostrar e esconder menus, entre muitas outras funcionalidades (figura 7).
jQuery
jQuery é uma biblioteca ou coleção de funções e métodos JavaScript que interage com o HTML. Criada com o objetivo de facilitar a utilização da linguagem JavaScript, na medida em que é possível criar diversas ações em poucas linhas de código, contrariamente se fosse utilizado a linguagem JavaScript. jQuery tem por lema “Write less, do more”, traduzido “Escreve menos, faz mais” (figura 8).
7É uma linguagem que é executada do lado cliente, ou seja, no computador do próprio utilizador, sendo assim utilizada em tarefas que linguagens
server-side, como o Python, não conseguem executar.
Figura 6 - CSS Logo
Fonte: https://logodownload.org/css3-logo/
Figura 7 - JavaScript Logo
Fonte:https://pt.wikipedia.org/wiki/JavaScript
Figura 8 - jQuery Logo Fonte: https://jquery.com/
13
MySQL
MySQL é um servidor robusto de banco de dados relacional. Utiliza a linguagem SQL, que é a linguagem mais popular para gerir dados armazenados numa base de dados (figura 9).
Figura 9 - MySQL Logo Fonte: https://www.mysql.com/
Programas de desenvolvimento:
Vitual Box
VirtualBox (VM) é um software de virtualização que tem como principal vantagem a instalação de diferentes sistemas operativos dentro do sistema de operativo atual (figura 10). Durante o estágio, a VM foi utilizada de forma a tornar possível a realização do projeto em ambiente Linux.
Figura 10 - VirtualBox Logo Fonte: https://www.virtualbox.org/
Debian
Debian é um sistema operativo open-source pertencente à Linux (figura 11). Todo o projeto foi realizado neste sistema operativo uma vez que por default a equipa do MediaLab utiliza este sistema operativo no que toca ao desenvolvimento de aplicações.
Figura 11 - Debian Logo
14
Sublime Text
O Sublime Text é um editor de texto e código-fonte multiplataforma (figura 12). A principal vantagem deste editor de texto são as suas múltiplas funcionalidades que facilitam e diminuem o tempo de desenvolvimento de código. Algumas das funcionalidades proporcionadas são seleção múltipla, sugestão de comandos entre muitas outras.
PyCharm
PyCharm é um Integrated Development Environment (IDE) usado na programação em Python. Este IDE desenvolvido pela empresa Checa JetBrains fornece análise de código, graphical
debugger, entre muitas outras funcionalidades que permite ao programador uma maior facilidade
e rapidez no desenvolvimento do programa (figura 13).
Figura 12 - Sublime Text Logo
Fonte: https://en.wikipedia.org/wiki/File:Sublime_Text_Logo.png
Figura 13 - PyCharm Logo
15
3. Formação e pré-requisitos
Uma vez que nunca tinha tido qualquer tipo de contacto com as ferramentas de construção da plataforma web foi-me possibilitada formação e um contacto com as tecnologias a utilizar, com o objetivo de aprender os conceitos chave e funcionamento das tecnologias.
Assim sendo, inicialmente tive uma formação de Python, seguida de exercícios propostos pelo supervisor da instituição. Concluída a formação em Python seguiu-se uma formação e resolução de exercícios sobre Django, também uma proposta do supervisor da instituição.
3.1.
Formação em Python
A formação em Python consistia na realização de um curso online de Python no site “Codecacademy” (figura 14) que teve a duração de uma semana e que teve como objetivo a aprendizagem de conceitos básicos de linguagem Python e a aplicação desses conceitos em pequenos exercícios.
Figura 14 - Codecademy Logo Fonte: https://www.codecademy.com/learn
O curso foi constituído por 13 capítulos, que estavam subdivididos e onde eram introduzidos e explicados diversos conceitos de Python. Inicialmente era feita uma abordagem teórica e após terminada essa abordagem era necessário aplicar os conceitos aprendidos em pequenos exercícios e no final de cada capítulo havia sempre um exercício final que continha todos os conceitos aprendidos.
Assim sendo, numa parte inicial, foi feito uma introdução à linguagem e revisão geral da syntax básica de Python.
16
De seguida ao longo do curso foram explicados conceitos importantes dos quais se destacam listas, dicionários, ciclos, funções e classes, que mais tarde seriam usados na criação da base de dados (figura 15).
Figura 15 – Codecacademy
Fonte: https://www.codecademy.com/pt/learn
3.2. Exercícios relacionados com Python
Concluído o curso online em Python, era necessário cimentar alguns conceitos importantes para a construção da plataforma web dos quais se destacam a criação de classes e funções e a interação entre elas. Para isso foram delineados alguns exercícios relacionados com classes e funções e que mais tarde seriam utilizados na realização da base de dados.
Para a realização destes exercícios foi necessário usar o pycharm. Contudo este IDE não foi usado no desenvolvimento do projeto.
Realizei exercícios que criaram as seguintes funções: adicionar novos dados a uma base de dados, a editar dados existentes na base de dados, eliminar dados e visualizar detalhes dos mesmos, entre outras. A maior parte das funções realizadas seriam posteriormente usadas para servir de base na criação de funções semelhantes às do projeto final.
3.3. Formação e Exercícios de Django
Uma vez familiarizado com Python, iniciei uma pequena formação de Django que consistia em seguir um tutorial de desenvolvimento de um website de forma a compreender o funcionamento e utilização desta framework (figura 16).
17
Depois do tutorial foram realizados exercícios sobre esta framework com o intuito de desenvolver o meu conhecimento nesta temática. Estes exercícios consistiam na criação do projeto bem como em ligar esse projeto a uma base de dados. Também foram realizados exercícios onde desenvolvi algumas funcionalidades que iriam ser usadas posteriormente na plataforma web, como por exemplo mostrar uma tabela com o conteúdo da base de dados e adicionar novos itens à base de dados, entre outros.
4. Construção da base da plataforma web
4.1. Contextualização
Concluídas as formações houve uma contextualização sobre a forma como a plataforma web ia ser estruturada e que tipo de dados iam estar presentes na base de dados.
Ficou então definido que na fase inicial era necessário haver três tipos de dados/objetos que representam os tipos de equipamentos existentes no laboratório: CPE, Hardware e Software.
Tecnicamente um CPE é um hardware, no entanto como há muitos equipamentos na posse da equipa houve a necessidade de fazer uma separação entre certos equipamentos.
CPE’s são equipamentos como set-top-boxes e telefones enquanto que os objetos do tipo Hardware são smartphones, tablets e televisões.
Já os objetos do tipo Software, na realidade são as licenças de programas utilizados em projetos que a equipa possui.
Figura 16 - Tutorial Django
18
Numa segunda fase houve a criação de um quarto tipo de dado/objeto que seria o Requisition.
Em termos práticos, os objetos do tipo Requisition contêm dados relativos a requisições de equipamentos realizadas por outras pessoas da empresa como por exemplo: quem efetuou a requisição, o porquê de a efetuar, que equipamento requisitou e a data de entrega, entre outros. Desta forma procedeu-se à criação da base de dados denominada de “catalog” e de um user que tinha permissões de gerir a mesma.
Na base de dados cada tipo de objeto é representado por uma tabela que contém todos os objetos existentes desse mesmo tipo. As colunas dessa tabela representam os atributos dos objetos e cada linha da tabela é um objeto em específico. No Anexo 2 está representado como a base de dados e as tabelas estão organizadas.
4.2. Criação do Projeto
Para a criação deste projeto era necessário criar a pasta onde ia estar todo o conteúdo relacionado com toda a plataforma web.
O primeiro passo é, através do terminal, aceder à localização onde queremos guardar o projeto e executar o comando “django-admin startproject nome_do_projeto”. Ao executar o comando foi criada uma pasta com o nome escolhido pelo utilizador, a qual contém outra pasta com o mesmo nome do projeto, bem como o ficheiro “manage.py” (figura 17).
O ficheiro “manage.py” é bastante importante na medida em que vai ser utilizado como linha de comando para interagir com o projeto de diversas formas. Exemplo: iniciar o servidor para o website funcionar.
A pasta com o nome do projeto contém diversos ficheiros que serão usados na criação do website, dos quais se salientam: “settings.py”, “urls.py”, “wsgi.py”, “__init__.py”.
Nome_do_projeto ├─── manage.py └─── mysite settings.py urls.py wsgi.py __init__.py
Figura 17 - Estrutura da pasta da plataforma web criada automaticamente Fonte: Elaborado pelo aluno
19
De seguida é necessário criar a pasta das “apps”, com o nome que o programador considerar apropriado e na localização desejada. Para isso, através da linha de comandos, é necessário aceder à localização desejada e correr o comando “python manage.py startapp nome_das_app”. Esta pasta vai conter os ficheiros com as funcionalidades, bem como interface da plataforma web. Ao executar o comando foi criada uma pasta que contém uma pasta chamada “migrations” e vários ficheiros (“admin.py”, “apps.py”, “models.py”, “tests.py”, “views.py”). De seguida é necessário criar um ficheiro Python na pasta anteriormente criada denominado de “urls” que vai conter todos os urls necessários para chamar as funções criadas no ficheiro “views.py” (figura 18).
catalog_projet ├─── manage.py └─── catalog_site settings.py urls.py wsgi.py __init__.py catalog_site └─── admin.py apps.py models.py tests.py views.py urls.py Migrations
Figura 18 - Estrutura da pasta da plataforma web depois de alterada Fonte: Elaborado pelo aluno
Depois de criado o ficheiro das “apps” é necessário transmitir ao Django para usar esse ficheiro, uma vez que apenas a presença da pasta com o conteúdo do website não é suficiente. Então para o Django conseguir usar a pasta “catalog_site”, é necessário adicionar no ficheiro “settings.py” a app criada no bloco de código “INSTALLED_APPS” (figura 19).
Figura 19 - App inserida em INSTALLED_APPS Fonte: Projeto desenvolvido
20
4.3. Desenvolvimento do Projeto
Criação dos models:
A função dos models é descrever algo real no código, por exemplo um dos models criados neste projeto foi o “Software” que continha vários atributos dos quais se destacam o “software_brand” que é a marca do software (objeto do tipo “Software”) e “reception_date” que é a data de quando este
software foi adquirido, o que significa que qualquer objeto existente ou que venha a ser criado na
base de dados do tipo “Software” vai ser descrito por diversos atributos como os que foram referenciados anteriormente.
Os Models são uma classe que representa uma tabela numa base de dados que armazena propriedades, atributos e ações (model field) e que representam uma coluna da tabela na base de dados. Cada um destes models contém os seus respetivos atributos e um ID que também é considerado um atributo com a diferença de este ser único para cada objeto, isto é cada objeto criado pelo utilizador vai tem um ID único que não pode ser igual ao ID de outro objeto.
Para que cada objeto tenha o seu ID único foi criada uma função dentro de cada uma das classes denominada de “generate_id” que tem como função gerar automaticamente um ID sempre que é criado um novo objeto.
É necessário definir estes tipos de objetos no ficheiro “models.py”. Neste ficheiro vão ser criadas classes para cada um dos tipos de objetos e os atributos que cada classe vai possuir.
Figura 20 - Parte do código do model CPE Fonte: Projeto desenvolvido
Como se pode observar na figura 20, inicialmente foi definida uma classe com o nome “Cpe” com diversos model fields dos quais se destacam “cpe_id”, “brand”, “service_provider” e “model”.
Na figura 20 apenas foram criados model fields do tipo CharField, o que significa que o conteúdo dessas colunas vai ser do tipo string. Contudo há outros tipos de model fields, como DateFields que também foram utilizados neste projeto, e a diferença deste tipo em relação ao anterior é que as colunas definidas desta forma só podem conter datas.
21
Outra característica é que todas estas colunas devem estar preenchidas obrigatoriamente pois um dos atributos é “Null=False” que significa que essa coluna não pode estar vazia. Para além deste atributo é obrigatório atribuir sempre o número máximo de carateres que aquele model field deve ter, caso contrário o Django vai apresentar um erro alertando para que “max_length” não está definido.
Os restantes models (Hardware e Software) foram criados da mesma forma e diferem apenas no nome da classe que os define e no nome dos model fields que cada um tem.
Por fim ao criar um model é necessário transmitir à base de dados a criação de novos models e o mesmo é efetuado através de migrations.
Quando os models são criados, não são colocados diretamente na base de dados, é necessário executar certos comandos no terminal para que na base de dados sejam criadas as tabelas respetivas aos models criados.
Inicialmente executa-se o comando “python manage.py makemigrations catalog_site” e este comando transmite a informação à base de dados sobre a forma como as tabelas são constituídas, como por exemplo o nome de cada uma e que atributos vai ter.
Para finalizar é necessário confirmar as alterações feitas na base de dados, ou seja, é necessário que o utilizador confirme que realmente quer alterar a base de dados. Este último passo é feito através do comando “python manage.py migrate”. Este processo de confirmação pode ser observado na figura 21.
Figura 21 - Exemplo de Migrations Fonte: Projeto Desenvolvido
22
Criação de Model Forms:
Através da criação dos models já era possível mostrar, através das páginas HTML, os model fields e assim o utilizador fazer uso dos mesmos. No entanto, o Django disponibiliza a classe Form que vai tratar da interface das páginas web.
A classe form, semelhante à classe model, descreve a estrutura lógica de um objeto, o seu comportamento e a maneira como vai ser organizada e apresentada a interface do mesmo ao utilizador. Tal como a classe model que mapeia os model fields para a base de dados, a classe form mapeia os form fields para os elementos “<input>” do formulário HTML.
Resumidamente, a classe form descreve um formulário e determina o seu funcionamento e interface. Quando é criado um form, é possível deixá-lo vazio ou preenchê-lo com:
dados provenientes/baseados de um model guardado previamente ;
dados obtidos através de outras fontes;
dados recebidos por um post de um formulário do utilizador.
Neste projeto todos os forms criados eram baseados nos models ou seja quando era criado um form, o mesmo ia conter form fields (campos de preenchimento do formulário) correspondentes aos fields do
model em que era baseado.
Por exemplo se um model field for definido como Charfield, posteriormente o form criado e correspondente a esse model, vai ter um form field do tipo Charfield.
Com os forms é possível fazer validações do conteúdo que o utilizador está a colocar em cada model
field e isto é vantajoso, pois vai haver uma validação do que está a ser inserido ou editado e caso
esses dados estejam incorretos o utilizador não vai poder finalizar a ação que estava a realizar no
website e será avisado qual é o erro que provoca isso.
Assim sendo foram criados diversos forms, no ficheiro “forms.py”, baseados em models previamente criados.
Na criação de forms também é definido o tipo de conteúdo e a forma como o respetivo campo de preenchimento irá ser mostrada ao utilizador através de CharFields e ChoiceFields, entre outros.
23
Tal como na classe model, a classe form vai ter atributos que vão definir como este campo vai ser mostrado ao utilizador, isto é, nestes atributos vão estar dados relativos ao tipo de campo de preenchimento que vai aparecer (o seu tamanho e a label que vem com ele, entre muitas outras opções). Nos forms criados, para além dos atributos já referidos, foram adicionados atributos que controlam o número máximo de carateres, bem como se o preenchimento dos forms é obrigatório ou não.
Como é possível observar na figura 22, depois de ser definida a classe form, neste caso “HardwareForm”, é necessário transmitir ao Django qual é o model em que este form se vai basear. O mesmo é feito através da “classe Meta”. Para além de definir em que model é baseado, é necessário identificar os campos desse model que vão estar relacionados com os fields do form. É ainda importante referir que na construção do form, a forma que o Django usa para relacionar os
fields com os model fields criados é a ordem de escrita, contudo depois na construção do HTML já
não é necessário ser rigoroso na ordem pela qual os campos de preenchimento aparecem.
URLS:
Após a criação dos models e dos forms é necessário criar urls das páginas.
Url é o endereço de um recurso disponível numa rede, ou seja, o url é o path (caminho) que indica a
localização do que o utilizador procura quer seja um aquivo, um website ou até mesmo um dispositivo periférico como uma impressora.
Estrutura do url:
Um url é constituído por esquema, domínio, porta (opcional) e path, e tal como a porta o url pode ser constituído opcionalmente por um query string e um fragment.
Exemplo: http://127.0.0.1:8000/catalog_site/details/AMLC01021
Esquema é o protocolo que poderá ser HTTP, HTTPS, FTP etc.
Figura 22 - Parte do código do model form Hardware Fonte: Projeto Desenvolvido
24 Domínio é o endereço da máquina que designa o servidor que disponibiliza o documento ou recurso solicitado pelo utilizador. No exemplo acima, o endereço da máquina é 127.0.0.1 que o localhost (o próprio computador do utilizador)
Porta é o ponto lógico no qual se pode executar a conexão com o servidor. No exemplo acima a porta é o 8000.
O path especifica o local onde se encontra o recurso no servidor (catalog_site/details).
A query string é um conjunto de um ou mais pares "pergunta-resposta" ou "parâmetro-argumento" (neste caso id=AMLC01021, em que o id é uma variável (neste caso é um atributo de um objeto), e AMLC01021 é o valor a essa variável). Resumidamente, o que este pedaço do url faz é enviar uma string ao servidor para que seja possível filtrar o recurso, ou seja vai dizer ao servidor para ir buscar o recurso que tem o id AMLC01021.
O fragment é uma parte ou posição específica dentro do recurso.
Neste projeto, um dos ficheiros foi criado automaticamente e esse ficheiro vai conter apenas dois
urls.
A criação dos urls consiste apenas em definir o path, como o mesmo vai ser constituído e que possíveis funções vão estar associadas.
Figura 23 - Urls presentes no ficheiro "urls" criado automaticamente Fonte: Projeto Desenvolvido
O primeiro url que pode ser observado na figura 23 foi criado automaticamente com o ficheiro e direcionava o utilizador para uma página admin do website, porém essa funcionalidade não foi desenvolvida, pois o que estava planeado era apenas a construção de um website funcional onde não existiam tipos de usuários e restrições.
Na criação de um url é necessário definir qual o path que vai ter bem como o que vai acontecer ao aceder a esse url.
25
Como se pode observar na figura 23, na criação de urls a parte inicial é comum a todos (“r’^”) e só diferem a partir daí. Isto deve-se ao facto de que o que é escrito a seguir a esses três carateres vai ser o path do url. Por exemplo, o terceiro url coloca “catalog_site” no path e de seguida, através do código “include(catalog_site.urls)”, transmite ao Django que esse mesmo path pode ter continuação e que essa mesma continuação vai estar no ficheiro “urls” presente na pasta “catalog_site”.
Já o segundo url o que faz é dizer transmite Django que caso path esteja vazio, vai fazer um redirecionamento para o terceiro url. Este redirecionamento é feito através do código “RedirectView.as_view(url=’catalog_site/’, permanente=False)”.
Na prática o que acontece é passar o endereço, neste caso do localhost (“127.0.0.1:800”) para “127.0..0.1:800/catalog_site/” em que “127.0.0.1:800” são o domínio e a porta.
Em relação ao segundo ficheiro dos urls.py, todos os urls definidos vão funcionar de forma semelhante, com a diferença de que os mesmos serão uma continuação do url “catalog_site” definido anteriormente (figura 24).
Isto significa que o path começa sempre por “catalog_site/” e vão sendo acrescentados carateres de acordo com o que o utilizador vai solicitar no website ou funcionalidades a que vai aceder.
A função destes url é executar métodos/funções definidos no ficheiro “views.py”. Tomando o segundo url como exemplo, é possível observar que o path desse url é “index” e é seguido pelo código ”views.main”. O que isto faz é transmitir ao Django que quando este endereço url é utilizado, o website deve executar o método “main” presente no ficheiro “views.py”.
Os restantes funcionam todos da mesma forma e mudam apenas na constituição do path e no método que é executado.
Figura 24 - Alguns dos urls presentes no ficheiro "urls" criado posteriormente Fonte: Projeto Desenvolvido
26 Views e Templates
Como foi referido anteriormente, ao criar o projeto é criado automaticamente um ficheiro Python denominado de “Views”. Este ficheiro contém funções Python, que recebem um pedido e retornam uma resposta.
Por convenção, este tipo de funções são colocadas neste ficheiro, daí o facto de ter sido criado automaticamente.
As views, de uma forma geral são compostas por uma função criada pelo programador e que, através de um url, está ligada a um template específico. Templates são as páginas HTML através das quais o utilizador consegue visualizar e interagir com as mesmas, onde faz pedidos e recebe respostas por parte da aplicação. De forma resumida, essa é a função dos templates uma vez que os navegadores
web não conseguem traduzir linguagens de programação como o Python e é necessário haver uma
forma de gerar código HTML e Python para que o website não se torne estático.
Um template contém código HTML que mostra o output do website ao utilizador e contém ainda uma syntax especial para que seja possível a ligação entre HTML e Python podendo assim criar páginas web interativas.
O funcionamento destas funções é efetuado sempre da mesma forma. Inicialmente o utilizador envia um pedido ao servidor (request) através de um url que que contém as informações do pedido. De seguida, o servidor analisa o pedido e retorna uma resposta através de um template ou da execução de uma ação (Figura 25).
Figura 25 – Interação entre o utilizador, plataforma web e servidor Fonte: http://django-easy-tutorial.blogspot.pt
27
Neste projeto foram criadas diversas views para que fosse possível interagir com a aplicação de diversas formas, das quais se salientam adicionar, editar objetos e visualizar os detalhes quer de um objeto apenas quer de uma lista inteira de objetos presentes na base de dados. E para cada uma
Lista de todos os equipamentos da base de dados:
Ao iniciar a aplicação, a página inicial é composta por uma lista de todos os equipamentos do laboratório bem como algumas das características que possuem. Para além da lista, existe um botão “Add” que permite ao utilizador adicionar novos equipamentos à lista. Por fim a página inicial tem uma sidebar onde o utilizador pode escolher que tipo de equipamento deseja ver (CPE, Hardware, Software) e ainda a opção de ser redirecionado para a página que trata das requisições dos equipamentos da equipa. Estas funcionalidades podem ser observadas no Anexo 3.
Na prática o que acontece é que o utilizador, ao iniciar a aplicação, está a efetuar um pedido ao servidor, através do url da página inicial. De seguida, o servidor lê e processa o pedido e vai retornar o template da página inicial.
Como foi explicado anteriormente, quando o utilizador acede a uma página web, a mesma tem um
url que vai executar um método e neste caso será o método “main”. Esta função é que é responsável
pelo processamento do pedido realizado e pelo retorno do mesmo.
O que acontece é que a função vai guardar todos os dados dos models (CPE, Hardware e Software) presentes na base de dados e guardá-los num dicionário denominado de “context”. E de seguida vai retornar o template da página inicial preenchido com os dados guardados, neste caso as tabelas com os dados de todos os models (figura 26).
Figura 26 - Código da função main Fonte: Projeto Desenvolvido
28
Depois de criada a função que possibilita a visualização do conteúdo da base de dados é necessário criar um template que essa função vai retornar (Figura 27). Como é possível observar no Anexo 3, o
template do menu inicial mostra os equipamentos e os seus atributos através de uma tabela.
Figura 27 – Parte do código do template da lista de equipamentos Fonte: Projeto Desenvolvido
Inicialmente cria-se a tabela e de seguida definem-se os headers da mesma (“<th> … <th>”), que são os nomes que descrevem o conteúdo que cada coluna vai ter.
É necessário preencher a tabela com os dados da base de dados. Assim sendo, foi criado um ciclo que vai procurar cada um dos objetos presentes na lista de dados e mostrá-los na tabela. Uma vez que a linguagem HTML é estática, é necessário colocar quer o ciclo “for” quer os dados dos objetos entre “{}” de forma a dizer ao Django que aquelas linhas são código Python. Ao longo do projeto, na criação de templates foi muito utilizada esta syntax tornando assim a plataforma web interativa. No que diz respeito à mudança entre as listas de tipos de equipamentos, esta é feita através de JavaScript. Basicamente, o JavaScript criado o que vai permitir que quando o utilizador prime, por exemplo, o botão Software, as listas Hardware e CPE vão ficar invisíveis e a lista Software não (figura 28).
Figura 28 - Script “hw_change()” Fonte: Projeto Desenvolvido
29
Para além dos botões referidos anteriormente existe ainda o botão “Requisition” presente na sidebar e o botão “Add”. Ambos têm funções e funcionamentos semelhantes. O botão “Requisition” tem como função redirecionar o utilizador para a página das Requisições de material, já o botão “Add” redireciona o utilizador para o formulário de adicionar equipamentos à base de dados. Tudo isto é realizado através do atributo “href”. Este atributo contém um url definido, neste caso o url do
template das páginas de Requisições e do formulário de adicionar equipamentos e quando o botão é
pressionado, o utilizador é redirecionado para a página HTML correspondente a esse template.
Adicionar Dados:
Quando o utilizador prime o botão “Add” no menu principal é direcionado para uma página HTML que tem um formulário para adicionar novos objetos à base de dados com diversos campos de preenchimento, como é possível observar no Anexo 4.
Para criar o template de adicionar equipamentos é necessário existirem três formulários diferentes para cada um dos tipos de objetos nesse template. Apesar da diferença, entre eles o código HTML dos três formulários é semelhante e só muda os nomes dos model fields, já que a estrutura é igual. Mas antes de referir os formulários é importante referir e explicar certas linhas de código que têm um papel importante para o correto funcionamento de qualquer página HTML que implique a gestão de uma base de dados.
Figura 29 – form Fonte: Projeto Desenvolvido
A linha <form action=”…” method=”post” … <form> é muito importante na medida em que vai especificar como é que os dados vão ser enviados para uma determinada página.
O atributo “action”, através do url, indica qual é a localização para onde os dados serão enviados. Neste caso os dados serão enviados para a página “add_item.html” como se pode observar na figura 29.
Já o atributo “method” define como é que os dados vão ser enviados. Há diversas formas de enviar dados mas as mais comuns são através do método “get” e “post”. Quando são pedidos os dados através do método “get”, o servidor retorna os dados pelo url, porém o objetivo é receber os dados no
30
body do HTML, na própria página e não na barra de endereços. Por essa razão é que é usado o
método “post” e através deste método a resposta que o servidor vai enviar ao utilizador é no body da página e não no url.
Posto isto é possível passar à criação do template do formulário de adicionar itens/equipamentos. Como é possível observar no Anexo 4, o formulário é constituído por diversos campos de preenchimento de acordo com o tipo de equipamento que o utilizador pretende adicionar e um botão “Submit” que irá guardar todos esses dados na base de dados. O código relativo a cada campo de preenchimento é muito semelhante entre eles como se pode observar na figura 30.
Figura 30 - Parte do código do template de adicionar equipamentos Fonte: Projeto Desenvolvido
Para explicar o código vou tomar, como exemplo, o bloco do código relativo ao campo preenchimento do “model” presente na figura 30.
Na primeira linha o código “form_cpe.model.label_tag” acede aos forms criados anteriormente no ficheiro “forms.py”, mais especificamente ao “form_cpe” buscar a label definida no field do “model”. Na linha seguinte “form_cpe.model” vai buscar que tipo de field é, neste caso é um CharField que é uma caixa de texto para inserir dados. Caso o tipo de field fosse ChoiceField como é o caso do model field “brand” é apresentada uma drop-down list com opções para o utilizador escolher como se pode observar no Anexo 4. Por fim a última linha tem como função avisar o utilizador de erros. Caso o utilizador tente submeter um dado incorreto, vai surgir uma alert box que é um pequeno texto debaixo do campo incorreto a avisar o utilizador que o valor que está a tentar submeter está incorreto como se pode observar na figura 31.
31
Figura 31 - Alert box Fonte: Projeto Desenvolvido
Como já foi referido, a página “Add Items” é um formulário para adicionar novos equipamentos à base de dados, porém existem três tipos de equipamentos diferentes. Isto significa que quando o utilizador acede à página tem de existir a possibilidade de escolher que tipo de equipamento quer adicionar e só pode aparecer o formulário de adicionar relativo a esse tipo de equipamento. Portanto, é preciso existir uma forma de separar os formulários dos diferentes equipamentos. Devido a isso foi criado um JavaScript semelhante ao do menu inicial que torna os formulários visíveis ou invisíveis de acordo com a opção selecionada na sidebar.
Depois de concluída a construção da interface da página, falta apenas tornar a página funcional, isto é falta permitir que a página receba os dados do utilizador, valide e guarde os mesmos na base de dados. Para tal é necessário criar uma função que valide e guarde os dados do utilizador na base de dados quando o mesmo clicar no botão “Submit”.
Na prática, o utilizador vai solicitar um request8 (get) ao servidor do template (figura 32). Esse
template é uma página HTML com um form renderizado nela. De seguida, o servidor retorna o template com o formulário, que será preenchido pelo utilizador e posteriormente será executado um post do formulário (figura 33). Quando o post é executado é feita uma validação do formulário
(figura 34). Caso o formulário seja válido, os dados do mesmo serão guardados na base de dados e o utilizador é redirecionado para o menu inicial (figura 35). Se o formulário não for válido, o utilizador será avisado do erro e continuará na página “Add Item”, como se pode observar na figura 31.
32
Request (get):
Post: Função que verifica se o request feito é um “Post”
Figura 33 - Código da função add_item que faz o post dos dados Fonte: Projeto Desenvolvido
Validação:
Figura 32 - Código da função “add_item” que faz o get Fonte: Projeto Desenvolvido
Figura 34 – Código da função “add_item” que valida os dados inseridos Fonte: Projeto Desenvolvido
33
O método “is_valid” vai validar cada campo do form e, caso o mesmo seja válido, os dados desse campo vão ser guardados numa forma normalizada e consistente (“cleaned_data”).
Criar e guardar objeto:
“Cpe.objects.create(…)” vai criar o objeto com os dados de cada campo do formulário já normalizados. Esses dados são guardados na variável “query_cpe”.
“query_cpe.save()” vai guardar os dados na base de dados.
Detalhes de um item:
Esta funcionalidade permite ao utilizador ver um objeto de forma detalhada. Para aceder aos detalhes de um item, o utilizador apenas necessita de clicar no ID do objeto no menu principal. De seguida, será redirecionado para a página HTML onde se encontra a informação detalhada desse objeto. Nessa página há também um botão “Edit” que permite ao utilizador editar o respetivo objeto. Todo este processo está representado visualmente no Anexo 5.
Tal como é feito na criação de qualquer funcionalidade da plataforma web, é necessário criar um url, um template e uma função, neste caso que mostre os dados do objeto.
Depois do url ter sido criado, procede-se à criação de uma função que pesquise na base de dados os dados relativos ao objeto específico escolhido pelo utilizador. O que vai acontecer é que o utilizador envia um request ao servidor (uma string), neste caso o ID do equipamento, e de seguida o servidor vai pesquisar na base de dados o objeto que tem o ID igual à string enviada e retorna o template da página “Details” com toda a informação relativa a esse objeto.
Figura 35 - Código da função “add_item” que cria e guarda os dados na base de dados Fonte: Projeto Desenvolvido
34
Figura 36 - Função “details” Fonte: Projeto Desenvolvido
Na figura 21 podemos observar que foram criadas três páginas HTML diferentes para cada tipo de objeto e uma forma de filtrar o tipo de objeto que o utilizador escolheu. Esta filtragem é feita através do método “startswith”. O que este método vai fazer é verificar como começa a string enviada pelo utilizador. Por exemplo se a string enviada começar por “AMLH” significa que o objeto selecionado é um Hardware. Por conseguinte o servidor vai comparar a string recebida com todos os ID’s dos objetos do tipo Hardware e depois retorna o template “hardware_details” que é o template criado para mostrar os detalhes dos objetos do tipo Hardware.
Por fim, basta criar a interface da página que está representada no Anexo 5.
Editar Item:
A funcionalidade “Editar” foi feita com o intuito que, caso o utilizador se engane a adicionar dados na tabela ou por ventura os dados estejam desatualizados, seja possível alterá-los sem ser necessário criar um objeto novo na base de dados.
Como é descrito no Anexo 6, para poder editar um objeto é necessário aceder à página de detalhes do objeto em causa e de seguida clicar o botão “Edit”. Já na página de edição do objeto o utilizador vai deparar-se com um formulário igual ao formulário de adicionar objetos com a diferença de que este já está preenchido com os respetivos dados desse objeto. Depois basta atualizar os dados desejados e clicar no botão “Save”.
Editar um item é muito semelhante à funcionalidade adicionar com a diferença de que o formulário “Edit Item” já vem preenchido contrariamente ao “Add Item”. Tal como as restantes funcionalidades,
35
é solicitado um request por parte do utilizador e o mesmo irá retornar o formulário de edição já preenchido (Figura 37).
Figura 37 - Código da função "edit_item" que trata do get Fonte: Projeto Desenvolvido
De seguida, o utilizador faz as alterações necessárias e clica no botão “Save”. Ao clicar no botão, os dados serão validados e dependendo do facto dos dados estarem corretos ou não, o servidor vai guardar o objeto com as novas alterações ou mostrar quais os campos que não foram preenchidos corretamente.
Requisições:
Uma vez que o laboratório possui diversos equipamentos, é comum que outros projetos da empresa façam requisições de alguns desses equipamentos. Dessa forma surgiu a necessidade de também criar na plataforma web algo que gerisse essas requisições.
A forma como esta segunda parte da plataforma web foi construída é muito semelhante à anterior. Inicialmente ao aceder às requisições, o utilizador depara-se com a lista de todas as requisições feitas, um botão de adicionar novas requisições e uma sidebar com a opção de retornar à lista de equipamentos. Para além de adicionar requisições, o utilizador tem a possibilidade de visualizar a requisição detalhadamente clicando no id da requisição e de seguida editar a mesma.
Ao clicar no botão de adicionar, o utilizador é redirecionado para o formulário de adicionar requisições. Depois do formulário ser preenchido corretamente, o utilizador volta para a página Inicial (lista das requisições) onde é possível ver na tabela a nova requisição. Quando uma requisição é adicionada vai ficar com o estado (“req_status”) em “Requested”. Para além deste estado, a requisição pode estar “Canceled”, “Delivered” e “Returned”. Este processo de criar uma nova requisição é apresentado no Anexo 7.
No que toca aos estados da requisição, ela fica “Canceled” quando alguém faz a requisição do equipamento mas depois a cancela antes de o equipamento ser entregue. Após a requisição ser
36
cancelada só é possível editar alguns campos que estejam incorretos. Para realizar o mesmo pedido é necessário fazer uma nova requisição.
Para ficar no estado “Delivered”, o equipamento deve ser requisitado e entregue à pessoa que fez a requisição do mesmo.
Por fim quando a pessoa devolve o equipamento requisitado, a requisição fica no estado “Returned”.
Cancelar Requisição:
Para cancelar uma requisição, o utilizador apenas necessita de aceder aos detalhes da requisição desejada e clicar no botão “Cancel Requisition”. De seguida, aparece uma pop-up9 de confirmação
de cancelamento da requisição e caso o utilizador cancele, será redirecionado de volta para a lista de requisições. Para executar este processo de cancelamento de requisições foi criado um script que através do atributo “window.location.href” faz com que ao confirmar o cancelamento da requisição, seja executado o método “cancel_requisition” definido em “views.py”. Este método simplesmente vai efetuar um update no campo “req_status” da respetiva requisição de “Requested” para “Canceled” e redirecionar o utilizador para a lista de requisições Figura 38. O Anexo 8 descreve o processo de cancelamento de uma requisição.
Figura 38 - Função “cancel_requisition” Fonte: Projeto Desenvolvido
Entregar equipamento:
Caso a requisição não seja cancelada, significa que o equipamento requisitado foi entregue, logo é necessário mudar o estado da requisição para “Delivered”, bem como preencher um formulário relativo ao equipamento que vai ser requisitado e a data de entrega e retorno do mesmo. Para isso, o utilizador necessita de aceder aos detalhes da requisição e de seguida clicar no botão “Deliver”. Após clicar no botão, o utilizador é redirecionado para uma nova página HTML que para além de conter o
9É uma janela que aparece nos navegadores web normalmente para dar informação extra ou como forma de garantia de certa ação nos
