What to Fix? Distinguishing between design and non-design rules in automated tools

Technical debt---design shortcuts taken to optimize for delivery speed---is a critical part of long-term software costs. Consequently, automatically detecting technical debt is a high priority for software practitioners. Software quality tool vendors have responded to this need by positioning their tools to detect and manage technical debt. While these tools bundle a number of rules, it is hard for users to understand which rules identify design issues, as opposed to syntactic quality. This is important, since previous studies have revealed the most significant technical debt is related to design issues. Other research has focused on comparing these tools on open source projects, but these comparisons have not looked at whether the rules were relevant to design. We conducted an empirical study using a structured categorization approach, and manually classify 466 software quality rules from three industry tools---CAST, SonarQube, and NDepend. We found that most of these rules were easily labeled as either not design (55%) or design (19%). The remainder (26%) resulted in disagreements among the labelers. Our results are a first step in formalizing a definition of a design rule, in order to support automatic detection.Comment: Long version of accepted short paper at International Conference on Software Architecture 2017 (Gothenburg, SE

E-REPORT BERBASIS WEB MENGGUNAKAN METODE MODEL VIEW CONTROLLER UNTUK MENGETAHUI PENINGKATAN PERKEMBANGAN PRESTASI ANAK DIDIK

Teknologi dapat dilihat sebagai aktivitas yang membentuk budaya perubahan. Ketepatan, kecepatan, dan kualitas dari suatu system teknologi informasi dibutuhkan dalam menyusun perencanaan, pelaksanaan, dan pemantauan suatu kegiatan, pemecahan masalah, pengambilan keputusan secara tepat, cepat dan terarah. Pengembangan teknologi informasi di bidang pendidikan yaitu penciptaan lembar hasil belajar siswa dengan menggunakan teknologi komputerisasi yaitu E-Report. Pada Sekolah Dasar Negeri 1 Penengahan Kec. Kedaton Bandar Lampung dalam penilaian prilaku dan raport siswa masih dinilai secara manual serta hanya dapat diketahui oleh tenaga pengajar yang bersangkutan. Berdasarkan hal tersebut maka dibangun sebuah aplikasi E-Report dengan metode Model View Controller (MVC). MVC merupakan design pattern yang terdiri dari design pattern yang lain disebut sebagai compound pattern.  MVC meliputi 3 design pattern yaitu Composite pattern, Strategy pattern, dan observer pattern. MVC digunakan pada aplikasi web karena memisahkan bagian yang menjadi controller, model, view

Detection of microservice smells through static analysis

A arquitetura de microsserviços é um modelo arquitetural promissor na área de software, atraindo desenvolvedores e empresas para os seus princípios convincentes. As suas vantagens residem no potencial para melhorar a escalabilidade, a flexibilidade e a agilidade, alinhando se com as exigências em constante evolução da era digital. No entanto, navegar entre as complexidades dos microsserviços pode ser uma tarefa desafiante, especialmente à medida que este campo continua a evoluir. Um dos principais desafios advém da complexidade inerente aos microsserviços, em que o seu grande número e interdependências podem introduzir novas camadas de complexidade. Além disso, a rápida expansão dos microsserviços, juntamente com a necessidade de aproveitar as suas vantagens de forma eficaz, exige uma compreensão mais profunda das potenciais ameaças e problemas que podem surgir. Para tirar verdadeiramente partido das vantagens dos microsserviços, é essencial enfrentar estes desafios e garantir que o desenvolvimento e a adoção de microsserviços sejam bem-sucedidos. O presente documento pretende explorar a área dos smells da arquitetura de microsserviços que desempenham um papel tão importante na dívida técnica dirigida à área dos microsserviços. Embarca numa exploração de investigação abrangente, explorando o domínio dos smells de microsserviços. Esta investigação serve como base para melhorar um catálogo de smells de microsserviços. Esta investigação abrangente obtém dados de duas fontes primárias: systematic mapping study e um questionário a profissionais da área. Este último envolveu 31 profissionais experientes com uma experiência substancial no domínio dos microsserviços. Além disso, são descritos o desenvolvimento e o aperfeiçoamento de uma ferramenta especificamente concebida para identificar e resolver problemas relacionados com os microsserviços. Esta ferramenta destina-se a melhorar o desempenho dos programadores durante o desenvolvimento e a implementação da arquitetura de microsserviços. Por último, o documento inclui uma avaliação do desempenho da ferramenta. Trata-se de uma análise comparativa efetuada antes e depois das melhorias introduzidas na ferramenta. A eficácia da ferramenta será avaliada utilizando o mesmo benchmarking de microsserviços utilizado anteriormente, para além de outro benchmarking para garantir uma avaliação abrangente.The microservices architecture stands as a beacon of promise in the software landscape, drawing developers and companies towards its compelling principles. Its appeal lies in the potential for improved scalability, flexibility, and agility, aligning with the ever-evolving demands of the digital age. However, navigating the intricacies of microservices can be a challenging task, especially as this field continues to evolve. A key challenge arises from the inherent complexity of microservices, where their sheer number and interdependencies can introduce new layers of intricacy. Furthermore, the rapid expansion of microservices, coupled with the need to harness their advantages effectively, demands a deeper understanding of the potential pitfalls and issues that may emerge. To truly unlock the benefits of microservices, it is essential to address these challenges head-on and ensure a successful journey in the world of microservices development and adoption. The present document intends to explore the area of microservice architecture smells that play such an important role in the technical debt directed to the area of microservices. It embarks on a comprehensive research exploration, delving into the realm of microservice smells. This research serves as the cornerstone for enhancing a microservice smell catalogue. This comprehensive research draws data from two primary sources: a systematic mapping research and an industry survey. The latter involves 31 seasoned professionals with substantial experience in the field of microservices. Moreover, the development and enhancement of a tool specifically designed to identify and address issues related to microservices is described. This tool is aimed at improving developers' performance throughout the development and implementation of microservices architecture. Finally, the document includes an evaluation of the tool's performance. This involves a comparative analysis conducted before and after the tool's enhancements. The tool's effectiveness will be assessed using the same microservice benchmarking as previously employed, in addition to another benchmark to ensure a comprehensive evaluation

On the relation between architectural smells and source code changes

Although architectural smells are one of the most studied type of architectural technical debt, their impact on maintenance effort has not been thoroughly investigated. Studying this impact would help to understand how much technical debt interest is being paid due to the existence of architecture smells and how this interest can be calculated. This work is a first attempt to address this issue by investigating the relation between architecture smells and source code changes. Specifically, we study whether the frequency and size of changes are correlated with the presence of a selected set of architectural smells. We detect architectural smells using the Arcan tool, which detects architectural smells by building a dependency graph of the system analyzed and then looking for the typical structures of the architectural smells. The findings, based on a case study of 31 open-source Java systems, show that 87% of the analyzed commits present more changes in artifacts with at least one smell, and the likelihood of changing increases with the number of smells. Moreover, there is also evidence to confirm that change frequency increases after the introduction of a smell and that the size of changes is also larger in smelly artifacts. These findings hold true especially in Medium–Large and Large artifacts

Model-based risk assessment

In this research effort, we focus on model-based risk assessment. Risk assessment is essential in any plan intended to manage software development or maintenance process. Subjective techniques are human intensive and error-prone. Risk assessment should be based on architectural attributes that we can quantitatively measure using architectural level metrics. Software architectures are emerging as an important concept in the study and practice of software engineering nowadays, due to their emphasis on large-scale composition of software product, and to their support for emerging software engineering paradigms, such as product line engineering, component based software engineering, and software evolution.;In this dissertation, we generalize our earlier work on reliability-based risk assessment. We introduce error propagation probability in the assessment methodology to account for the dependency among the system components. Also, we generalize the reliability-based risk assessment to account for inherent functional dependencies.;Furthermore, we develop a generic framework for maintainability-based risk assessment which can accommodate different types of software maintenance. First, we introduce and define maintainability-based risk assessment for software architecture. Within our assessment framework, we investigate the maintainability-based risk for the components of the system, and the effect of performing the maintenance tasks on these components. We propose a methodology for estimating the maintainability-based risk when considering different types of maintenance. As a proof of concept, we apply the proposed methodology on several case studies. Moreover, we automate the estimation of the maintainability-based risk assessment methodology