Tp:; 1 dalGuardaEscola Superiorde Tecnologia e Gestflo

RELATÓRIO DE ESTÁGIO

Curso Técnico Superior Profissional

em Desenvolvimento de Aplicações Informáticas

André Marcelino Baptista

julho 12017

Escola Superior de Tecnologia e Gestão

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 –

Computer Software

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

Bibliografia .......................................................................................................................................... 42

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

Anexo 10 - Devolução do equipamento ........................................................................................... 81

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

Figura 25 – Interação entre o utilizador, plataforma web e servidor ................................................... 26

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

Figura 42 - Box 2.0 HD+DVR ............................................................................................................. 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 Caracterização da Instituição de Estágio

4

1. Instituição1

1.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;

1 Fonte: www.altran.pt (consultado em 19/07/2017)

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)

Fonte http://www.altran.pt

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.

3 Conjunto de condições usadas para testes de software.

8

Capítulo II O Estágio

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

Fonte: https:pt.wikipedia.org/wiki/HTML5

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

Fonte: https://www.debian.org/index.pt.html

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

Fonte: https://en.wikipedia.org/wiki/PyCharm

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

Fonte: https://docs.djangoproject.com/en/1.11/intro/tutorial01/

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.

8 Pedido do utilizador feito ao servidor

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

navegadores web

37

formulário de preenchimento vai conter os detalhes relativos à requisição do equipamento que vai ser

entregue. Depois do formulário ser preenchido corretamente, o utilizador guarda os dados e é

redirecionado para a lista de requisições onde pode observar a alteração do estado da requisição.

Figura 39 - Código da função "deliver_form" que adiciona novos dados e altera o estado da requisição

Fonte: Projeto Desenvolvido

Como se pode observar na figura 39, inicialmente é feita uma filtragem do Aml_ID (o ID do

equipamento) de forma a verificar se o ID do equipamento que está a ser requisitado está correto. E

só depois dessa verificação é que são adicionados os novos campos dessa requisição.

Para além da alteração do estado, os campos que inicialmente estavam vazios (“None”) foram

preenchidos. Um desses campos preenchidos, denominado de “Aml_ID”, tem a particularidade de ter

um link associado a ele, tal como os “ID’s”, e que quando selecionado, o utilizador é redirecionado

para a página de detalhes do equipamento que foi requisitado.

É de notar ainda que na entrega de um equipamento, para além do estado da requisição ser alterado,

também é necessário que o estado do equipamento requisitado seja alterado. Isto significa que para

além de alterar o campo “req_status” dessa específica requisição, vai alterar o campo “status” caso o

equipamento requisitado seja um CPE ou o campo “hw_status” caso seja um Hardware de “Stock”

para “Delivered” (Figura 40). No anexo 9 está demonstrado passo a passo como é realizada a entrega

de um equipamento.

Figura 40 - Código da função "deliver_form" que altera o estado dos equipamentos

Fonte: Projeto Desenvolvido

38

Retorno do equipamento:

Depois de um equipamento ter sido entregue, ele tem de ser devolvido, o que implica alterar o estado

da requisição para “Returned”. Então quando o equipamento é devolvido, o utilizador necessita

apenas de aceder aos detalhes dessa requisição e clicar no botão “Return”. Automaticamente o estado

vai ser alterado para “Returned” e o campo “Return Date” vai ser alterado para o dia em que o

utilizador efetuou essa ação. O processo é semelhante ao de cancelar uma requisição com a diferença

de que para além de ser alterado o estado da requisição, neste caso para “Returned”, também é

alterado o estado do equipamento de volta para “Stock”, como se pode observar no Anexo 10.

39

5. Outras tarefas realizadas

Para além do projeto delineado no meu plano de estágio, foi-me solicitado pela equipa a realização

de testes funcionais (testes de fiabilidade, funcionais, desempenho e segurança) a duas set-top-boxes.

Box 2.0 HD+ (figura 41):

Figura 41 - Box 2.0 HD+

Fonte: http://www.modainteractiva.com

Box 2.0 HD+DVR(figura 42):

Figura 42 - Box 2.0 HD+DVR

Fonte: https://pplware.sapo.pt

Os testes funcionais têm como objetivo testar os requisitos funcionais de uma aplicação, sistema ou

dispositivo e verificar se o mesmo está apto para realizar o que é suposto fazer. Desta forma foram

simulados vários cenários e depois realizados testes.

Cenários simulados:

Testar set-top-box após falha de rede;

Testar set-top-box após falha de energia;

40

Testar set-top-box após restauro de Parâmetros de Fábrica;

Testar set-top-box após atualizações;

Os testes podiam ter três resultados, “Passou”, “Não Passou” e “N/A” (not aplicable) ou “Out of

Cope”. Este último resultado acontecia quando o test case que era pedido, não podia ser realizado

pelo facto de o dispositivo não ter os requisitos ou funcionalidades necessários.

A forma de realizar estes testes é executá-los e comparar o resultado obtido com o resultado esperado

e a partir daí determinar se passou ou não no teste.

Foram-me então entregues diversos test cases em suporte Excel, onde para além de referir quais os

testes a realizar e qual era o resultado esperado, continha a explicação de como realizar o teste passo

a passo.

41

Conclusão

Este estágio foi muito benéfico, uma vez que me permitiu o trabalho direto numa equipa dinâmica e

organizada, bem como estar integrado no mercado de trabalho.

Numa fase inicial, foi um grande desafio, pois fui confrontado com muita informação que importava

adquirir e compreender, o que exigiu uma aprendizagem contínua. Na medida em que nunca tinha

tido contacto com a maior parte das tecnologias usadas para desenvolver o projeto, isso implicou

uma grande curva de aprendizagem da minha parte. No entanto, graças a toda a formação que recebi

e também toda a ajuda e conhecimento transmitido pelo meu supervisor da intuição consegui superar

muitas dificuldades e adquirir bases importantes na área da programação que vão ser extremamente

benéficas no meu futuro.

Para além disso, a integração na equipa foi muito positiva, uma vez que sempre existiu um ambiente

amigável, de boa disposição e entreajuda.

Relativamente a competências técnicas, aprendi quase tudo, pois trabalhei com ferramentas e

linguagens que não conhecia, pude pôr os conhecimentos adquiridos em prática, ou seja, houve

tempo e disponibilidade para aprendizagem e desenvolvimento de competências, bem como, para

executar trabalho útil em contexto profissional. Ainda sobre as tecnologias usadas, penso que foi

uma escolha assertiva optar pelo Django pois é uma ótima framework de desenvolvimento de

plataformas web e é escrito numa linguagem muito acessível e de alto nível.

Os obstáculos, porque também os houve, foram ultrapassados com a pronta colaboração do meu

supervisor e foram encarados por mim como oportunidades de aprendizagem e enriquecimento

pessoal e profissional. Para além da curva de aprendizagem que tive com as novas tecnologias,

durante o projeto surgiram diversos obstáculos como a criação da drop-down list que permitia o

utilizador escolher os tipos de “brands” e “hardware_types”. Ambas as drop-down lists funcionavam

da mesma forma, no entanto, houve muitas dificuldades em ligá-las à base de dados, o que implicou

a criação de dois novos models, um para as “brands” e outro para os “hardware_types”. Mesmo após

a criação desses dois models, surgiram diversos problemas em relação à estrutura da dropdow, da

forma como era organizada, mas no final foi tudo superado.

Pelo exposto, considero que este estágio foi uma experiência muito enriquecedora, tanto em termos

académicos como profissionais, tendo sido ao mesmo tempo uma oportunidade e um desafio.

42

Bibliografia

“Altran” disponível em: http://www.altran.pt/; acedido em 18/07/2017

“Aulas interativas com recurso à exposição: Uma metodologia para o ensino da linguagem de programação

Borges, Luiz Eduardo (2010) Python para desenvolvedores. Rio de Janeiro: Edição do autor

“Desenvolvimento de uma aplicação web de análise de registos de utilização” - Armindo Eugénio de Sousa

Pereira disponível em https://repositorio-aberto.up.pt/bitstream/10216/70951/2/24207.pdf; acedido em

18/07/2017

“Python” – Maria Elisabete de Sousa disponível em

https://repositorium.sdum.uminho.pt/bitstream/1822/38294/1/Maria%20Elisabete%20de%20Sousa%20Cunha

.pdf; acedido em 18/07/2017

“O que é Django?” disponível em https://tutorial.djangogirls.org/pt/django/; acedido em 18/07/2017

“Django (framework web)” disponível em https://pt.wikipedia.org/wiki/Django_(framework_web) ; acedido

em 18/07/2017

“Linguagem de script” disponível em https://pt.wikipedia.org/wiki/Linguagem_de_script; acedido em

18/07/2017

“Linguagem interpretada” disponível em https://pt.wikipedia.org/wiki/Linguagem_interpretada; acedido em

18/07/2017

“Models” disponível em https://docs.djangoproject.com/pt-br/1.11/topics/db/models/; acedido em 18/07/2017

“Modelos do Django” disponível em https://tutorial.djangogirls.org/pt/django_models/; acedido em

18/07/2017

“O Que é Uma Solução Open Source?” disponível em

http://www.sinfic.pt/SinficWeb/displayconteudo.do2?numero=24957; acedido em 18/07/2017

“Python” disponível em https://pt.wikipedia.org/wiki/Python; acedido em 18/07/2017

“Stackoverflow” disponível em https://pt.stackoverflow.com/questions/17082/o-que-%C3%A9-uma-

linguagem-de-script; acedido em 18/07/2017

“Vamos começar a programar em Python? (Parte I)” disponível em https://pplware.sapo.pt/tutoriais/vamos-

comecar-a-programar-em-python-parte-i/; acedido em 18/07/2017

43

Anexos

44

Anexo1 Plano de Estágio

45

Plano de Estágio

2017

TESP EM DESENVOLVIMENTO DE APLICAÇÕES INFORMÁTICAS ANDRÉ MARCELINO

ALTRAN PORTUGAL | Lisboa

46

ÍNDICE

A. .................................................................................................................................................. ÍNDICE 46

A. .......................................................................................................... OBJECTIVOS E JUSTIFICAÇÃO 47

B. ........................................................................................................................... PLANO DE ESTÁGIO 48

1. Contextualização ....................................................................................................................................48

2. Desafio ....................................................................................................................................................48

3. Requisitos ...............................................................................................................................................49

4. Proposta ..................................................................................................................................................50

5. Tarefas ....................................................................................................................................................50

6. Cronograma ............................................................................................................................................51

C. .................................................................................................................... ANEXO AO PROTOCOLO 52

47

A. OBJECTIVOS E JUSTIFICAÇÃO

Pretende-se proporcionar ao aluno finalista um contacto privilegiado com as realidades existentes,

como complemento da formação académica.

O objetivo final do estágio será apoiar a inserção do aluno no mercado de trabalho, proporcionando

as condições adequadas à consolidação e aprofundamento dos conhecimentos teóricos adquiridos,

conjugados com a aplicação prática da atividade da organização em que se realize o estágio.

O estagiário terá o indispensável acompanhamento durante todo o período do estágio e a atividade

por ele desenvolvida será devidamente avaliada.

48

B. PLANO DE ESTÁGIO

Contextualização

A Altran Portugal dispõe de um laboratório dedicado para efetuar testes e desenvolvimentos

relacionados com CPE’s - Customer Premises Equipments – que não são mais do que os

equipamentos existentes na casa dos clientes, como por exemplo routers, set-top boxes ou

repetidores.

Este Laboratório, denominado por Expertise Center de CPEs, Video & Voice, possui uma rede

própria que possibilita replicar a rede dos operadores, permitindo ligar os dispositivos que

geralmente se encontram nas casas dos clientes, tais como, computadores, smartphones, tablets,

PlayStation, 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).

Adicionalmente a Altran implementa projetos de desenvolvimento e testes de Software na área

mobile e dada a variedade de dispositivos móveis existentes no MediaLab, são efetuadas requisições

destes para suportar outros projetos extra Expertise Center.

Desta forma, surge uma enorme necessidade de gerir não só os equipamentos recebidos pelos

diversos clientes da Altran como também todos os dipositivos utilizados para efetuar os testes e

suporte bem como as requisições de material.

Desafio

Atualmente, a gestão dos equipamentos do laboratório é feita através de um ficheiro Excel e as

requisições de material são efetuado através de formulários em papel. A gestão deste catálogo em

Excel e em papel foi efetiva durante algum tempo, dado que o número de dispositivos era baixo, no

entanto, devido ao rápido crescimento, esta gestão torna-se ineficiente devido a:

necessidade de atualizar regularmente o ficheiro Excel, e manter backups do ficheiro de modo

a não perder informação;

49

o catálogo é gerido e mantido apenas por uma pessoa, o que torna as consultas ao ficheiro

morosas, uma vez que estas consultas tem de passar sempre pela pessoa responsável;

necessidade de manter (em papel) os pedidos de requisição de material, que facilmente pode

ser perdido;

Requisitos de material que excederam o tempo de entrega não são facilmente visualizados.

Adicionalmente no âmbito da certificação da empresa em ISO 20000 todos os configuration itens de

um serviço deverão estar devidamente registados de acordo com a norma.

Todas estas razões levaram à necessidade de construir algo que facilite a gestão do catálogo e

requisições de equipamentos.

O objetivo deste estágio é então a criação de uma plataforma capaz de centralizar a gestão do

catálogo bem como os pedidos de requisição de material, que seja capaz de armazenar todos os

equipamentos no laboratório e que seja de fácil acesso e consulta a qualquer pessoa.

Requisitos

Os requisitos da plataforma estão divididos em três níveis de prioridade, sendo A requisitos

indispensáveis à plataforma, B requisitos que são importantes, mas dispensáveis, e 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.

50

Proposta

Dados os requisitos da solução, propõe-se então ao estagiário a criação da plataforma usando as

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.

Tarefas

Dada da natureza do projeto, que é um projeto inteiramente de desenvolvimento, foi decidido optar

por uma metodologia Agile. Desta forma foram então identificados os seguintes sprints com as

tarefas mencionadas na tabela abaixo.

Sprint Descrição Tarefas

1. Enquadramento e

contextualização com as

tecnologias

Pretende-se que o estagiário entre

em contacto com as tecnologias a

utilizar, nomeadamente com Python

e Django, com o objetivo de

aprender os conceitos chave e

funcionamento das tecnologias.

- Enquadramento e contextualização do

projeto

- Aprendizagem de tecnologias Python e

Django

- Aprendizagem de tecnologias de

controlo de versões Git

2. Construção da base da

plataforma web

Construção da primeira versão a

plataforma e que tenha as

funcionalidades essenciais já

implementadas.

Desenvolvimento das funcionalidades:

adição, visualização, consulta e edição

dos elementos do catálogo.

3. Optimização da base

da plataforma web

Optimização da base da plataforma.

Enquanto que a fase anterior

assentava na implementação das

funcionalidades básicas, o objetivo

desta fase é assegurar o correto

funcionamento dessas

funcionalidades uma vez que o

resultado desta fase será a base final

da plataforma.

- Optimização e correta implementação

da base de dados (tendo atenção aos

tipos das colunas e opções associadas,

tais como campos obrigatórios e valores

por defeito);

- Implementações de validações dos

campos no backend e notificações ao

utilizador.

- Optimização e validação de código.

4. Optimização da Desenvolvimento da interface web - Integração da plataforma com Bootstrap

51

Sprint Descrição Tarefas

interface (frontend) (frontend), de modo a torna-la user-

friendly e intuitiva.

(conjunto de classes, design e scripts para

frontend)

5. Desenvolvimento da

restante funcionalidade

Desenvolvimento das funcionalidades

relativas às requisições de material.

O correto funcionamento destas

novas funcionalidades e interface

user-friendly para esta

funcionalidade está igualmente

incluída nesta fase.

- Desenvolvimento e implementação das

funcionalidades de criação e visualização

de requisições, bem como criação e

visualização de devoluções.

6. Criação de mecanismos

de alertas

Notificações relativas a prazos de

devoluções expiradas devem ser

desenvolvidas nesta fase.

- Desenvolvimento e implementação de

notificações a requisições expiradas.

Cronograma

O presente projeto de estágio deverá seguir o seguinte cronograma:

A aceitação final deverá integrar os testes de aceitação. Durante o desenvolvimento da solução serão

efetuadas apresentações da mesma á equipa.

52

ANEXO AO PROTOCOLO

Orientador: Fábio Rafael Costa

Área Cientifica: Engenharia de software e sistemas de Informação/Telecomunicações

Inicio: 06-03-2017 Duração: 750 h

Estagiário (a): André Marcelino

Curso: TesP em Desenvolvimento de Aplicações Informáticas

53

Public Limited Company share capital: € 71 852 266 registered office: 58, boulevard Gouvion Saint-Cyr

75017 Paris - registration number: 702 012 956 RCS Paris.

54

Anexo 2 Representação da base de dados

55

Base de dados “Catalog” e tabelas existentes:

Tabela Software e atributos:

Representação da base de

dados “Catalog”

Tabela da base de dados, neste

caso tabela dos CPE

Tabela Software

Atributos do objeto CPE

Dados do equipamento com o

id AMLS001

56

Anexo 3 Funcionamento da SideBar

57

1) Clicar no botão “Hardware”

2) Resultado esperado: Mostrar lista de equipamentos do tipo Hardware:

58

3) Clicar no botão “Requisitions”:

4) Resultado esperado: Mostrar lista de requisições de equipamentos:

59

Anexo 4 Adicionar Equipamentos à base de

dados

60

1) Clicar no botão “Add”

2) Resultado esperado: Mostrar formulário de adicionar equipamentos do tipo

CPE, Hardware ou Software dependendo da escolha do utilizador:

61

3) Resultado esperado: Mostrar formulário de adicionar equipamentos do tipo

Hardware:

62

4) Resultado esperado: Mostrar formulário de adicionar equipamentos do tipo

Software

63

5) Preencher formulário e clicar no botão submit

64

6) Resultado esperado: Objeto adicionado com sucesso

65

Anexo 5 Ver detalhes dos equipamentos

66

1) Clicar no ID do equipamento

2) Resultado esperado: Mostrar detalhes do equipamento escolhido

67

Anexo 6 Editar equipamentos

68

1) Clicar no ID do equipamento que deseja editar

2) Clicar no botão “Edit”

69

3) Resultado esperado: Mostrar formulário de edição

70

4) Resultado esperado: Fazer as alterações necessárias

5) Resultado Esperado: Equipamento editado com sucesso

71

Anexo 7 Adicionar e ver detalhes de

requisições

72

1) Clicar no botão “Add”

2) Resultado esperado: Formulário de adicionar requisições

73

3) Preencher formulário e guardar nova requisição

4) Resultado esperado: Nova requisição adicionada

74

5) Ver detalhes da nova requisição adicionada

75

Anexo 8 Cancelar Requisição

76

1) Aceder aos detalhes do equipamento, clicar no botão “Cancel Requisition” e

confirmar

2) Resultado esperado: Estado da requisição passou de “Requested” para

“Canceled”

77

Anexo 9 Entregar equipamento requisitado

78

1) Aceder aos detalhes do equipamento e selecionar requisição com estado

“Requested”

2) Resultado esperado: Mostrar formulário “Deliver Form”

79

3) Preencher formulário e guardar dados

4) Resultado esperado: Estado da requisição passou de “Requested” para

“Delivered” e as restantes colunas dessa requisição estão preenchidas

80

5) Clicar no link do campo Aml_ID da requisição

6) Resultado esperado: Redirecionar utilizador para a página dos detalhes do

equipamento requisitado

81

Anexo 10 Devolução do equipamento

82

1) Aceder aos detalhes da requisição

2) Resultado esperado: Página de detalhes da requisição é demonstrada;

Clicar no botão “Deliver”;

83

3) Resultado esperado: Estado da requisição passou de “Delivered” para

“Returned”

4) Aceder novamente aos detalhes da requisição e verificar se foi acrescentado um

novo dado preenchido com a data do dia de retorno do equipamento denominado

de “Return Date”

84

5) Aceder aos detalhes do equipamento através do “Aml_ID” e verificar se o estado

passou de “Delivered” para “Stock”