Single-page applications have historically been subject to strong market forces driving fast development and deployment in lieu of quality control and changeable code, which are important factors for maintainability. In this report we develop two functionally equivalent applications using AngularJS and React and compare their maintainability as defined by ISO/IEC 9126. AngularJS and React represent two distinct approaches to web development, with AngularJS being a general framework providing rich base functionality and React a small specialized library for efficient view rendering. The quality comparison was accomplished by calculating Maintainability Index for each application. Version control analysis was used to determine quality indicators during development and subsequent maintenance where new functionality was added in two steps.   The results show no major differences in maintainability in the initial applications. As more functionality is added the Maintainability Index decreases faster in the AngularJS application, indicating a steeper increase in complexity compared to the React application. Source code analysis reveals that changes in data flow requires significantly larger modifications of the AngularJS application due to its inherent architecture for data flow. We conclude that frameworks are useful when they facilitate development of known requirements but less so when applications and systems grow in size. / Ensidesapplikationer har historiskt sett påverkats av starka marknadskrafter som pådriver snabba utvecklingscykler och leve­rans­er. Detta medför att kvalitetskontroll och förändringsbar kod, som är viktiga fak­torer för förvaltningsbarhet, blir lidande. I denna rapport utvecklar vi två funktionellt ekvi­val­enta ensidesapplikationer med AngularJS och React samt jämför dessa applikationers för­valtningsbarhet enligt ISO/IEC 9126. AngularJS och React representerar två distinkta angreppsätt på webbutveckling, där AngularJS är ett ramverk med mycket färdig funk­tional­itet och React ett mindre bibliotek specialiserat på vyrendering. Kvalitets­jämförelsen utfördes genom att beräkna förvaltningsbarhetsindex för resp­ek­tive applikation. Ver­sions­­hanteringsanalys användes för att bestämma andra kvalitets­indi­kat­orer efter den initiala utvecklingen samt två efter­följande underhållsarbeten.   Resultaten visar inga markanta skillnader i förvaltningsbarhet för de initiala applikationerna. I takt med att mer funktionalitet lades till sjönk förvaltnings­barhetsindex snabbare för AngularJS-applikationen, vilket motsvarar en kraft­igare ökning i komplexitet jämfört med React-applikationen. Versions­hanteringsanalys visar att ändringar i dataflödet kräver större mod­ifika­tioner för AngularJS-applikationen på grund av dess förbestämda arki­tek­tur. Utifrån detta drar vi slutsatsen att ramverk är användbara när de under­stödjer utvecklingen mot kända krav men att deras nytta blir begränsad ju mer en applikation växer i storlek.

M.Phil. / The implementation of a maintenance strategy without taking the uniqueness of the specific business into account, will not necessarily result in a high level of performance. The maintenance function should be developed specifically to support the particular business processes and technology in use. There is presently a large gap between the results obtained through the implementation of the maintenance strategy at a major coal-mining complex and the desired targets to be met. To close the gap, this dissertation suggests that support systems should be implemented to sustain growth and stability. The dissertation specifically proposes the creation of a Central Support Function to support the maintenance strategy, which has been implemented together with the Enterprise Management System (EMS) with the System Application Product (SAP) as an enabler.

This is a project performed by me, Richard Præsto, student at Luleå University ofTechnology, with the intentions to suggest an improvement for the maintenancesystem of Volvo Construction Equipment’s articulated haulers. Today, themaintenance process consists of several different maintenance points and isperformed by maintenance technicians all over the world – but since the machinesneed to be taken out of production in order to receive maintenance, the processneeds to be quick. By researching documents, performing field studies and testingnew ideas, several different solutions were found and evaluated, to eventually befiltered down to one final concept. The final concept, which suggested animprovement of the engine oil and engine filter exchange processes, lived up to theexpectations by fulfilling the project goals and objectives. It was concluded that thesolution was a clear improvement and that it was also applicable to the whole rangeof the VCE machines.

In industries, successful logistics management delivers higher performance and value (time, cost, profits, and quality). Projects involving ports logistics systems are complex to manage due to the level and number of entities to manage, such as the expensive equipment units and the interconnection of the flows of goods and information. In these complex projects, it is difficult to conduct experiments on the real logistics system to help management predict future strategies due to high costs, time and infrastructure constrains. Therefore, to achieve the objectives of managing ports logistics system it requires that managers select the best strategic tools and methods. Simulation is one of the best predictive and strategic tools which allows the use of real-time, real-world data collection to stage mathematical analyses of the “what-if” scenarios. This thesis presents a simulation model for a case study on the port container terminal transportation of the port of Gävle in Sweden. In this model, a simulation approach is developed with a high software engineering maintainability that enables companies to analyse and study various scenarios that are motivated by changes in different inputs to measure their impact on the outputs that include throughput, resource utilization and waiting times. This study method adopted a simulation that covered both qualitative and quantitative research approaches. The main contributions of this study are: (i) developing a simulation program helps improve visibility in decision making process at port industry.(ii) providing a guideline for designing the maintainability of simulation models (iii) The simulation model has proved to be an industrial solution for the case company and its various stakeholders.

Nowadays, while software industries are aiming to develop their software continuously, their delivery is hindered by technical debt.  Preventing technical debt would be valuable if it is considered in architectural decisions. On the other side, since microservices architecture is adaptable to build cloud applications and has other advantages, it has become a trend in the software industries. Due to the popularity of microservices and the importance of technical debt in the software industry, this research aims to find the influence of architectural decisions on technical debt in microservices applications. In this research, we explore architectural decisions in microservice applications and their qualities that impact technical debt.   We calculated the repetitiveness of selected microservices architectural decisions and the extra effort that they need to meet qualities to prevent technical debt. Spearman correlation coefficient used to calculate the relation between extra effort on the qualities of architectural decisions in microservice applications that affect technical debt. Furthermore, we calculated the correlation between the repetitiveness of selected architectural decisions and the effort for their qualities to find the effect of repetitiveness on qualities that reduce technical debt.   Our result shows that every architectural decision that we have explored for microservice applications needs some extra effort to increase the quality that can prevent technical debt. Correlation between qualities and repetitiveness of architectural decisions shows that weak correlation, which proves that increasing or decreasing of repetitiveness would not change the demand for extra effort to prevent technical debt.

Code decay is a gradual process that negatively impacts the quality of a software system. Developers need trusted measurement techniques to evaluate whether their systems have decayed. This dissertation aims to assess code decay by discovering software architectural violations. Our methodology uses Lightweight Sanity Check for Implemented Architectures to derive architectural constraints represented by can-use and cannot-use phrases. Our methodology also uses Lattix to discover architectural violations. We also introduce measures that indicate code decay in a software system. We conducted two case studies of proprietary systems (9 versions of System A and 14 versions of System B) to demonstrate our methodology for assessing code decay. Resulting architectural constraints and architectural violations were validated by the expert of each system. Our results show that the net violations of System A increased from one version to other version even though there were architecture changes. However, in System B, the number of net violations decreased after changes in the architecture. The proposed code decay metrics can give managers insight into the process of software development, the history of the software product, and the status of unresolved violations. Our results and qualitative analysis showed that the methodology was effective and required a practical level of effort for moderate sized software systems. Code decay values increase because of an increase in the number of violations over multiple versions. We compared our code decay measures with definitions in the literature, namely coupling metrics. In addition, our empirical results showed that coupling is qualitatively correlated with the size of a system as expected. We note that coupling is an opportunity for architectural violations. We concluded that coupling is not consistently related to violations.

The ability to predict the weather carries great societal benefit. To ascertain reliable predictions the numerical weather prediction models used need evaluation with particular attention paid to their representations of atmospheric processes. This type of process-based model evaluation is performed through comparison of large datasets of observational data and  model results. The Year Of Polar Prediction Project site Model Intercomparison Project (YOPPsiteMIP) works to further process-based model evaluation in polar regions and has, to this end, created extensive datasets for these types of analysis. However, the lack of standardized tools to visualize the analyses carries with it significant limitations for both the usability of the data as well as the standardization of the visualizations created from it. To amend this, a set of visualization tools have been created. They were evaluated in the context of visualization quality and source code maintainability. They were found satisfactory in all cases except for the runtime. These tools further the ability to perform process-based analysis with the YOPPsiteMIP datasets in standardized formats. They are limited to the project specific MDF file type. However, with the continued spread of the MDF file type the tools become increasingly useful in furthering model evaluation on larger scales than YOPPsiteMIP.

[pt] Code smells são estruturas pobres que prejudicam a manutenção do sistema. Sendo assim, code smells devem ser detectados e removidos, através de refatoração, no começo do ciclo de vida do software. Refatoração consiste em modificações no código que visam melhorar a manutenção do software, removendo ou mitigando estruturas pobres. Contudo, as estratégias de detecção e refatoração de smells são subjetivas. Isto é, desenvolvedores trabalhando no mesmo sistema podem divergir acerca da existência de um smell. Essa divergência é influenciada pelo conhecimento do desenvolvedor, incluindo o design do sistema e o código analisado. Como consequência, essa divergência afeta também a aplicação das refatorações. Assim, é preciso customizar a detecção de smell e refatoração a partir do conhecimento dos desenvolvedores. Afinal, o desenvolvedor é quem confirma a nocividade de um smell e define como refatorá-lo. Para isso, decompomos nossa pesquisa em 3 passos: (i) como customizar estratégias de detecção de smells?, (ii) se e com que frequência os desenvolvedores customizam suas refatorações? e (iii) como dar suporte a customização de refatoração?. No primeiro passo avaliamos as técnicas de aprendizagem de máquina quanto a capacidade de customizar sua detecção para cada desenvolvedor. Segundo, nós investigamos como desenvolvedores customizam refatorações, analisando suas modificações de código enquanto aplicam certos tipos de refatoração. Além disso, nós também discutimos como essas customizações estão relacionadas com a inserção, remoção ou mitigação de smells e se são apoiados pelo Eclipse. Terceiro, nós propusemos uma abordagem que permite a aplicação de refatorações customizadas. Nossos resultados indicaram que as técnicas de aprendizagem de máquina são capazes de capturar o conhecimento do desenvolvedor e obter alta acurácia detectando smells. Além disso, desenvolvedores frequentemente customizam refatorações que não são totalmente suportadas pelo Eclipse. Para piorar, customizações complexas, geralmente manuais, tendem a reduzir o efeito positivo da refatoração. Portanto, nossos resultados servem como base para melhorar o suporte de ferramentas: a (i) detecção customizada de smells, levando em consideração o conhecimento do desenvolvedor e (ii) a aplicação de refatoração customizada. / [en] Code smells are poor structures that harm software maintenance. Therefore, code smells should be detected and removed, through refactoring, early in the software lifecycle. Refactoring consists of a sequence of code modifications that aim to improve software maintenance by removing or mitigating poor code structures. However, the strategies for detecting and refactoring smells are subjective. Even developers working on the same software may diverge on their opinions about the existence of a smell. In fact, this divergence is mostly influenced by the developer s knowledge, including the system s design and the analyzed source code. As a consequence, the same divergence affects the application of the corresponding refactorings. Therefore, there is a need to support the customization of smell detection and refactoring based on the developer s knowledge. The developer is who, after all, becomes the decision maker on confirming the harmfulness of a smelly structure and how to refactor it out. In order to address this issue, we split our research in 3 steps: (i) how to customize smell detection strategies? (ii) whether and how often developers customize their refactorings? and (iii) how to support refactoring customization? In the first step, we evaluated the use of machine learning techniques for properly customizing smell detection for each developer. Second, we investigated how developers customize refactorings by analyzing their code modifications while applying certain refactoring types. Besides, we also discussed how these customizations are related to the introduction, removal or mitigation of smells, and whether they are currently supported by Eclipse, a popular IDE. Third, we proposed an approach that allows the application of custom refactoring. Our results indicated that machine learning techniques are able to efficiently capture the developer s knowledge and achieve high smell detection accuracy. Also, even though developers frequently customize refactorings, their customizations are often not supported by Eclipse. To make it worse, complex customizations, which are manually performed, tend to reduce the positive effect of the refactoring. Therefore, our contributions serve as a basis for improving tool support for: (i) customized detection of smells considering the developer s knowledge, and (ii) application of customized refactoring.

Due to the surge in the development of software, people in the software industry have a need for higher coding quality in different programming languages. A “code with good quality” can be defined as code that is written in a way that follows the rules or, in other words, conventions for, i.e., comments, proper indentation, clear notations, simplicity, naming, etc. There are coding style guidelines extracted from Java and Oracle code conventions to have readable, maintainable source code; however, the current studies do not answer the question of to what extent the open-source systems follow these guidelines. Finding the violations of conventions at the early stages of software development is essential because the changes are costly and impossible in the later stages. As a result, adhering to coding conventions will facilitate code readability and maintainability. Thus, this study intends to analyze the results from several code quality tools, make a comparison among them and, based on the outcomes, develop a new tool that covers the probable missing conventions in the studied code-checking tools.

No description available.