52 resultados para API (Application Programming Interface)
Resumo:
Teaching and learning computer programming is as challenging as difficult. Assessing the work of students and providing individualised feedback to all is time-consuming and error prone for teachers and frequently involves a time delay. The existent tools and specifications prove to be insufficient in complex evaluation domains where there is a greater need to practice. At the same time Massive Open Online Courses (MOOC) are appearing revealing a new way of learning, more dynamic and more accessible. However this new paradigm raises serious questions regarding the monitoring of student progress and its timely feedback. This paper provides a conceptual design model for a computer programming learning environment. This environment uses the portal interface design model gathering information from a network of services such as repositories and program evaluators. The design model includes also the integration with learning management systems, a central piece in the MOOC realm, endowing the model with characteristics such as scalability, collaboration and interoperability. This model is not limited to the domain of computer programming and can be adapted to any complex area that requires systematic evaluation with immediate feedback.
Resumo:
Esta dissertação tem como principal objetivo a criação de uma interface humana, baseada na eletromiografia dos músculos orbicular do olho e frontalis. O algoritmo de programação do microcontrolador ATmega2560 deteta o piscar de olhos voluntário, conta o número de vezes que este acontece e verifica se preenche os requisitos necessários à execução de um comando. Para este efeito foram utilizados elétrodos para a captação do sinal eletromiográfico. O sinal analógico é condicionado pela Shield ECG/EMG da Olimex sendo enviado para o arduíno ATmega2560. Este microcontrolador administra todos os atuadores, dos quais o mais importante é um painel de comandos (quatro comandos diferentes), no qual existe um ponteiro motorizado que indica qual a ação a realizar. O código de execução é extremamente simples: se o utilizador piscar os olhos três vezes, o ponteiro movimenta-se para a secção do painel imediatamente à direita; e se o utilizador piscar os olhos quatro vezes, o ponteiro movimenta-se para a secção do painel imediatamente à esquerda. Os testes realizados com este dispositivo indicam que os utilizadores demoram menos de 10 minutos a aprender a utilizar e executar todos os comandos do painel. Apenas num dos testes realizados o dispositivo não funcionou. Dos utilizadores que realizaram o teste: vários usam óculos; um idoso com graves problemas auditivos, cegueira parcial e dificuldades locomotoras; nenhum foi incapaz de piscar, pelo menos, um dos olhos voluntariamente; e a maioria referiu que, com alguma concentração e principalmente se ouvirem o bip sonoro, a aprendizagem de utilização torna-se muito fácil. Apesar dos limites impostos à concretização de um projeto deste tipo (dos quais se evidenciam as dificuldades em conseguir voluntários com paralisia medular, bem como os limites orçamentais), pode-se afirmar que este dispositivo é eficaz e seria uma mais valia quando implementado num cenário de paralisia medular (total ou parcial). A melhoria de qualidade de vida de um utilizador com estes problemas físicos, ou outros que lhe comprometam a locomoção é garantida. O cenário em que vivem é tremendamente limitado sendo urgente criar soluções para tornar estas vidas mais cómodas. Com os devidos aplicativos, o utilizador poderia abrir portas ou janelas, acender ou apagar luzes, pedir ajuda, ajustar a posição da cama, controlar cadeiras de rodas, entre outros. É neste sentido que surge a minha motivação de criar algo que ajude estas pessoas.
Resumo:
A presente dissertação tem como objectivo descrever o trabalho desenvolvido sobre o projecto iCOPE, uma plataforma dedicada ao auxilio do processo psicoterapêutico para pessoas com perturbações psicóticas. A sua concepção e motivada pela necessidade de fornecer um meio psicoterapêutico com base na portabilidade dos dispositivos móveis. O desenvolvimento foi conseguido através de uma colaboração multidisciplinar, orientada por especialistas de terapia ocupacional, e pela engenharia de software. O iCOPE é um sistema centralizado, no qual o progresso de um paciente é registado e monitorizado através de outra aplicação, por um terapeuta designado. Esta filosofia levou à criação de uma API baseada em REST, capaz de comunicar com uma base de dados. A construção da API concretizou-se com recurso a linguagem PHP, aliada a micro-framework Slim. O objectivo desta API passa não só pela necessidade de fornecer um sistema acessível, mas também com a ambição de conceber uma plataforma com um potencial escalável e expansível, para o caso de ser necessário implementar novas funcionalidades futuras (future-proof). O autor desta dissertação foi responsável pelo levantamento de requisitos, o desenvolvimento da aplicação móvel, o desenvolvimento colaborativo do modelo de dados e base de dados e da interface da API de comunicação. No fim do desenvolvimento foi feita uma apreciação funcional pelos utilizadores alvo, que realizaram uma avaliação sobre a utilização e integração da aplicação no seu tratamento. Face aos resultados obtidos foram tiradas conclusões sobre o futuro desenvolvimento da aplicação e que outros aspectos poderiam ser integrados para efectivamente chegar a mais pacientes.
Resumo:
O veículo guiado automaticamente (AGV) adquirido pelo Departamento de Engenharia Mecânica (DEM) tem vindo a ficar obsoleto devido ao hardware, que nos dias de hoje começa a dar sinais de falhas bem como falta de peças de substituição, e ao software, sendo o PLC (Programmable Logic Controller) usado muito limitado quanto às suas funções de controlo, ficando as principais tarefas de controlo do AGV a cargo de placas eletrónicas de controlo. Para promover o controlo autónomo do AGV, foi decidido retirar toda a parte de hardware que detinha o controlo do mesmo e passou a ser um novo PLC, com maior capacidade de processamento, a executar todo o tipo de controlo necessário ao funcionamento do mesmo. O hardware considerado apenas incluí, de forma resumida, os motores responsáveis pelo movimento e direção, placa de controlo de potência dos motores, placa de interface entre as saídas digitais do PLC e as entradas da placa de controlo de potência dos motores e os demais sensores necessários à deteção de obstáculos, fins de curso da direção, sensores dos postos de trabalho e avisadores de emergência. Todo o controlo de movimento e direção bem como a seleção das ações a executar passou a ficar a cargo do software programado no PLC assim como a interação entre o sistema de supervisão instalado num posto de controlo e o PLC através de comunicação via rádio. O uso do PLC permitiu a flexibilidade de mudar facilmente a forma como as saídas digitais são usadas, ao contrário de um circuito eletrónico que necessita de uma completa remodelação, tempo de testes e implementação para efetuar a mesma função. O uso de um microcontrolador seria igualmente viável para a aplicação em causa, no entanto o uso do PLC tem a vantagem de ser robusto, mais rápido na velocidade de processamento, existência de software de interface de programação bastante intuitivo e de livre acesso, facilidade de alterar a programação localmente ou remotamente, via rádio, acesso a vários protocolos de comunicação robustos como Modbus, Canbus, Profinet, Modnet, etc., e acesso integrado de uma consola gráfica totalmente programável. iv É ainda possível a sua expansão com adição de módulos de entradas e saídas digitais e/ou analógicas permitindo expandir largamente o uso do AGV para outros fins. A solução está a ser amplamente testada e validada no Laboratório de Automação (LabA) do Departamento de Engenharia Mecânica do ISEP (Instituto Superior de Engenharia do Porto), permitindo a otimização dos sistemas de controlo de direção bem como a interatividade entre o PLC e o programa de interface/supervisão do posto de trabalho.
Resumo:
As plataformas com múltiplos núcleos tornaram a programação paralela/concorrente num tópico de interesse geral. Diversos modelos de programação têm vindo a ser propostos, facilitando aos programadores a identificação de regiões de código potencialmente paralelizáveis, deixando ao sistema operativo a tarefa de as escalonar dinamicamente em tempo de execução, explorando o maior grau possível de paralelismo. O Java não foge a esta tendência, disponibilizando ao programador um número crescente de bibliotecas de mecanismos de sincronização e paralelização de código. Neste contexto, esta tese apresenta e discute um conjunto de resultados obtidos através de testes intensivos à eficiência de algoritmos de ordenação implementados com recurso aos mecanismos de concorrência da API do Java 8 (Threads, Threadpools, ExecutorService, CountdownLach, ExecutorCompletionService e ForkJoinPools) em sistemas com um número de núcleos variável. Para cada um dos mecanismos, são apresentadas conclusões sobre o seu funcionamento e discutidos os cenários em que o seu uso pode ser rentabilizado de modo a serem obtidos melhores tempos de execução.
Resumo:
The persistence concern implemented as an aspect has been studied since the appearance of the Aspect-Oriented paradigm. Frequently, persistence is given as an example that can be aspectized, but until today no real world solution has applied that paradigm. Such solution should be able to enhance the programmer productivity and make the application less prone to errors. To test the viability of that concept, in a previous study we developed a prototype that implements Orthogonal Persistence as an aspect. This first version of the prototype was already fully functional with all Java types including arrays. In this work the results of our new research to overcome some limitations that we have identified on the data type abstraction and transparency in the prototype are presented. One of our goals was to avoid the Java standard idiom for genericity, based on casts, type tests and subtyping. Moreover, we also find the need to introduce some dynamic data type abilities. We consider that the Reflection is the solution to those issues. To achieve that, we have extended our prototype with a new static weaver that preprocesses the application source code in order to introduce changes to the normal behavior of the Java compiler with a new generated reflective code.
Resumo:
Este documento descreve o trabalho realizado em conjunto com a empresa MedSUPPORT[1] no desenvolvimento de uma plataforma digital para análise da satisfação dos utentes de unidades de saúde. Atualmente a avaliação de satisfação junto dos seus clientes é um procedimento importante e que deve ser utilizado pelas empresas como mais uma ferramenta de avaliação dos seus produtos ou serviços. Para as unidades de saúde a avaliação da satisfação do utente é atualmente considerada como um objetivo fundamental dos serviços de saúde e tem vindo a ocupar um lugar progressivamente mais importante na avaliação da qualidade dos mesmos. Neste âmbito idealizou-se desenvolver uma plataforma digital para análise da satisfação dos utentes de unidades de saúde. O estudo inicial sobre o conceito da satisfação de consumidores e utentes permitiu consolidar os conceitos associados à temática em estudo. Conhecer as oito dimensões que, de acordo com os investigadores englobam a satisfação do utente é um dos pontos relevantes do estudo inicial. Para avaliar junto do utente a sua satisfação é necessário questiona-lo diretamente. Para efeito desenvolveu-se um inquérito de satisfação estudando cuidadosamente cada um dos elementos que deste fazem parte. No desenvolvimento do inquérito de satisfação foram seguidas as seguintes etapas: Planeamento do questionário, partindo das oito dimensões da satisfação do utente até às métricas que serão avaliadas junto do utente; Análise dos dados a recolher, definindo-se, para cada métrica, se os dados serão nominais, ordinais ou provenientes de escalas balanceadas; Por último a formulação das perguntas do inquérito de satisfação foi alvo de estudo cuidado para garantir que o utente percecione da melhor forma o objetivo da questão. A definição das especificações da plataforma e do questionário passou por diferentes estudos, entre eles uma análise de benchmarking[2], que permitiram definir que o inquérito iv estará localizado numa zona acessível da unidade de saúde, será respondido com recurso a um ecrã táctil (tablet) e que estará alojado na web. As aplicações web desenvolvidas atualmente apresentam um design apelativo e intuitivo. Foi fundamental levar a cabo um estudo do design da aplicação web, como garantia que as cores utilizadas, o tipo de letra, e o local onde a informação são os mais adequados. Para desenvolver a aplicação web foi utilizada a linguagem de programação Ruby, com recurso à framework Ruby on Rails. Para a implementação da aplicação foram estudadas as diferentes tecnologias disponíveis, com enfoque no estudo do sistema de gestão de base de dados a utilizar. O desenvolvimento da aplicação web teve também como objetivo melhorar a gestão da informação gerada pelas respostas ao inquérito de satisfação. O colaborador da MedSUPPORT é o responsável pela gestão da informação pelo que as suas necessidades foram atendidas. Um menu para a gestão da informação é disponibilizado ao administrador da aplicação, colaborador MedSUPPORT. O menu de gestão da informação permitirá uma análise simplificada do estado atual com recurso a um painel do tipo dashboard e, a fim de melhorar a análise interna dos dados terá uma função de exportação dos dados para folha de cálculo. Para validação do estudo efetuado foram realizados os testes de funcionamento à plataforma, tanto à sua funcionalidade como à sua utilização em contexto real pelos utentes inquiridos nas unidades de saúde. Os testes em contexto real objetivaram validar o conceito junto dos utentes inquiridos.