A cognitive study of learning to program in introductory programming courses.

Programming is notoriously hard for novices to learn and a substantial number of learners fail in introduction to programming courses. It is not just a UK problem: a number of multi-institutional and multi-national studies reveal that the problem is well-known and is widespread. There is no general agreement about the causes or the remedies. The major factors which can be hypothesised as a cause of this phenomenon are: learners' psychology; teaching methods; complexity of programming. In this study, learners' common mistakes, bugs, misconceptions, frequencies and type of errors (syntactic and semantic) in the early stages of learning programming were studied. Noticing the patterns of rationales behind novices' mistakes swayed the study toward investigating novices' mental ability which was found to have a great effect on their learning performance. It was observed that novices reported a recognisable set of models of program execution each of which was logically acceptable as a possible answer and it appeared that some students even used these models systematically. It was suspected that the intellectual strategies behind their reasoning could have been built up from their programming background knowledge and it was surprising when it was found that some of those novices had not even seen a program before. A diagnostic questionnaire was designed that apparently examined a student's understanding of assignments and sequence but in fact was capturing the reasoning strategy behind their interpretation of each question, regardless of a correct or wrong answer. The questionnaire was administered in the first week of an introductory programming course, without giving any explanation of what the questions were about. A full response from most participants was received, despite the fact that the questions were unexplained. Confronted with a simple program, about half of novices seem to spontaneously invent and consistently apply a mental model of program execution. They were called the consistent subgroup. The other half are either unable to build a model or to apply one consistently. They were called the inconsistent subgroup. The first group perform very much better in their end-of-course examination than the rest. Meta-analysis of the results of six experiments in UK and Australia confirmed a strong effect of consistency on success which is highly significant (p < 0:001). A strong eect persisted in every group of candidates, sliced by background factors of programming experience (with/ without), relevant programming experience(with/without), and prior programming course (with/without) which might be thought to have had an effect on success. This result confirms that consistency is not simply provided by prior programming background. Despite the tendency in institutions to rely on students' prior programming background as a positive predictor for success, this study revealed that prior programming education did not have a noticeable eect on novices' success. A weak positive eect of prior programming experience was observed overall which appeared to be driven by one experiment with a programming-skilful population. This study shows that students in the consistent subgroup have the ability to build a mental model, something that follows rules like a mechanical construct. It also seems that when programming skill is measured by a weak assessment mechanism, the eect of consistency on success is reduced

Strategic programming on graph rewriting systems

We describe a strategy language to control the application of graph rewriting rules, and show how this language can be used to write high-level declarative programs in several application areas. This language is part of a graph-based programming tool built within the port-graph transformation and visualisation environment PORGY.Comment: In Proceedings IWS 2010, arXiv:1012.533

Evaluation of genetic improvement tools for improvement of non-functional properties of software

Genetic improvement (GI) improves both functional properties of software, such as bug repair, and non-functional properties, such as execution time, energy consumption, or source code size. There are studies summarising and comparing GI tools for improving functional properties of software; however there is no such study for improvement of its non-functional properties using GI. Therefore, this research aims to survey and report on the existing GI tools for improvement of non-functional properties of software. We conducted a literature review of available GI tools, and ran multiple experiments on the found open-source tools to examine their usability. We applied a cross-testing strategy to check whether the available tools can work on different programs. Overall, we found 63 GI papers that use a GI tool to improve nonfunctional properties of software, within which 31 are accompanied with open-source code. We were able to successfully run eight GI tools, and found that ultimately only two ---Gin and PyGGI--- can be readily applied to new general software

Telecommand and Telemetry Implementation of Aalto-2 CubeSat Project

This thesis work concentrates on the development of telecommand and telemetry handler software for a 2 kg Aalto-2 nanosatellite, currently scheduled for launch in October 2016. The satellite is part of the international QB50 termosphere mission and it is developed by Aalto University in Espoo, Finland. The telecommand and telemetry (TC/TM) handler, in charge of communications, is one of the most important systems of satellite software, which is executed by On Board Computer (OBC). In this thesis, the TC/TM handler subsystem is designed, giving it a special attention in maintaining simplicity and reliability. The design process is started with the derivation of requirements and constraints. The software is implemented for FreeRTOS, an open-source real-time operating system, which is selected as operation environment of the satellite OBC software. The designed software uses a Concatenative Language approach and complies with ECSS-PUS standard. It features different libraries that provide capabilities for on-board data handling needs, the most notable of which is the Dyncall library. The library provides functions of dynamic function call in C. The UHF driver handles incoming and outgoing low-level communications protocols, and the Coffee File System implements storage management. The work gives an overview of small satellite communication architectures and relevant standards and interfaces.Esta tésis se centra en el desarrollo de sistemas de telecontrol y software controlador de telemetría para el nanosatélite Aalto-2, cuyo lanzamiento está previsto para octubre de 2016. El satélite forma parte de la misión internacional QB50 termosphere y ha sido desarrollado por la Universidad de Aalto en Espoo, Finlandia. El controlador de telecomando y telemetría (TC/TM), a cargo de las comunicaciones, es uno de los sistemas más importantes del software del satélite. Este software es ejecutado por el Ordenador de abordo (OBC). El proceso de diseño se inicia con la derivación de los requisitos y limitaciones. El software está implementado para FreeRTOS, un sistema operativo en tiempo real de código abierto, que es seleccionado como entorno operativo del software del OBC. El software diseñado utiliza un enfoque de programación concatenativa y cumple con la norma de ECSS-PUS. Cuenta con diferentes librerias que proporcionan capacidades de datos de abordo necesidades de manipulación, el más notable de los cuales es la libreria Dyncall. Esta proporciona funciones de llamada dinámica en C. Los drivers de la UHF maneja los protocolos de comunicación de bajo nivel de entrada y salida, y el sistema de archivo es implementado por el Coffe File System o CFS. El trabajo ofrece una visión general de las arquitecturas de comunicaciones de nanosatélites, las normas pertinentes y las interfaces.Aquesta tési es centra en el desenvolupament de sistemes de telecontrol i programari controlador de telemetria per al nanosatèl·lit Aalto-2, el llançament del qual està previst per octubre del 2016. El satèl·lit forma part de la missió internacional QB50 termosphere i ha estat desenvolupat per la Universitat d'Aalto a Espoo, Finlàndia. El controlador de telecomandament i telemetria (TC / TM), se'n fa càrrec de les comunicacions i és un dels sistemes més importants del programari del satèl·lit. Aquest és executat per l'ordinador d'abord (OBC). El procés de disseny s'inicia amb la derivació dels requisits i limitacions. El programari està implementat per FreeRTOS, un sistema operatiu en temps real de codi obert, que és seleccionat com a entorn operatiu del OBC. El programari dissenyat utilitza un enfocament de programació concatenada i compleix amb la norma de ECSS-PUS. Compta amb diferents llibreries que proporcionen capacitats de dades d'abordo necessitats de manipulació, el més notable dels quals és la llibreria Dyncall. Aquesta proporciona funcions de crida dinàmica en C. Els drivers de la UHF controla els protocols de comunicació a baix nivell d'entrada i sortida, i el sistema d'arxiu és implementat pel Coffe File System o CFS. El treball ofereix una visió general de les arquitectures de comunicacions de nanosatèl·lits, les normes pertinents i les interfícies

A bounded-search iterated greedy algorithm for the distributed permutation flowshop scheduling problem

As the interest of practitioners and researchers in scheduling in a multi-factory environment is growing, there is an increasing need to provide efficient algorithms for this type of decision problems, characterised by simultaneously addressing the assignment of jobs to different factories/workshops and their subsequent scheduling. Here we address the so-called distributed permutation flowshop scheduling problem, in which a set of jobs has to be scheduled over a number of identical factories, each one with its machines arranged as a flowshop. Several heuristics have been designed for this problem, although there is no direct comparison among them. In this paper, we propose a new heuristic which exploits the specific structure of the problem. The computational experience carried out on a well-known testbed shows that the proposed heuristic outperforms existing state-of-the-art heuristics, being able to obtain better upper bounds for more than one quarter of the problems in the testbed.Ministerio de Ciencia e Innovación DPI2010-15573/DP

A comparative study of software architectures in constrained-device iot deployments

Since its inception in 2009, the Internet of Things (IoT) has grown dramatically in both size and complexity. One of the areas that has seen significant developments is that of resourceconstrained devices. Such devices clearly require careful engineering in order to manage resources such as energy and memory, whilst still ensuring acceptable performance. A number of aspects play a critical role in the engineering of such systems. One such aspect is the choice of software architecture. The microservices architecture appears to be a promising approach for IoT, as suggested by a number of researchers. However, limited research has been done on the implementation of microservices in IoT and resource-constrained devices, and even less research has been done to compare the microservices architecture to the monolithic architecture in such deployments. The aim of this research thesis was to compare these two architectures in the context of IoT and constrained devices. The two architectures were compared by: energy consumption, runtime performance and memory consumption. To ensure that the results are not specific to a single programming language, each architecture was developed in three different languages: Go, Python and C++. Following a review of different asynchronous messaging protocols, Message Queuing Telemetry Transport was selected. The experiments were conducted on a Raspberry Pi 4, and a number of other hardware devices were used, including sensors, an actuator and a type C USB Tester. Two metrics were used to measure power consumption: maximum instantaneous power consumption and total power consumption. Whilst three metrics were used to measure memory consumption: maximum Resident Set Size (RSS), total RSS and central processing unit (CPU) resource usage. Each experiment was carried out 10 times in order to ensure data validity. The power consumption results showed that the microservices architecture had, on average, 14,9% higher maximum instantaneous power consumption, whilst the total power consumption of the microservices architecture was only 3,0% greater than that of the monolithic architecture. The runtime results indicated that the microservices architecture had a longer runtime than the monolithic architecture for Go and C++, whilst the inverse was true for Python. When considering memory consumption, it was found that the maximum RSS was 37,1% greater for the microservices architecture. The total RSS results for both architectures were very similar for Go and C++, whilst microservices performed much better for Python. Lastly, the results for CPU usage showed that the monolithic architecture had, on average, 14,9% greater CPU usage than the microservices architecture. It was concluded that, for small-scale applications, the monolithic architecture had better performance across most metrics and languages. It was, however,recommended that additional research be conducted on larger scale applications to determine the applicability of these results beyond the scope of small-scale applications. In general, there is still much room for research in this area.A Web e a Internet das Coisas (WoT/IoT) são áreas empolgantes que, sem dúvida, continuarão a desenvolver-se nos próximos anos. À medida que vão sendo feitos novos desenvolvimentos nestas áreas, e vários tipos de objetos se tornam “Coisas”, é expectável que a limitação de recursos seja cada vez mais uma preocupação. Atualmente já existem muitos dispositivos que possuem recursos limitados por vários motivos, como a sua localização em locais difíceis ou remotos (ex: sensores implantáveis ou sensores de erupção vulcânica) ou necessidade de trabalhar enquanto estão em movimento (ex: dispositivos vestíveis). Assim sendo, a necessidade de usar-se os recursos de forma eficiente será cada ver maior. O objetivo primordial desta tese foi o de analisar a utilização de recursos por parte de uma aplicação IoT, considerando duas arquiteturas de software diferentes, implementada num dispositivo com poucos recursos. O dispositivo escolhido é um Raspberry Pi 4, dado ser um dispositivo embarcado bastante adequado para realização de testes. As arquiteturas que foram comparadas neste estudo foram: microsserviços e monolítica. Para garantir que os resultados não fossem específicos da linguagem utilizada, o desenvolvimento foi feito em três linguagens de programação: Go, Python e C++. Embora seja possível encontrar estudos que analisam como as linguagens de programação utilizam os recursos, apenas foi encontrado um estudo cujo foco é a eficiência energética, memória e tempo de execução em dispositivos com recursos limitados, não tendo sido encontrado nenhum estudo que compare o desempenho das arquiteturas de software em dispositivos com recursos limitados. A adoção de uma arquitetura de microsserviços em ambientes WoT/IoT tem vantagens, como modularidade, flexibilidade e facilidade de manutenção. Vários estudos referem que esta arquitetura é adequada para WoT/IoT, pois compartilha muitos dos mesmos objetivos. WoT/IoT é inerentemente dinâmico e tem muitos pontos de extremidade, o que pode apresentar desafios de desenho e implementação. Uma arquitetura como microsserviços pode explorar estas caracteristicas, transformando estes desafios em vantagens. No entanto, não foi encontrada investigação que compare o desempenho da arquitetura de microsserviços com a arquitetura monolítica, especialmente no contexto IoT, tendo sido este o foco desta tese. A escolha do protocolo de transferência de mensagens, para comunicação entre os vários microsserviços, foi também analisada. Um protocolo de transferência leve será o mais adequado, para dispositivos que têm recursos limitados, e três opções foram consideradas em mais profundidade: MQTT (Message Queuing Telemetry Transport), AMQP (Advanced Message Queuing Protocol) e CoAP (Constrained Application Protocol). Da análise feita, verificou-se que o MQTT é limitado na qualidade de serviço, seguranca e confiabilidade que oferece, isto quando comparado com o AMQP, sendo por isso um protocolo mais leve. Ao comparar-se MQTT e CoAP, verificou-se que ambos os protocolos oferecem vários benefícios, tendo o MQTT sido escolhido para os testes realizados. A abordagem técnica que foi adotada é descrita em detalhe, incluindo os componentes de hardware necessários para o projeto e o software necessário para a recolha de medições. Foi ainda delineada uma metodologia experimental, a qual foi seguida de perto. Foram obtidos resultados que permitem analisar em detalhe o consumo de energia, o tempo de execução e o consumo de memória. Quanto ao consumo de energia, em específico, recolhe-se o consumo de energia instantâneo máximo e o consumo de energia total. Desta análise verificou-se que o consumo de energia instantâneo máximo da arquitetura de microserviços foi, em média, e em todas as linguagens, 14.9% maior do que o consumo obtido para a arquitetura monolítica. Verificou-se também que a linguagem Go tem o maior consumo de energia instantâneo máximo, para ambas as arquiteturas, enquanto que o Python e o C++ tiveram medidas semelhantes. Os resultados para o consumo total de energia (durante o tempo de execução total) foram ligeiramente diferentes. Ao comparar-se as duas arquiteturas, deduziu-se que os valores de consumo de energia eram muito semelhantes e, em média, e em todas as linguagens, a arquitetura de microsserviços consumia apenas 3.0% a mais que a arquitetura monolítica. Também foi verificado que ao usar-se a arquitetura monolítica, o consumo total de energia era quase idêntico em todos as linguagens. Com a arquitetura de microserviços, o Python teve o maior consumo, seguido do Go e C++, embora os valores não tenham diferido muito. Também ficou claro que, embora o consumo de energia instantâneo máximo possa ser útil para entender os requisitos de energia de pico, não é diretamente proporcional ao consumo de energia total. Por exemplo, o Python teve o menor consumo de energia instantâneo máximo, mas o maior consumo de energia total. A segunda parte dos resultados considerou o desempenho no que diz respeito ao tempo de execução. Considerando apenas a arquitetura, verificou-se que a quitetura de microsserviços tinha um tempo de execução maior do que a arquitetura monolítica para Go e C++, enquanto o inverso era verdadeiro para o Python, o que pode estar relacionado com a otimizacao de simultaneidade vinculada à unidade central de processamento (CPU), pelas diferentes linguagens. Ao comparar o tempo de execução das linguagens de programacao, os resultados ficaram amplamente em linha com as expetativas. C++ teve o menor tempo de execução, seguido de perto pelo Go. O Python teve um tempo de execução significativamente mais longo, o que faz sentido já que o Python é a única linguagem interpretada que foi usada neste projeto. Foi interessante notar que o tempo de execução do Python foi muito maior ao usar-se uma arquitetura monolítica do que ao usar-se uma arquitetura de microserviços, o que não foi o caso do C++ ou Go. Com a arquitetura de microserviços, o Python teve um tempo de execução médio 319.4% maior do que o do C++, enquanto que o tempo de execuçao médio do Go foi 31.5% maior do que o do C++. Diferenças semelhantes foram observadas para a arquitetura monolítica. O consumo de memória foi medido usando três métricas diferentes: tamanho do conjunto residente (RSS) máximo, RSS total e uso de CPU. A comparação do RSS máximo, em cada arquitetura, mostrou que o RSS máximo para a arquitetura de microserviços foi 37.1% maior do que para a arquitetura monolítica. A diferença foi especialmente significativa para Python (65.9% de diferença). Verificou-se que o Go teve um RSS máximo significativamente maior do que as outras linguagens, para ambas as arquiteturas. O Python teve o menor RSS máximo na arquitetura monolítica, enquanto que o C++ teve o menor para a arquitetura de microserviços. Os resultados para o RSS total foram muito diferentes do RSS máximo, tanto por arquitetura como por linguagem usada. Mais concretamente, as medidas totais de RSS para Go e C++ nao diferiam muito por arquitetura, embora houvesse uma grande diferença quando comparado com o Python. Em média o RSS total foi 127.0% maior para a arquitetura monolítica do que para a arquitetura de microserviços, ao usar-se Python. Comparando por linguagem, o RSS total do Python foi significativamente maior do que para as outras duas linguagens, especialmente para a arquitetura monolítica, enquanto o Go e C++ tiveram medições RSS totais muito semelhantes. A última métrica de consumo de memória considerada foi o uso médio da CPU. Verificou-se que a arquitetura monolítica teve, em média, 14.9% maior utilização de CPU do que a arquitetura de microserviços, e a maior diferença foi observada para o Python. Uma comparação por linguagem mostrou que o Go teve a maior utilização de CPU, para ambas as arquiteturas. O C++ teve a segunda maior utilização de CPU, e o Python teve a menor utilização. Estas conclusões foram de encontro às expectativas, já que o Go tem processos integrados leves (rotinas Go), podendo otimizar a utilização de CPU. Esta dissertação produziu, em geral, resultados muito interessantes, uns mais esperados que outros. Os resultados mostraram que a arquitetura monolítica teve melhor desempenho na maioria das métricas, ou seja, consumo de energia instantâneo máximo, consumo de energia total (apenas para o Go e Python), tempo de execução geral (apenas para o Go e C++), RSS e CPU máximos. Deste modo, é possível concluir que ao implementar-se aplicações de pequena escala, em dispositivos IoT, a arquitetura monolítica pode oferecer mais benefícios. É bastante provável, no entanto, que a arquitetura de microserviços possa superar a arquitetura monolítica em aplicações de maior escala. A dimensão da aplicação deve, por isso, ser considerada ao escolherse uma arquitetura de software. Claramente, ainda existe muito espaço para contribuição nesta área de investigação. A investigação encontrada sobre o desempenho da arquitetura de microserviços, em comparação com a arquitetura monolítica, é limitafa e não foi encontrada investigação no contexto da IoT. Isto acaba por ser surpreendente, pois muitas empresas estão já a adotar microserviços e tem havido um aumento das pesquisas relacionadas com esta arquitetura. Assim sendo, compreender quais as vantagens e desvantagens desta arquitetura tornou-se muito pertinente. Embora esta dissertação tenha analisado a arquitetura de microsserviços, e tendo esta sido comparada com a arquitetura monolítica, considerando diferentes linguagens, a análise é feita numa escala relativamente pequena, quanto ao número de componentes de serviço, e num único dispositivo embarcado. A análise de aplicações de maior escala forneceria, certamente, perceções adicionais muito valiosas