Tp:;bdigital.ipg.pt/dspace/bitstream/10314/4224/1/André Baptista_10120… · Tp:; 1 dalGuarda...
Transcript of Tp:;bdigital.ipg.pt/dspace/bitstream/10314/4224/1/André Baptista_10120… · Tp:; 1 dalGuarda...
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”