Desenvolvimento de plataforma para gestão integrada de calçado para pé diabético

Faculdade de Engenharia da Universidade do Porto

Desenvolvimento de

Integrada de Calçado para Pé D

Pedro Emanuel de Castro Meneses

Mestrado Integrado em Engenharia Electrotécnica e de Com

Orientador:

Co-orientador:

Faculdade de Engenharia da Universidade do Porto

Desenvolvimento de Plataforma para Gestão

Integrada de Calçado para Pé Diabético

Pedro Emanuel de Castro Meneses

Dissertação realizada no âmbito do

Mestrado Integrado em Engenharia Electrotécnica e de Com

Major Automação

Orientador: Américo Lopes de Azevedo (Professor Doutor

orientador: Paulo Ferreira dos Santos (Doutor)

Junho de 2012

Faculdade de Engenharia da Universidade do Porto

Plataforma para Gestão

iabético

Mestrado Integrado em Engenharia Electrotécnica e de Computadores

Américo Lopes de Azevedo (Professor Doutor)

Paulo Ferreira dos Santos (Doutor)

ii

iii

Resumo

Cada vez mais os avanços tecnológicos têm sido um potencial aliado na evolução dos métodos de diagnóstico e tratamento no sistema de saúde. A tecnologia só tem utilidade se for de encontro às necessidades dos seus clientes e resolver problemas que os humanos não têm capacidade de resolver autonomamente. Esta dissertação centra-se na construção de uma plataforma WEB com capacidade para combater os problemas de comunicação e diagnóstico no processo de prescrição de calçado para pé diabético.

O trabalho apresentado neste documento foi desenvolvido no contexto de um projeto europeu – projeto CORENET (Customer-ORiented and Eco-friendly NETworks for healthy fashionable goods) que visa essencialmente, desenvolver métodos, ferramentas e tecnologias para produção de pequenas séries de produtos ou serviços e divide-se em quatro grandes fases:

• Análise de requisitos funcionais e não funcionais; • Definição das funcionalidades a implementar; • Desenvolvimento e implementação da plataforma; • Testes e validação.

Esta plataforma pretende interligar os vários intervenientes na encomenda de calçado para pé diabético de forma a reduzir tempos, despesas, erros e aumentar a satisfação dos clientes deste tipo de calçado.

Esta plataforma deverá ser capaz de oferecer as diferentes funcionalidades necessárias a cada tipo de utilizador sem que isso implique maior complexidade na forma como operam e interagem. Facilitar a comunicação durante todo o processo é outro dos grandes objetivos que se pretendem alcançar com este projeto.

Por se tratar de um trabalho integrado num projeto europeu tornou-se necessária a produção de documentação que permitisse enquadrar o trabalho que estava a ser desenvolvido com o projeto. Esta documentação será anexada ao relatório e mencionada sempre que se justificar.

No fim deste projeto pretende-se que esta plataforma sirva de ponto de partida para apoiar os médicos e técnicos na prescrição de calçado para pacientes que sofrem de pé diabético.

v

Abstract

Increasingly, technological advances have been a potential ally in the development of diagnostic methods and treatment in the health system. The technology is only useful if it to meets the needs of their customers and solve problems that humans are unable to resolve independently. This dissertation focuses on building a web platform with the capacity to tackle the problems of communication in the process of diagnosis and prescription footwear for diabetic foot.

The work presented herein was developed in the context of a European project - project CoreNet (Customer-Oriented and Eco-friendly healthy Networks for fashionable goods) which aims primarily to develop methods, tools and technologies for production of small series of products or services and it is divide into four phases:

• Analysis of functional and nonfunctional requirements; • Definition of features to implement;

• Development and implementation of the platform; • Testing and validation.

This platform aims to link the various stakeholders in order to reduce time, costs, errors and increase customer satisfaction in this type of footwear.

This platform should be able to offer different functionalities required by each type of user can do this without more complexity in how they operate and interact. Facilitate a communication throughout the process is another major goal that it is necessary achieve with this project.

Because it is an integrated work in a European project has become necessary to produce documentation that would allow frame the work that was being developed with the project. This documentation shall be attached to the report and referred to where appropriate.

At the end of this project is intended that this platform will serve as a starting point to support doctors and technicians in the prescription of footwear for patients suffering from diabetic foot.

vii

Agradecimentos

Esta secção do relatório reservei aos verdadeiros profissionais que me apoiaram e orientaram todo este trabalho. De entre os inúmeros profissionais que trabalharam comigo neste projeto, identifico três que merecem um agradecimento individual:

• Ao professor Américo Azevedo pela orientação do trabalho. Sempre se revelou muito mais que um orientador. Preocupou-se com muito mais do que uma simples orientação de um trabalho e nestes seis meses fez-me crescer a nível profissional possibilitando-me experiências profissionais que não teria a sorte de as ter se não fosse pelo seu profissionalismo;

• Ao professor João Bastos pela incansável disponibilidade. Apesar de não ter qualquer tipo de obrigação neste trabalho, foi uma das peças fundamentais na concretização deste projeto. Foi com a sua ajuda que me integrei no projeto CoReNet e com quem aprendi muito acerca daquilo que tinha que fazer nas reuniões em que participei;

• Ao Eng. Paulo Santos pela co-orientação do trabalho e pelas experiências que me proporcionou. Demonstrou uma constante preocupação com o trabalho que estava a desenvolver e foi-me oferecendo um conjunto de caminhos que poderia percorrer. Sem nunca me dizer como fazer, integrou-me numa equipa de trabalho e proporcionou-me um verdadeiro ambiente empresarial para desenvolver o meu trabalho.

A estes três profissionais, o meu obrigado pelo profissionalismo que demonstraram e a incansável ajuda que me dispensaram. Sem dúvida que me fizeram crescer como profissional possibilitando-me a integração no mundo do trabalho e seguindo de perto as minhas ações.

ix

Índice

Resumo ... iii

Abstract ... v

Agradecimentos ... vii

Índice ... ix

Lista de figuras ... xi

Lista de tabelas ... xiii

Abreviaturas e Símbolos ... xiv

Capítulo 1 ... 1

Capítulo 2 ... 7

2.3 -Método de Diagnóstico do Pé Diabético ... 10

2.4 -Objetivos da Plataforma Tecnológica ... 10

Capítulo 3 ... 13

Especificação da infraestrutura de Informação ... 13

3.1 -Modelo AS-IS ... 13

3.2 -Requisitos do Processo de Prescrição ... 15

3.3 -Arquitetura do Sistema ... 17

3.4 -Análise e Conceção ... 19

3.5 -Casos de Uso da Plataforma ... 22

Capítulo 4 ... 27

Desenvolvimento e Implementação da Solução ... 27

x 4.4.1 - Módulo “Processo” ... 34 4.4.2 - Módulo “Upload” ... 35 4.4.3 - Módulo “Catálogo” ... 37 4.4.4 - Módulo “Características” ... 37 4.4.5 - Módulo “Diálogo” ... 38 4.4.6 - Módulo “Comunicação” ... 40 4.4.7 - Módulo “Administração” ... 42 4.5 -Modelo TO-BE ... 42

Capítulo 5 ... 45

Conclusões e Trabalho Futuro ... 45

5.1 -Validação da solução ... 45

5.2 -Conclusões ... 46

5.3 -Trabalho Futuro ... 47

Anexo A ... 49

Gestão do Projeto ... 49

A.1 -Diagrama de Gantt ... 50

A.2 -Tarefas do diagrama de Gantt... 51

Anexo B ... 53

Requisitos do Sistema de Informação ... 53

B.1 -Entrevista ao Podologista – Hospital de Santo António (25/10/2011) ... 53

B.2 -Protótipo em PowerPoint ... 55

B.3 -Lista de Requisitos ... 58

Anexo C ... 61

Arquitetura do Sistema de Informação ... 61

C.1 -Modelo Entidade – Associação ... 61

C.2 -Modelo Relacional ... 62

Anexo D ... 65

Validação da Solução ... 65

D.1 -Apresentação da ICE Conference ... 65

xi

Lista de figuras

Figura 1.1 – Abordagem do CORENET para pequenas séries de roupas e sapatos na área da

saúde [Seventh Framework Programme, 2010] ... 3

Figura 2.1 – Arquitetura da Plataforma ... 11

Figura 3.1 – Fluxograma representativo do processo de prescrição de calçado para pé diabético ... 14

Figura 3.2 – Arquitetura funcional da plataforma de apoio à prescrição de calçado para pé diabético ... 18

Figura 3.3 – Interface Podologista – Sistema ... 19

Figura 3.4 – Interface Técnico – Sistema ... 20

Figura 3.5 – Interface Administrador – Sistema ... 21

Figura 3.6 – Esquematização das funções desempenhadas pelo bloco de processamento ... 22

Figura 3.7 – Diagrama de casos de uso para a plataforma ... 23

Figura 3.8 – Diagrama do caso de uso “Submeter Processo” ... 24

Figura 3.9 – Diagrama do caso de uso “Carregar Ficheiros” ... 24

Figura 3.10 – Implementação – Caso de Uso ... 25

Figura 4.1 – Arquitetura da base de dados sobre a forma Entidade-Associação ... 30

Figura 4.2 – Constituição do sistema WalkinSense ... 31

Figura 4.3 – Instalação do dispositivo e características [Tomorrow, 2012] ... 32

Figura 4.4 – Interface que permite analisar a evolução da pressão plantar do pé do paciente... 33

Figura 4.5 – Módulo “Processo” da infraestrutura de informação ... 35

Figura 4.6 – Módulo “Upload” da infraestrutura de informação ... 35

Figura 4.7 – Sistema de pastas da infraestrutura de informação ... 36

xii

Figura 4.11 – Caixa de diálogo para submissão do processo para o fabricante ... 39

Figura 4.12 – Ficheiro XML enviado para o fabricante com a lista dos processos submetidos ... 40

Figura 4.13 – Ficheiro XML enviado para o fabricante com os dados do processo ... 41

Figura 4.14 – Módulo “Administração” da infraestrutura de informação ... 42

Figura A.1 – Diagrama de Gantt com as macro tarefas ... 50

Figura B.1 – Interface do Podologista onde poderá fazer login ... 56

Figura B.2 – Interface do Podologista onde terá acesso à área de diagnóstico do paciente ... 56

xiii

Lista de tabelas

Tabela 1 - Incidência e custo, úlceras e amputações para problemas relacionados com diabetes nos USA [Saleh, 2005] ... 9 Tabela A.1 – Tabela com todas as tarefas retiradas do diagrama de Gantt ... 51 Tabela B.1 - Lista de requisitos do sistema ... 58

xiv AJAX Asynchronous JavaScript and XML BD Base de Dados

CORENET Customer-ORiented and Eco-friendly NETworks for healthy fashionable goods CSS Cascading style sheets

CSV Comma Separated Values

FEUP Faculdade de Engenharia da Universidade do Porto HTML HyperText Markup Language

IEEE Institute of Electrical and Electronics Engineers INESC Instituto de Engenharia de Sistemas e Computadores ISO International Organization for Standardization NICE National Institute for Health and Clinical Excellence PDF Portable Document Format

PHP Hypertext Preprocessor SQL Structured Query Language S.I. Sistema de Informação UE União Europeia

UKTI United Kingdom Trade and Investment USB Universal Serial Bus

WEB World Wide Web

Capítulo 1

Introdução

Este documento descreve o trabalho desenvolvido no contexto da unidade curricular “Dissertação” do Mestrado Integrado em Engenharia Eletrotécnica e de Computadores na Faculdade de Engenharia da Universidade do Porto.

Neste capítulo faz-se o enquadramento do trabalho explicando o contexto em que se desenvolveu, são apresentados os objetivos do trabalho assim como a motivação que levou ao seu desenvolvimento e apresenta-se a estrutura deste relatório justificando as opções tomadas.

1.1 - Enquadramento

Este projeto foi desenvolvido em ambiente empresarial1 _{no âmbito de um projeto} europeu2

envolvendo diversas instituições de I&D e empresas industriais de diversos países. O objetivo deste projeto é responder às necessidades e expectativas de um conjunto de consumidores específicos, tais como obesos, diabéticos e pessoas que necessitem de cuidados especiais na elaboração da sua roupa e calçado. Atualmente, os consumidores com este tipo de necessidades especiais são confrontados com uma gama de escolhas muito reduzida fazendo com que tenham de usar coisas que não gostam em detrimento do seu estado de saúde. Para possibilitar uma maior escolha aos consumidores e ao mesmo tempo flexibilizar o processo de encomenda e produção de roupa e calçado com características especiais, é imperial o uso das novas tecnologias e formas de comunicação que agora estão ao dispor da sociedade.

Este trabalho centra-se essencialmente na produção de calçado para pé diabético e na construção de uma plataforma tecnológica que interligue os três intervenientes neste processo: o paciente, o médico e o técnico da indústria onde será desenvolvido o calçado.

1

Tomorrow Options S.A

2

É importante realçar que a evolução do estado de saúde de um paciente com pé diabético depende fortemente da rapidez e da eficácia com que é tratado. Tendo em conta alguns dados da Federação Internacional de Diabetes [IDF, 2005], este é um problema grave de saúde pública onde se tem gasto avultadas quantias de dinheiro em amputações e consultas que podiam ser evitadas. Para isso, é necessária uma ferramenta com capacidade para uma rápida e correta troca de informação entre podologistas e técnicos de saúde.

Uma vez que se trata de um projeto com uma abrangência europeia levanta-se um problema adicional: o processo de encomenda deste tipo de calçado é feito de maneira diferente entre os vários países (Portugal e Inglaterra, por exemplo). A solução a encontrar deverá satisfazer ambos os processos.

1.2 - Projeto CoReNet

Como já foi referido anteriormente, os principais objetivos do corenet passam por atender um conjunto de necessidades de um grupo de cidadãos muito específico, cumprindo os graus de exigência na qualidade, preço acessível e compatibilidade ambiental.

Particularmente, o corenet irá incidir sobre os obesos, diabéticos e pessoas com deficiência através de:

• Sapatos personalizados e confortáveis (com redução das costuras, materiais biológicos, flexíveis e componentes leves, por exemplo);

• Roupas personalizadas e confortáveis (tamanhos especiais, funcionalidades especiais e bio têxteis para problemas de pele, por exemplo);

Pretende-se que o corenet:

• Obtenha e faça a gestão dos dados do consumidor para conhecer as suas necessidades;

• Envolva o consumidor na fase de design e configuração do produto; • Faça a gestão dos fornecedores de forma a planear e distribuir o tempo;

• Desenvolva máquinas de fabrico inovadoras, em particular para impressão digital e gravação a laser;

• Entregue o produto ao consumidor final;

• Monitorize a qualidade e sustentabilidade dos produtos.

Muitas pequenas séries de mercado estão a emergir principalmente devido às mudanças na sociedade e às expectativas e necessidades dos consumidores. O projeto corenet vai tratar especificamente do setor da saúde. É cada vez mais importante satisfazer as necessidades desse tipo de consumidores, não só a níveis estéticos, mas também em termos de bem-estar, saúde e funcionalidades especiais dos produtos.

Os objetivos do corenet passam por fechar esta lacuna do mercado atual criando uma solução sustentável baseada no custo e no design, desenvolvendo produtos personalizados capazes de satisfazerem os seus clientes, tendo em conta a sua saúde e o seu desejo nos produtos da moda.

1.3 - Motivação e Objetivos 3

Figura 1.1 – Abordagem do CORENET para pequenas séries de roupas e sapatos na área da saúde [Seventh Framework Programme, 2010]

1.3 - Motivação e Objetivos

Com a evolução da competição a nível industrial que se tem verificado nos últimos anos, as empresas têm tido a necessidade de se adaptarem aos novos paradigmas do mercado global para poderem resistir a uma economia de escala em crescente evolução.

Cada vez mais as grandes empresas apostam na produção em grande escala, fazendo com que as pequenas empresas desapareçam ou tenham que se adaptar a uma realidade diferente optando por uma nova estratégia de negócio.

A produção de pequenas séries de produtos complexos e muito personalizados para cada cliente torna-se uma área de negócio cada vez mais importante, principalmente para as pequenas e médias empresas (PMEs) que não têm capacidade de produção em massa [Azevedo et al., 2011].

Este tipo de estratégia revela-se particularmente relevante na produção de bens para a saúde, onde cada produto tem que ser totalmente adaptado a cada cliente.

Inerente a esta necessidade de adaptação por parte de algumas pequenas empresas, existe também a necessidade de uma plataforma que permita sincronizar as diferentes fases do processo de prescrição de calçado para pé diabético. Fazendo uma pequena pesquisa nesta área, facilmente se conclui que a produção de calçado para pacientes de pé diabético é bastante diferente da produção de calçado tradicional.

Isto ocorre porque cada sapato tem de ser completamente adaptado ao paciente e em conformidade com um conjunto de requisitos prescritos pelo podologista. Esta circunstância

levanta um conjunto de constrangimentos na forma como o fabricante de calçado tem que lidar com a procura do cliente, como recebe a informação do podologista e como avalia essa informação. Vários estudos têm revelado alguns problemas críticos na forma como flui o processo e na forma como o estado do paciente é avaliado.

Neste sentido, é de grande importância desenvolver uma plataforma que facilite a comunicação e troca de informação entre o podologista e a indústria que faz a produção de calçado especializado.

Os principais objetivos definidos no contexto do projeto de dissertação foram:

• Identificação e caracterização do problema – procurou-se analisar, descrever e caracterizar o fluxo de informação que existe no processo tal e qual como é executado atualmente;

• Desenvolvimento e construção da arquitetura do sistema - conceber uma solução para o problema recorrendo às tecnologias que melhor se adaptem à situação em análise;

• Elaboração de um protótipo - Desenvolver uma plataforma web de acordo com a arquitetura especificada e que cumpra os requisitos do cliente.

Este conjunto de três grandes objetivos, conjuntamente com as restrições temporais associadas ao projeto permitiram representar as atividades a desenvolver ao longo do período de duração do projeto utilizando um diagrama de Gantt (Anexo A.1). Esse diagrama acompanhou todo o projeto e foi atualizado sempre que necessário.

No anexo A.1 encontra-se o diagrama de Gantt com as metas temporais associadas às macro tarefas do projeto. As tarefas podem ser consultadas no anexo A.2 onde está representada uma tabela com todos os objetivos juntamento com as suas metas temporais.

Naturalmente, os objetivos descritos anteriormente, foram detalhados e divididos em pequenos objetivos com metas temporais bem definidas de forma a estruturar o trabalho e cumprir todos os objetivos em tempo útil.

1.4 - Resultados Esperados

Uma vez que se trata de um trabalho realizado em ambiente empresarial, espera-se desenvolver uma solução que seja útil para a empresa e que seja responsável por alertar para a gravidade do problema do processo de prescrição de calçado para pé diabético.

Como se trata de um sistema de engenharia, espera-se completar todas as fases do processo no desenvolvimento de uma solução. Mais importante que a solução final será abranger todas as fases do seu desenvolvimento para facilitar e permitir uma futura discussão para melhoramentos a implementar na solução tecnológica.

Espera-se desenvolver um protótipo com capacidade para interligar todos os intervenientes do processo e facilitar a comunicação entre eles. Deverá ser um protótipo totalmente funcional e pronto a ser instalado num servidor para avaliar o seu funcionamento e o seu desempenho no cumprimento das suas funcionalidades junto dos seus utilizadores.

Erro! A origem da referência não foi encontrada.Erro! A origem da referência não foi

encontrada. 5

1.5 - Estrutura do Documento

O planeamento do trabalho é uma das fases mais importantes num sistema de engenharia. Neste projeto adotou-se uma abordagem típica na engenharia de sistemas recorrendo aos referenciais normativos, como por exemplo, a IEEE std 1220-2005.

O relatório foi estruturado da mesma forma que se desenvolveu o trabalho e seguindo os referenciais normativos referidos anteriormente. Facilmente se identificam quatro grandes fases do projeto e essas fases dão origem a quatro dos cinco capítulos deste relatório:

• Caracterização do problema – Todos os projetos em engenharia são desenvolvidos com o intuito de satisfazer uma necessidade de um cliente. É essencial perceber bem essa necessidade para que o resultado final vá de encontro à satisfação do cliente. Por isso, uma primeira etapa é perceber e descrever essa necessidade para que posteriormente se compreendam quais os atores envolvidos e as diferentes etapas pelas quais o processo deve passar; • Proposta de solução – Depois de identificar a necessidade do cliente é necessário

compreender o problema, especificar os requisitos para a solução e desenvolver uma arquitetura que cumpra os objetivos do projeto;

• Desenvolvimento da solução – Esta fase corresponde à parte técnica do trabalho. Mesmo antes de passar à programação e desenvolvimento da solução é necessário fazer uma pesquisa sobre as tecnologias disponíveis e escolher as mais adequadas ao projeto. Escolher e construir a base de dados necessária ao projeto e construir a plataforma com base nas especificações dos diferentes intervenientes no processo;

• Integração e validação – Como já se referiu anteriormente, esta plataforma foi desenvolvida no contexto de um projeto com vários parceiros. Como é natural, deverá ser capaz de se integrar com outras plataformas e trocarem dados entre si. Os testes de validação são também uma importante fase do projeto. Não é suficiente a plataforma trabalhar corretamente, é preciso que vá de encontro às necessidades do cliente e esteja de acordo com aquilo que especificou.

No primeiro capítulo é feito um enquadramento do projeto e são definidos um conjunto de objetivos que se esperam alcançar no fim do projeto.

O segundo capítulo deste documento consiste essencialmente na identificação do problema de forma a entender as necessidades do cliente. Inclui alguns conteúdos associados à primeira fase do projeto.

O terceiro capítulo resume-se à especificação da infraestrutura de informação. De uma forma geral pode ser associada ao conjunto da primeira e segunda fase do projeto. Neste capítulo é feito o levantamento de requisitos e é definida uma arquitetura para a plataforma. No quarto capítulo descreve-se a forma como a solução foi desenvolvida. Incide principalmente na quarta fase do projeto descrita anteriormente.

Por fim, no último capítulo, para além de algumas conclusões e perspetivas de trabalho futuro relativas ao projeto é descrita a forma como foi feita a validação da solução. Naturalmente, este capítulo integra a última fase do projeto.

Capítulo 2

Caracterização do Problema

Antes de se desenvolver um projeto de engenharia é importante contextualizar o problema de forma a entender as necessidades dos clientes. A melhor forma de perceber a necessidade de um cliente é fazer com que o engenheiro sinta a mesma necessidade. Nesse sentido, neste capítulo faz-se uma introdução ao problema de forma a contextualizar os aspetos mais importantes e identificar os principais problemas que o cliente quer ver resolvidos.

2.1 -

Relevância Industrial

A indústria têxtil, não está adequada a lidar com pequenos grupos de consumidores com características especiais, por isso, deve ser adequada para ter capacidade de responder a estas necessidades. Uma vez que se trata de um pequeno grupo de consumidores, não faz sentido usar o mesmo tipo de negócio que se usa atualmente na indústria têxtil, onde são desenvolvidos produtos a velocidades espantosas e são colocados no mercado em quantidades gigantescas (produção para stock) esperando que o consumidor compre aquilo que foi produzido. Para este novo tipo de mercado, a produção tem que ser feita em função da procura e com produtos totalmente orientados ao cliente, uma vez que cada produto tem características muito próprias. Reconstruir um novo modelo de produção que seja capaz de suportar este conjunto de características envolve muita tecnologia e integração de várias empresas o que significa maior planeamento e coordenação entre os vários atores envolvidos. Atualmente, no setor têxtil, os fabricantes estão totalmente integrados numa rede de produção que começa na indústria química com produção de fibras e termina com os produtos acabados. No setor do calçado, a abordagem é muito semelhante onde as indústrias que montam os componentes (sapatos e acessórios) estão interligados com fornecedores de matéria-prima e componentes semiacabados. Os fornecedores de tecnologia estão a ganhar mais importância na indústria do calçado porque ao lado dos produtores de máquinas e aplicações de informação e comunicação, novos serviços devem ser prestados às indústrias de produção.

Desta forma, facilmente se conclui que a estrutura da rede neste tipo de indústrias não se restringe às indústrias de produção. Estão incluídos também, os fornecedores, as indústrias prestadoras de serviços (centros de design, logística e os inspetores de qualidade, por exemplo). Assim sendo, a melhoria da produtividade, flexibilidade e qualidade numa empresa vai ter influência na competitividade de toda a rede.

Cada organização deve funcionar como um único componente inteligente de um sistema complexo onde cada unidade colabora em direção às metas e objetivos comuns, começando com a identificação das características dos produtos que vão de encontro às necessidades dos consumidores, permitindo que o cliente esteja envolvido no processo de produção tornando-o mais eficiente e eficaz.

À medida que o setor da indústria têxtil e calçado é globalizado, torna-se evidente a competitividade entre os diferentes países fazendo com que locais com mão-de-obra mais barata se tornem nos que representam maior volume de vendas. Isto obrigou a UE a reestruturar a sua estratégia adicionando mais valor aos seus produtos de forma a atingirem novos nichos de mercado.

O desempenho global desta indústria tem sido fortemente afetado pela globalização e pelos países cujas condições de trabalho são menos regularizadas, mas há um grupo de consumidores que está disposto a comprar não apenas produtos baratos mas que ofereçam alto desempenho e conforto: Pacientes com problemas de saúde e que precisam de roupas e calçados especiais. Cada vez mais as empresas precisam de desenvolver estratégias de inovação baseadas em criatividade, qualidade e diferenciação dos seus produtos. Por isso, pequenas séries de produtos altamente especializados para um grupo de consumidores com características muito especiais, representa uma boa oportunidade de negócio. [Magaletti et al., 2010]

2.2 -

Relevância do Pé diabético

O pé diabético é uma doença causada pelos níveis elevados de glicose no sangue (diabetes). Esses níveis elevados de glicose dificultam a circulação sanguínea resultando num menor fornecimento de sangue aos pés. Como consequência deste défice de sangue nos pés, os tecidos nervosos sofrem danos reduzindo a capacidade de sentir dor e a cicatrização das feridas. Os pacientes de pé diabético não sentem qualquer tipo de dor ou qualquer tipo de úlcera que se possa estar a formar no pé. Nos casos mais graves, estas lesões podem levar a amputações [IDF, 2005].

Infelizmente, estes casos não são tão raros como inicialmente se pode pensar e trata-se de um problema grave de saúde pública. De acordo com a Federação internacional de Diabetes [IDF, 2005]:

• Em todo o mundo, cerca de 70% das amputações de pernas acontecem a pessoas com diabetes;

• Algures no mundo, uma perna perde-se a cada trinta segundos devido a diabetes; • Estima-se que cerca de 85% das amputações que acontecem devido a diabetes

podiam ser evitadas;

• Cerca de 85% das amputações de membros inferiores relacionadas com diabetes são precedidas de úlceras;

2.2 -Relevância do Pé diabético 9

• A maior parte das úlceras nos pés podem ser prevenidas apenas com cuidados de saúde adequados;

• Nos países desenvolvidos, uma em cada seis pessoas com diabetes terá uma úlcera durante a sua vida.

• Nos países desenvolvidos, estima-se que cerca 15% dos recursos de saúde sejam necessários para tratar os problemas de pé diabético. Este valor ascende aos 40% quando se trata dos países em desenvolvimento.

Se a estes factos se acrescentar dados relativos a incidências e custos para problemas relacionados com diabetes nos USA (tabela 1), rapidamente se conclui que afinal o problema de pé diabético trata-se de um problema de saúde pública e que pode ser combatido precocemente reduzindo custos e vidas humanas.

Tabela 1 - Incidência e custo, úlceras e amputações para problemas relacionados com diabetes nos USA [Saleh, 2005]

Incidências e Custos

Número de pacientes diabéticos 12 milhões (5%) Número de pacientes diabéticos com problemas nos pés

relacionados com a doença 3 milhões Número de novos casos de diabetes 600 mil/ano Custo hospitalar do diabético para infeções do pé

diabético $200 milhões/ano Tempo médio de permanência no hospital 22 semanas Custo por hospitalização $6.600 Custo por amputação $800-$12.000

Admissão devido a problemas nos pés 20% de todas as admissões de diabéticos

Úlceras e Amputações

Pacientes com média de 3 anos de vida após amputação de membros inferiores 50% Redução de amputações devido a cuidados médicos e

educação do paciente 50% Redução de amputações devido à melhoria do cuidado

com o pé 50%

Amputações de pacientes internados com úlceras

2.3 -

Método de Diagnóstico do Pé Diabético

Pela secção anterior, facilmente se conclui que as úlceras nos pés deste tipo de pacientes representam um elevado custo de tratamento e um efeito que pode levar à amputação, nos casos mais graves. Neste sentido, a prevenção das úlceras representa a forma mais económica e eficaz no combate a esta doença. Quando são detetadas anomalias, o tratamento do pé diabético geralmente envolve o uso de calçado apropriado, palmilhas de proteção, cirurgia e terapia física [Pedeboy et al., 2012].

Atualmente, a maioria das avaliações clínicas dos pacientes com pé diabético baseiam-se apenas na observação visual e experiência do podologista. Desta forma os problemas só são detetados quando já são visíveis, como por exemplo a alteração da cor da pele, a formação de um calo ou até mesmo a existência de uma úlcera, o que muitas vezes é tarde demais. De acordo com um estudo realizado por Guldemond [Guldemond et al., 2006], a identificação da elevada pressão plantar através da avaliação clínica é difícil, insuficiente e pode ser potencialmente prejudicial. Gouldemond vai ainda mais longe ao afirmar que o processo de triagem clínica usado atualmente tem que ser repensado de forma a incluir uma avaliação quantitativa da pressão plantar para uma identificação com maior precisão dos locais com elevada pressão plantar.

A solução para um paciente que sofre de uma má distribuição da pressão plantar passa pela prescrição de calçado personalizado de forma a redistribuir a pressão pelo pé. No entanto, a prescrição de um calçado com características inadequadas ao paciente pode revelar-se um potencial aliado para a formação de novas úlceras. Normalmente, após uma prescrição, a evolução do pé do paciente é avaliada pelo podologista através de um conjunto de consultas periódicas. Mas, mais uma vez, esta avaliação baseia-se apenas na observação visual do pé, o que pode levar a um aumento dos riscos, custos e tempo gasto pelos podologistas.

2.4 -

Objetivos da Plataforma Tecnológica

Para um tratamento mais eficaz dos pacientes de pé diabético é necessário atingir níveis mais elevados de colaboração entre os prestadores de serviços de saúde e os fabricantes de calçado através de um novo conjunto de ferramentas, produtos e serviços, principalmente na área das tecnologias da informação.

Uma melhor interação e comunicação entre estes dois universos (indústria de calçado e serviços de saúde) traria vantagens para todos os intervenientes:

• Do ponto de vista da indústria do calçado, haveria um maior número de vendas. Abordando uma estratégia diferente, algumas empresas podem apostar na criação de valor no produto que vendem e apostar no aspeto exterior dos sapatos, uma vez que, atualmente, pouco ou nada é investido na área do design. Ao proporcionar produtos medicamente funcionais com características modernas vão proporcionar conforto e bem-estar aos seus clientes;

• Do ponto de vista do paciente, veria o seu problema resolvido mais rapidamente, sem ter que recorrer à amputação e teria um maior número de opções na altura de escolher o aspeto exterior do seu sapato (atualmente os catálogos oferecem

2.4 -Objetivos da Plataforma Tecnológica 11

um reduzido número de opções) permitindo usar o que gosta mesmo tendo problemas nos pés;

• Do ponto de vista do podologista ou o técnico de saúde, aumentaria a sua eficiência reduzindo o tempo de consulta com os pacientes e obteria um menor número de amputações nos seus pacientes.

A plataforma deve ser capaz de facilitar a interação entre os intervenientes do processo, permitindo uma rápida conclusão do processo e respetiva instalação do sapato no paciente. Simultaneamente, facilitando a comunicação entre o podologista e o fabricante será possível reduzir erros e custos na prescrição do sapato (figura 2.1).

Figura 2.1 – Arquitetura da Plataforma

Um dos parceiros do projeto3

desenvolveu um dispositivo eletrónico4

com capacidade para adquirir dados qualitativos e quantitativos relativamente à distribuição da pressão plantar. Este dispositivo representa um componente vital na plataforma que se descreve neste documento. Através deste dispositivo será possível visualizar informação quantitativa do estado do paciente e trocar essa informação entre podologistas ou técnicos usando esta plataforma. Desta forma, será possível avaliar quantitativamente o estado do paciente antes e depois da instalação dos sapatos e analisar se estão a provocar o resultado esperado ou se precisam de adaptações. Assim, reduzem-se os riscos de ocorrerem novas úlceras devido a uma má análise do estado do paciente e simplificam-se as comunicações entre o fabricante e o podologista ou técnico de saúde.

3

Tomorrow Options S.A

4

Capítulo 3

Especificação da infraestrutura de

Informação

De acordo com os referenciais normativos IEEE std 1220-2005, este capítulo representa a segunda fase do sistema de engenharia. É uma das fases mais importantes de todo o processo porque a solução a desenvolver dependerá fortemente da interpretação que é dada aquilo que o cliente enuncia.

Nesta fase é essencial compreender o processo tal e qual como é executado atualmente e interpretar aquilo que os vários intervenientes desejam como solução.

A forma como este projeto se desenvolve encaixa perfeitamente num modelo de desenvolvimento interativo e incremental. Consiste num desenvolvimento incremental com sete fases: planeamento, requisitos, análise e design, implementação, desenvolvimento, teste e avaliação. Todas as sete fases são repetidas sequencialmente ao longo do desenvolvimento do projeto [IEEE std 1220-2005]. Desta forma, é feita uma constante avaliação e validação do projeto, aproximando a solução daquela que será entregue ao cliente. Assim, torna possível envolver o cliente ao longo de todo o desenvolvimento do projeto.

3.1 -

Modelo AS-IS

Atualmente, o processo de prescrição de calçado para pé diabético é centralizado na interação entre o paciente e o podologista (ou outra entidade de saúde semelhante), com algumas variações entre países e os seus respetivos sistemas de saúde. De uma forma sumarizada, o processo pode ser descrito pelas seguintes fases:

1. O podologista observa o paciente e decide se precisa de sapatos especiais;

2. Normalmente, o podologista prescreve uma palmilha personalizada para ser inserida no sapato do paciente. Geralmente esta palmilha é fabricada pelo próprio podologista ou então por um técnico especializado;

3. O podologista indica um conjunto de fabricantes deste tipo de calçado ao paciente e ele próprio desloca-se ao fabricante;

4. No fabricante, um técnico especializado faz um conjunto de medições para determinar os valores de um conjunto de características que se podem alterar num sapato;

5. É disponibilizado ao paciente um catálogo em papel com sapatos adequados ao seu estado de saúde, deixando o paciente apenas preocupar-se com o aspeto estético. 6. É dada ordem de produção dos respetivos sapatos;

7. O sapato e a palmilha são enviados para o podologista que testa no seu paciente e vê se são necessários alguns ajustes. Caso sejam necessárias algumas alterações, os sapatos são enviados novamente para o fabricante, a não ser que as alterações sejam passíveis de ser efetuadas pelo próprio podologista;

8. Após a instalação do sapato e da palmilha no pé do paciente, são feitas algumas consultas periódicas para avaliar a evolução do estado clinico do paciente e fazer pequenas correções caso sejam necessárias.

Na figura 3.1 pode ver-se o fluxograma que representa o processo de prescrição de calçado para pé diabético com os respetivos atores associados a cada atividade.

3.2 -Requisitos do Processo de Prescrição 15

3.2 -

Requisitos do Processo de Prescrição

O levantamento de requisitos é a fase mais importante da especificação do S.I.

Existe uma necessidade por parte do consumidor e é essa necessidade que leva a uma ideia de negócio e potencialmente à construção de um sistema de informação. Esta deve ser a ideia essencial que deve acompanhar toda a evolução e construção do software: o S.I. é desenvolvido com o intuito de satisfazer uma necessidade e essa necessidade deve ser compreendida corretamente para que o sistema de informação cumpra o seu objetivo.

Mais uma vez, o recurso às normas militares revela-se um excelente ponto de partida para se fazer um correto levantamento dos requisitos, mais concretamente a norma IEEE Std 830-1998. Esta norma é uma revisão da IEEE Std 830-1993 que recomenda um conjunto de boas práticas para um correta especificação de requisitos para o desenvolvimento de software de qualidade capaz de satisfazer a necessidade do cliente.

Segundo esta mesma norma existem cinco questões essenciais que um correto levantamento de requisitos deve abranger [IEEE std 830-1993]:

a) Funcionalidade: o que é suposto o software fazer?

b) Interfaces externas: Como é que o software interage com as pessoas, com outro software ou com hardware?

c) Desempenho: Qual a velocidade, disponibilidade, tempo de resposta, etc? d) Atributos: Existem aspetos importante a ter em conta relacionados com a

manutenção, segurança, conectividade, etc?

e) Restrições de design impostas na implementação: Existem restrições a nível da linguagem usada no desenvolvimento, políticas de integridade de bases de dados, ambientes operacionais, etc?

Como facilmente se conclui pelos tópicos anteriores, o levantamento de requisitos envolve muitos mais intervenientes do que simplesmente o cliente. Muitas vezes, a pessoa que requer o sistema de informação não é quem o vai utilizar, logo, tem uma determinada visão sobre aquilo que quer. Outra visão completamente diferente terá quem o vai utilizar todos os dias para fazer o trabalho, e ainda outra visão diferente terá o gestor que quer analisar o desempenho do processo ao longo do tempo.

Para diferentes intervenientes devem adotar-se diferentes abordagens no levantamento de requisitos.

No caso deste projeto em concreto, alguns requisitos resultam da própria natureza do projeto e por envolver diferentes países e consequentemente diferentes abordagens na prescrição de sapatos para pé diabético. Outros requisitos são impostos pela própria empresa onde o software se desenvolve, uma vez que existe a necessidade de interagir com hardware já em comercialização. E finalmente, os utilizadores do sistema, como por exemplo os técnicos e médicos podologistas, identificam um conjunto de funcionalidades que a solução deve ter para ir de encontro às suas necessidades.

No que se refere a este último conjunto de atores, o método utilizado consiste num conjunto de perguntas pré-desenvolvidas (podem ser consultadas no Anexo B.1) com o intuito de responder às questões acima apresentadas e que vão de encontro às recomendações feitas pela norma. Para completar essa abordagem, foi elaborado um pequeno protótipo (incluído no Anexo B.2) em PowerPoint com o objetivo de confrontar os podologistas e técnicos com

uma primeira abordagem ao problema e perceber o que mudariam nesse protótipo para que seja útil e vá de encontro ao que pretendem.

Esse primeiro protótipo serviu ainda para abordar a empresa sobre as restrições impostas pelo hardware.

De forma a organizar e facilitar uma posterior avaliação dos requisitos e que também servirá para avaliar e validar o desempenho da plataforma web, deve ter-se em conta um conjunto de características relevantes. Um documento de especificação de requisitos para um sistema de informação deve ser [IEEE std 830-1993]:

a) Correto: Cada requisito deve especificar apenas uma funcionalidade; b) Não ambíguo: Cada requisito deve ter apenas uma interpretação; c) Completo: Deve envolver todas as cinco questões acima mencionadas; d) Consistente: Um requisito não deve entrar em conflito com outro requisito; e) Ordenado por grau de prioridade: Os requisitos devem ter uma característica

que defina o grau de prioridade no que diz respeito à validação desse requisito: i. Essencial: Não é aceitável que este requisito não seja satisfeito;

ii. Condicional: São requisitos que melhoram a aplicação mas não são considerados essenciais;

iii. Opcional: São requisitos que podem não ser verificados. Um conjunto de funcionalidades extra e que não são absolutamente necessárias mas que poderiam ser interessantes do ponto de vista funcional.

f) Verificável: Deve ser possível verificar no software se existe alguma funcionalidade que cumpra o requisito especificado. Cada requisito deve incluir um processo que sirva para verificar se esse requisito é ou não cumprido;

g) Modificável: Deve ser possível adicionar, eliminar ou modificar qualquer requisito em qualquer momento, sem que para isso seja necessário reescrever o documento na íntegra;

Com base em todas estas recomendações retiradas da norma, foi construído um documento com a identificação dos requisitos e devidamente classificados. No anexo B.3 encontra-se esse documento na íntegra.

Com base nesse documento é possível identificar cinco requisitos que se podem denominar por requisitos core para o sistema:

1. O sistema deve manter a confidencialidade dos dados dos pacientes: Este foi o requisito principal imposto pela empresa onde se desenvolveu a solução. É absolutamente crítico que os dados dos pacientes sejam completamente desacoplados do processo mas ao mesmo tempo que seja possível mapear os processos nos pacientes à espera do calçado ortopédico;

2. Para cada processo, a plataforma deve permitir a troca de mensagens entre utilizadores: Cumprir este requisito representa atingir um dos objetivos principais da plataforma (facilitar a comunicação entre os intervenientes);

3. O sistema deve integrar uma ferramenta java3D5_{: Esta ferramenta que se} pretende integrar representa uma forma quantitativa de analisar o estado de saúde do paciente. Logo, cumprir este requisito representa um importante avanço nos métodos de diagnóstico da patologia de pé diabético;

5

Esta ferramenta consiste num software aplicativo que é executado no contexto de um web browser. Foi desenvolvida pela Tomorrow Options S.A com o intuito de reproduzir os ficheiros exportados do software do WalkinSense

3.3 -Arquitetura do Sistema 17

4. Para cada processo, a plataforma deve permitir a consulta de catálogos dos fabricantes registando a referência do produto: Este requisito tem por objetivo oferecer mais modelos de sapatos aos pacientes através da integração de vários fabricantes, aumentando a concorrência entre eles;

5. O sistema deve permitir fazer Upload de ficheiros: Este requisito tem por objetivo oferecer a possibilidade aos utilizadores de trocarem ficheiros entre eles de forma a complementarem a informação de cada processo. Visa essencialmente reduzir os erros no produto final através de uma maior e mais fácil troca de informação entre utilizadores responsáveis pelo processo.

Cumprir estes requisitos significa atingir os objetivos definidos para a plataforma. Mais do que requisitos com prioridade máxima, estes são os requisitos que definem a identidade da plataforma e a forma como combatem os problemas que existem atualmente no processo de prescrição de calçado para pé diabético.

Foram ainda identificadas três questões críticas que devem ser exploradas no desenvolvimento do sistema de informação [Santos, 2012]

• A maioria dos médicos queixam-se que as plataformas para preencher dados não são fáceis de usar;

• O tempo que o paciente espera desde a prescrição do calçado até o receber com as características desejadas é crítico, uma vez que os pacientes de alto risco desenvolvem úlceras frequentemente;

• O aspeto estético dos sapatos é muito importante para se obter adesão do paciente.

3.3 -

Arquitetura do Sistema

A especificação de um sistema de informação deve apoiar-se numa análise cuidada dos requisitos e do respetivo mapeamento em funcionalidades que a plataforma deve suportar. Esta análise funcional caracteriza-se por uma descrição detalhado do sistema e do que deve ser capaz de fazer para estar de acordo com as especificações dos vários atores envolvidos. Através da arquitetura funcional é possível descrever a forma como um sistema complexo se divide em pequenos subsistemas e a forma como se interligam. Na figura 3.2 pode observar-se a arquitetura funcional para a plataforma de suporte à prescrição de calçado para pé diabético.

Podologista

Técnico

WalkinSense

Visualização

Armazenamento Processamento Comunicações

Fabricante Informação Instruções Informação Instruções/Dados Informação Instruções/Dados Dados Dados Dados Dados Comandos

Figura 3.2 – Arquitetura funcional da plataforma de apoio à prescrição de calçado para pé diabético

De um modo geral pode dizer-se que o sistema interliga três grandes atores: O técnico especializado ligado à indústria do calçado ortopédico, o podologista e mais indiretamente o paciente.

A interface do sistema de informação é apresentada a utilizadores registados e com permissões diferentes de acordo com os privilégios de cada tipo de utilizador.

Na figura 3.2 estão representados oito grandes blocos, sendo que cinco deles representam subsistemas e os outros três representam os diferentes utilizadores do sistema (podologista, fabricante e técnico).

O bloco das comunicações representa o protocolo que terá que ser desenvolvido para trocar informação com os fabricantes. Apesar de haver comunicações em todo o sistema e entre os vários blocos representados na figura 3.2, apenas neste bloco existirá um protocolo com capacidade para trocar informação com outras aplicações exteriores.

O bloco de armazenamento corresponde a uma base de dados onde será armazenada a informação relativa a toda a infraestrutura de informação. Esta base de dados será acedida através de uma linguagem de programação que será escolhida de acordo com as especificações e de forma a cumprir os requisitos do utilizador.

O bloco de processamento representa um conjunto de páginas desenvolvidas numa linguagem de programação web com capacidade de transformar a linguagem humana em linguagem máquina. Todas as ações dos utilizadores passarão por este bloco, onde serão processadas e interpretadas e só depois de validadas passarão para os restantes blocos. Esta é uma das formas encontradas para se reduzirem os erros no processo de prescrição de calçado para pé diabético. Assim, será sempre possível avisar o utilizador que aquilo que pretende fazer é ou não correto.

O bloco de visualização corresponde à representação visual dos dados guardados no bloco de armazenamento. Será também desenvolvido numa linguagem de programação apropriada e tem como única função apresentar e recolher os dados e ações do utilizador.

O bloco do WalkinSense corresponde a um dispositivo eletrónico com capacidade de adquirir e apresentar informação quantitativa relativa à pressão plantar.

3.4 -Análise e Conceção 19

De uma forma resumida pode considerar-se que a plataforma recolhe vários tipos de informação de cada tipo de utilizador (ator), processa essa informação, armazena-a numa base de dados e apresenta-a de forma estruturada aos respetivos utilizadores.

3.4 -

Análise e Conceção

Depois do levantamento de requisitos e de uma definição da arquitetura do sistema é necessário descrever o que o sistema deve ser capaz de fazer em termos de funcionalidades. Ou seja, mapear os requisitos especificados pelos utilizadores em funcionalidades a ser implementadas nos diferentes blocos da arquitetura do sistema.

A figura 3.3 representa o mapeamento das funcionalidades identificadas nos requisitos, relativas aos utilizadores do tipo “Podologista”.

Figura 3.3 – Interface Podologista – Sistema

Depois de se validar no sistema, o podologista terá acesso à lista de processos. Aqui poderá encontrar o processo desejado selecionando um conjunto de filtros que estarão à sua disposição de forma a aumentar a eficiência da pesquisa. Em vez de selecionar poderá criar um novo processo se assim desejar. Ao escolher um processo, e no caso de ser ele o autor, poderá editar os dados do processo ou elimina-lo. Se não for o autor, apenas poderá consultar ou adicionar novas informações ao processo. Neste caso, é possível aceder a uma área de diálogo para trocar informações com outros utilizadores e aceder a uma área de upload de documentos que permitem complementar os dados do processo.

No caso de o utilizador ser um “Técnico”, a interface disponível encontra-se representada na figura 3.4.

Figura 3.4 – Interface Técnico – Sistema

A interface que é apresentada a um utilizador do tipo “Técnico” não difere em muito da interface de um podologista. As duas diferenças mais relevantes são:

• Um técnico não pode criar um processo;

• Um técnico pode submeter um processo para produção;

• No caso de se tratar de um utilizador do tipo “Administrador”, a interface que lhe é apresentada segue as orientações da figura 3.5.

3.4 -Análise e Conceção 21 Login no S.I Aceder aos Processos Escolher Processo Criar Processo Editar Processo Eliminar Processo Consultar Processo Alterar Dados do Processo Fazer Upload de Ficheiros para o Processo

Aceder a uma área de diálogo para troca de informação entre

podologistas ou técnicos Consultar Catálogos / Escolher Modelo Submeter para Produção Administração Ver Utilizador Eliminar Utilizador Adicionar Utilizador Editar Utilizador

Figura 3.5 – Interface Administrador – Sistema

Um administrador tem todas as funcionalidades dos outros utilizadores às quais se acrescem as funcionalidades administrativas. Nessa área, um administrador poderá editar, eliminar e adicionar novos utilizadores. É importante referir, que haverá um administrador que nunca poderá ser eliminado.

Recorrendo mais uma vez à arquitetura do sistema, o bloco de processamento também pode ser dividido e simplificado em subsistemas mais simples, como se pode ver pela figura 3.6.

Figura 3.6 – Esquematização das funções desempenhadas pelo bloco de processamento

Como já foi referido anteriormente, este bloco apenas processa a informação que recebe do utilizador e converte em dados compatíveis para armazenamento na base de dados. Este bloco funciona também na ordem inversa, ou seja, recebe os dados da base de dados e disponibiliza-os na plataforma web.

3.5 -

Casos de Uso da Plataforma

Com o objetivo de mapear os requisitos em funcionalidades e fazer uma melhor interpretação dos requisitos, recorreu-se a diagramas de casos de uso. Na figura 3.7 encontra-se representado o diagrama de casos de uso para a plataforma de suporte ao processo de prescrição de calçado para pé diabético. Como é natural e dado o elevado número de funcionalidades da plataforma, estão apenas representados os casos de uso essenciais e que representam as funcionalidades “core” da plataforma.

Recebe os dados do sistema de informação provenientes das ações dos utilizadores

Processa os dados de forma a serem compatíveis com a

arquitetura da BD

3.5 -Casos de Uso da Plataforma 23

Figura 3.7 – Diagrama de casos de uso para a plataforma

Com este diagrama evidenciam-se as responsabilidades de cada utilizador e as suas permissões no sistema. Note-se que para qualquer ação é necessário autenticação no sistema, ou seja, não é possível utilizar a plataforma sem que se possua as credenciais de acesso. São elas que atribuem as diferentes permissões a cada utilizador.

É importante referir que tal como está representado no diagrama anterior, não é possível fazer qualquer ação relacionada com um processo sem que antes se tenha escolhido um processo. Não faria sentido adicionar ou trocar informação entre utilizadores se não estivesse tudo associado a um determinado processo. Desta forma está assegurado que toda a informação armazenada na base de dados está associada a um processo em concreto.

No caso de o utilizador ser do tipo “Administrador”, este terá acesso a todas as funcionalidades ao dispor dos outros utilizadores às quais se acrescentam as funcionalidades inerentes à gestão de utilizadores.

Os casos de uso “Submeter Processo” e “Carregar Ficheiros” são suficientemente complexos para se justificar um maior detalhe na sua especificação. Mais uma vez, recorrendo a diagramas de casos de uso, pode representar-se com maior detalhe estas duas funcionalidades. Na figura 3.8 encontra-se representado o caso de uso “Submeter Processo”.

Figura 3.8 – Diagrama do caso de uso “Submeter Processo”

Este caso de uso é o responsável por fazer a comunicação entre a plataforma e o fabricante. É através desta funcionalidade que a informação de cada processo é enviada para a indústria do calçado ortopédico. O elemento central deste caso de uso é uma página XML gerada de forma dinâmica e que permite ao fabricante aceder a toda a informação dos processos submetidos para produção. O fabricante só terá acesso aos processos que estão prontos para a produção, ou seja, os processos são filtrados para que só sejam apresentados aqueles que contêm toda a informação necessária para a produção.

Figura 3.9 – Diagrama do caso de uso “Carregar Ficheiros”

A figura 3.9 representa o caso de uso “Carregar Ficheiros”. O utilizador só tem que escolher o processo e o respetivo ficheiro que quer adicionar ao processo. A infraestrutura de informação automaticamente faz a verificação da extensão do ficheiro (verifica se o tipo de ficheiro é permitido) e carrega o ficheiro no respetivo processo. Mais à frente neste relatório, o processo de “upload” é explicado em maior detalhe, assim como a respetiva gestão dos ficheiros nos processos.

3.5 -Casos de Uso da Plataforma 25

Figura 3.10 – Implementação – Caso de Uso

A figura anterior evidencia mais uma vez, que a plataforma é a principal ferramenta que irá fechar o processo de prescrição de calçado para pé diabético. Será a responsável por criar um elo de ligação entre os fabricantes e os técnicos ou podologistas que prescrevem o calçado e facilitar a troca de informação entre eles.

Capítulo 4

Desenvolvimento e Implementação da

Solução

Ao longo deste capítulo pretende-se descrever a forma como foi desenvolvida e implementada a plataforma de apoio ao processo de prescrição de calçado para pé diabético. Nesta fase do projeto pretende-se implementar por ordem de prioridade todas as funcionalidades determinadas pelos requisitos. Não menos importante do que implementar essas funcionalidades é escolher as tecnologias apropriadas para as implementar.

4.1 -

Revisão Tecnológica

São inúmeras as linguagens de programação ao dispor do programador. O maior desafio é saber quais utilizar. Para este projeto, optou-se por uma solução hibrida que envolve um conjunto de linguagens diferentes de forma a tornar mais versátil a integração com outras aplicações provenientes de outras empresas envolvidas no projeto.

As linguagens de programação escolhidas para o desenvolvimento da plataforma são: • HTML: HyperText Markup Language é uma linguagem baseada em marcas

através das quais é formatado o conteúdo das páginas. Basicamente, o HTML dispõe os comandos formatação usuais que se encontram nos processadores de texto [Harris, 2011];

• CSS: Cascading style sheets é uma folha de estilo que define um conjunto de regras que determinam como é que o browser6

apresenta os documentos HTML. Desta forma é possível separar o conteúdo do documento do estilo da apresentação. De entre as vantagens destacam-se:

6

Programa com capacidade para interagir com páginas virtuais que estejam hospedadas num servidor WEB.

a. As folhas de estilo podem ser definidas em ficheiros externo os ficheiros HTML, o que permite utilizar as mesmas definições de estilo em múltiplas páginas;

b. Desta forma, é possível mudar completamente o estilo de uma aplicação atuando sobre um único ficheiro [Harris, 2011].

• PHP: Hypertext Preprocessor é uma linguagem interpretada livre e é utilizada para gerar conteúdo dinâmico na WEB.

Numa primeira fase da WEB, não era possível efetuar qualquer tipo de processamento, como por exemplo aceder a bases de dados, através de HTML, existindo apenas ficheiros estáticos armazenados em servidores. Usando PHP é permitido recolher dados introduzidos pelo utilizador, processar esses dado e gerar respostas que, por sua vez são enviadas aos utilizadores [Harris, 2011].

• JavaScript: é uma linguagem de script dinâmica e baseada em objetos. A grande vantagem em utilizar esta linguagem para integrar com HTML reside no facto do código JavaScript correr localmente no navegador do utilizador e não num servidor, fazendo com que o browser responda mais rapidamente a ações do utilizador [Cecco, 2011];

• jQuery: é uma biblioteca JavaScript cross-browser7

desenvolvida para simplificar os scripts8

que interagem com o HTML. Neste projeto, esta biblioteca é usada principalmente para melhorar o aspeto gráfico da aplicação através de animações e manipulação de eventos [Cecco, 2011]; • Smarty: é um sistema de templates WEB, escrito em PHP e que visa separar a

apresentação da parte que gera o conteúdo dinâmico. Assim, deixa de ser necessário programar em HTML, sendo apenas necessário passar a informação para o smarty que automaticamente gera as páginas em HTML [Cecco, 2011]; • AJAX: Asynchronous Javascript and XML é o uso metodológico de tecnologias JavaScript e XML, providas por browsers, para tornar as páginas WEB mais interativas com o utilizador, utilizando-se solicitações assíncronas de informação. Isto permite ligar ao servidor para aceder a uma pequena parte da informação sem ser preciso recarregar toda a página novamente [Harris, 2011].

No que diz respeito ao armazenamento dos dados, estão disponíveis para este projeto dois tipos de bases de dados:

• MySQL: É um sistema de gestão de base de dados que utiliza a linguagem SQL como interface. Atualmente é um dos mais populares com mais de 10 milhões de instalações no mundo, podendo destacar-se a Alcatel - Lucent, Facebbok e a SonicWall. As funcionalidades que mais a caracteriza são [MySQL, 2012];

a) Portabilidade (suporta praticamente qualquer plataforma atual);

7

Habilidade de suportar múltiplos navegadores

8

4.1 - Revisão Tecnológica 29

b) Compatibilidade com diversas linguagens de programação, entre as quais, PHP;

c) Suporta controlo transacional; d) Suporta Triggers.

• PostgreSQL: É um sistema de gestão de base de dados que utiliza a linguagem SQL como interface. As características mais importantes são:

a) Consultas complexas; b) Integridade transacional;

c) Controlo de concorrência multi-versão; d) Indexação por texto;

e) Suporte ao modelo híbrido objeto-relacional.

Dada a natureza do projeto e os conhecimentos previamente adquiridos relacionados com bases de dados, PostgreSQL será a escolha para suportar a aplicação a desenvolver para o projeto.

Nesse sentido, será necessário a utilização de uma aplicação WEB, escrita em PHP, capaz de gerir uma base de dados do tipo PostgreSQL: PHPPgAdmin. Esta aplicação evidencia as seguintes características:

• Gere múltiplos servidores;

• Suporta várias versões de PostgreSQL; • Permite uma fácil manipulação dos dados;

• Exporta as tabelas de dados em diferentes formatos, entre eles, SQL • Importa scripts SQL;

• Suporta cerca de vinte e sete linguagens de programação.

4.2 -

Arquitetura da Base de Dados

A base de dados representa um dos componentes de maior importância no sistema de informação. Deve ser corretamente projetado para se combaterem futuros pontos de falha. Para se projetar a arquitetura de uma base de dados existem um conjunto de metodologias e modelos que permitem visualizar graficamente o comportamento e o armazenamento dos dados.

Neste projeto modelou-se a base de dados na forma Entidade-Associação, quer na forma textual quer na forma gráfica e modelou-se também sobre a forma de modelo relacional que representa um modelo textual muito fiel áquilo que é o código para a criação da base de dados. A escolha destes modelos recai sobre a necessidade de visualizar graficamente aquilo que é a base de dados e perceber a localização dos dados de todos os processos.

Naturalmente, e porque se trata de um processo de engenharia, a arquitetura da base de dados que se representa na figura 4.1, não foi desenhada na primeira tentativa. Tratou-se de um processo iterativo e de um longo processo de aperfeiçoamento ao longo do projeto.

Figura 4.1 – Arquitetura da base de dados sobre a forma Entidade-Associação

Como se pode observar pela figura, trata-se de uma arquitetura de alguma complexidade mas que em local algum existe a identidade do paciente. Apenas é registado o processo no sistema. Esse processo tem como identificação um nome ou um conjunto de números escolhidos pelo podologista. A associação entre esse código do processo e o paciente fica ao encargo do paciente. No entanto, e para o caso dessa identificação se perder, o processo fica registado no sistema com o nome do seu autor e data completa da sua criação. Assim, será fácil identificar e associar o processo ao paciente através da hora da sua consulta e da data registada no sistema. A entidade “Process” é sem dúvida a entidade central de todo o sistema e que vai de encontro áquilo que era o esperado, gerir pelo processo e não por um conjunto de atividades.

Todas as entidades do sistema de informação estão associadas ao processo. Desta forma, todas as ações que são executadas através da plataforma terão sempre que ser associadas a um determinado processo.

Os outros dois modelos, modelo entidade-associação na forma textual e o modelo relacional podem ser consultados no anexo C.4 e C.5 respetivamente.

4.3 -

Dispositivo Eletrónico para avaliação da pressão plantar