169 research outputs found

    Learning and Activity Patterns in OSS Communities and their Impact on Software Quality

    Get PDF
    This paper presents a framework to identify and analyse learning and activity patterns that characterise participation and collaboration of individuals in Open Source Software (OSS) communities.  It first describes how participants’ activities enable and drive a learning process that occurs in individual participants as well as in the OSS project community as a whole. It then explores how to identify and analyse learning patterns at both individual level and community level. The objective of such analysis is to determine the impact of these patterns on the quality of the OSS product and define a descriptive approach to quality that is concerned less with standards than with the facts of OSS peer-review and peer-production

    OPPL-Galaxy, a Galaxy tool for enhancing ontology exploitation as part of bioinformatics workflows

    Get PDF
    Biomedical ontologies are key elements for building up the Life Sciences Semantic Web. Reusing and building biomedical ontologies requires flexible and versatile tools to manipulate them efficiently, in particular for enriching their axiomatic content. The Ontology Pre Processor Language (OPPL) is an OWL-based language for automating the changes to be performed in an ontology. OPPL augments the ontologists’ toolbox by providing a more efficient, and less error-prone, mechanism for enriching a biomedical ontology than that obtained by a manual treatment. Results We present OPPL-Galaxy, a wrapper for using OPPL within Galaxy. The functionality delivered by OPPL (i.e. automated ontology manipulation) can be combined with the tools and workflows devised within the Galaxy framework, resulting in an enhancement of OPPL. Use cases are provided in order to demonstrate OPPL-Galaxy’s capability for enriching, modifying and querying biomedical ontologies. Conclusions Coupling OPPL-Galaxy with other bioinformatics tools of the Galaxy framework results in a system that is more than the sum of its parts. OPPL-Galaxy opens a new dimension of analyses and exploitation of biomedical ontologies, including automated reasoning, paving the way towards advanced biological data analyses

    Antipatterns in Software Classification Taxonomies

    Get PDF
    Empirical results in software engineering have long started to show that findings are unlikely to be applicable to all software systems, or any domain: results need to be evaluated in specified contexts, and limited to the type of systems that they were extracted from. This is a known issue, and requires the establishment of a classification of software types. This paper makes two contributions: the first is to evaluate the quality of the current software classifications landscape. The second is to perform a case study showing how to create a classification of software types using a curated set of software systems. Our contributions show that existing, and very likely even new, classification attempts are deemed to fail for one or more issues, that we named as the `antipatterns' of software classification tasks. We collected 7 of these antipatterns that emerge from both our case study, and the existing classifications. These antipatterns represent recurring issues in a classification, so we discuss practical ways to help researchers avoid these pitfalls. It becomes clear that classification attempts must also face the daunting task of formulating a taxonomy of software types, with the objective of establishing a hierarchy of categories in a classification.Comment: Accepted for publish at the Journal of Systems and Softwar

    Antipatterns in software classification taxonomies

    Get PDF
    Empirical results in software engineering have long started to show that findings are unlikely to be applicable to all software systems, or any domain: results need to be evaluated in specified contexts, and limited to the type of systems that they were extracted from. This is a known issue, and requires the establishment of a classification of software types. This paper makes two contributions: the first is to evaluate the quality of the current software classifications landscape. The second is to perform a case study showing how to create a classification of software types using a curated set of software systems. Our contributions show that existing, and very likely even new, classification attempts are deemed to fail for one or more issues, that we named as the ‘antipatterns’ of software classification tasks. We collected 7 of these antipatterns that emerge from both our case study, and the existing classifications. These antipatterns represent recurring issues in a classification, so we discuss practical ways to help researchers avoid these pitfalls. It becomes clear that classification attempts must also face the daunting task of formulating a taxonomy of software types, with the objective of establishing a hierarchy of categories in a classification

    Impacts and Detection of Design Smells

    Full text link
    Les changements sont faits de façon continue dans le code source des logiciels pour prendre en compte les besoins des clients et corriger les fautes. Les changements continus peuvent conduire aux dĂ©fauts de code et de conception. Les dĂ©fauts de conception sont des mauvaises solutions Ă  des problĂšmes rĂ©currents de conception ou d’implĂ©mentation, gĂ©nĂ©ralement dans le dĂ©veloppement orientĂ© objet. Au cours des activitĂ©s de comprĂ©hension et de changement et en raison du temps d’accĂšs au marchĂ©, du manque de comprĂ©hension, et de leur expĂ©rience, les dĂ©veloppeurs ne peuvent pas toujours suivre les normes de conception et les techniques de codage comme les patrons de conception. Par consĂ©quent, ils introduisent des dĂ©fauts de conception dans leurs systĂšmes. Dans la littĂ©rature, plusieurs auteurs ont fait valoir que les dĂ©fauts de conception rendent les systĂšmes orientĂ©s objet plus difficile Ă  comprendre, plus sujets aux fautes, et plus difficiles Ă  changer que les systĂšmes sans les dĂ©fauts de conception. Pourtant, seulement quelques-uns de ces auteurs ont fait une Ă©tude empirique sur l’impact des dĂ©fauts de conception sur la comprĂ©hension et aucun d’entre eux n’a Ă©tudiĂ© l’impact des dĂ©fauts de conception sur l’effort des dĂ©veloppeurs pour corriger les fautes. Dans cette thĂšse, nous proposons trois principales contributions. La premiĂšre contribution est une Ă©tude empirique pour apporter des preuves de l’impact des dĂ©fauts de conception sur la comprĂ©hension et le changement. Nous concevons et effectuons deux expĂ©riences avec 59 sujets, afin d’évaluer l’impact de la composition de deux occurrences de Blob ou deux occurrences de spaghetti code sur la performance des dĂ©veloppeurs effectuant des tĂąches de comprĂ©hension et de changement. Nous mesurons la performance des dĂ©veloppeurs en utilisant: (1) l’indice de charge de travail de la NASA pour leurs efforts, (2) le temps qu’ils ont passĂ© dans l’accomplissement de leurs tĂąches, et (3) les pourcentages de bonnes rĂ©ponses. Les rĂ©sultats des deux expĂ©riences ont montrĂ© que deux occurrences de Blob ou de spaghetti code sont un obstacle significatif pour la performance des dĂ©veloppeurs lors de tĂąches de comprĂ©hension et de changement. Les rĂ©sultats obtenus justifient les recherches antĂ©rieures sur la spĂ©cification et la dĂ©tection des dĂ©fauts de conception. Les Ă©quipes de dĂ©veloppement de logiciels doivent mettre en garde les dĂ©veloppeurs contre le nombre Ă©levĂ© d’occurrences de dĂ©fauts de conception et recommander des refactorisations Ă  chaque Ă©tape du processus de dĂ©veloppement pour supprimer ces dĂ©fauts de conception quand c’est possible. Dans la deuxiĂšme contribution, nous Ă©tudions la relation entre les dĂ©fauts de conception et les fautes. Nous Ă©tudions l’impact de la prĂ©sence des dĂ©fauts de conception sur l’effort nĂ©cessaire pour corriger les fautes. Nous mesurons l’effort pour corriger les fautes Ă  l’aide de trois indicateurs: (1) la durĂ©e de la pĂ©riode de correction, (2) le nombre de champs et mĂ©thodes touchĂ©s par la correction des fautes et (3) l’entropie des corrections de fautes dans le code-source. Nous menons une Ă©tude empirique avec 12 dĂ©fauts de conception dĂ©tectĂ©s dans 54 versions de quatre systĂšmes: ArgoUML, Eclipse, Mylyn, et Rhino. Nos rĂ©sultats ont montrĂ© que la durĂ©e de la pĂ©riode de correction est plus longue pour les fautes impliquant des classes avec des dĂ©fauts de conception. En outre, la correction des fautes dans les classes avec des dĂ©fauts de conception fait changer plus de fichiers, plus les champs et des mĂ©thodes. Nous avons Ă©galement observĂ© que, aprĂšs la correction d’une faute, le nombre d’occurrences de dĂ©fauts de conception dans les classes impliquĂ©es dans la correction de la faute diminue. Comprendre l’impact des dĂ©fauts de conception sur l’effort des dĂ©veloppeurs pour corriger les fautes est important afin d’aider les Ă©quipes de dĂ©veloppement pour mieux Ă©valuer et prĂ©voir l’impact de leurs dĂ©cisions de conception et donc canaliser leurs efforts pour amĂ©liorer la qualitĂ© de leurs systĂšmes. Les Ă©quipes de dĂ©veloppement doivent contrĂŽler et supprimer les dĂ©fauts de conception de leurs systĂšmes car ils sont susceptibles d’augmenter les efforts de changement. La troisiĂšme contribution concerne la dĂ©tection des dĂ©fauts de conception. Pendant les activitĂ©s de maintenance, il est important de disposer d’un outil capable de dĂ©tecter les dĂ©fauts de conception de façon incrĂ©mentale et itĂ©rative. Ce processus de dĂ©tection incrĂ©mentale et itĂ©rative pourrait rĂ©duire les coĂ»ts, les efforts et les ressources en permettant aux praticiens d’identifier et de prendre en compte les occurrences de dĂ©fauts de conception comme ils les trouvent lors de la comprĂ©hension et des changements. Les chercheurs ont proposĂ© des approches pour dĂ©tecter les occurrences de dĂ©fauts de conception, mais ces approches ont actuellement quatre limites: (1) elles nĂ©cessitent une connaissance approfondie des dĂ©fauts de conception, (2) elles ont une prĂ©cision et un rappel limitĂ©s, (3) elles ne sont pas itĂ©ratives et incrĂ©mentales et (4) elles ne peuvent pas ĂȘtre appliquĂ©es sur des sous-ensembles de systĂšmes. Pour surmonter ces limitations, nous introduisons SMURF, une nouvelle approche pour dĂ©tecter les dĂ©fauts de conception, basĂ© sur une technique d’apprentissage automatique — machines Ă  vecteur de support — et prenant en compte les retours des praticiens. GrĂące Ă  une Ă©tude empirique portant sur trois systĂšmes et quatre dĂ©fauts de conception, nous avons montrĂ© que la prĂ©cision et le rappel de SMURF sont supĂ©rieurs Ă  ceux de DETEX et BDTEX lors de la dĂ©tection des occurrences de dĂ©fauts de conception. Nous avons Ă©galement montrĂ© que SMURF peut ĂȘtre appliquĂ© Ă  la fois dans les configurations intra-systĂšme et inter-systĂšme. Enfin, nous avons montrĂ© que la prĂ©cision et le rappel de SMURF sont amĂ©liorĂ©s quand on prend en compte les retours des praticiens.Changes are continuously made in the source code to take into account the needs of the customers and fix the faults. Continuous change can lead to antipatterns and code smells, collectively called “design smells” to occur in the source code. Design smells are poor solutions to recurring design or implementation problems, typically in object-oriented development. During comprehension and changes activities and due to the time-to-market, lack of understanding, and the developers’ experience, developers cannot always follow standard designing and coding techniques, i.e., design patterns. Consequently, they introduce design smells in their systems. In the literature, several authors claimed that design smells make object-oriented software systems more difficult to understand, more fault-prone, and harder to change than systems without such design smells. Yet, few of these authors empirically investigate the impact of design smells on software understandability and none of them authors studied the impact of design smells on developers’ effort. In this thesis, we propose three principal contributions. The first contribution is an empirical study to bring evidence of the impact of design smells on comprehension and change. We design and conduct two experiments with 59 subjects, to assess the impact of the composition of two Blob or two Spaghetti Code on the performance of developers performing comprehension and change tasks. We measure developers’ performance using: (1) the NASA task load index for their effort; (2) the time that they spent performing their tasks; and, (3) their percentages of correct answers. The results of the two experiments showed that two occurrences of Blob or Spaghetti Code design smells impedes significantly developers performance during comprehension and change tasks. The obtained results justify a posteriori previous researches on the specification and detection of design smells. Software development teams should warn developers against high number of occurrences of design smells and recommend refactorings at each step of the development to remove them when possible. In the second contribution, we investigate the relation between design smells and faults in classes from the point of view of developers who must fix faults. We study the impact of the presence of design smells on the effort required to fix faults, which we measure using three metrics: (1) the duration of the fixing period; (2) the number of fields and methods impacted by fault-fixes; and, (3) the entropy of the fault-fixes in the source code. We conduct an empirical study with 12 design smells detected in 54 releases of four systems: ArgoUML, Eclipse, Mylyn, and Rhino. Our results showed that the duration of the fixing period is longer for faults involving classes with design smells. Also, fixing faults in classes with design smells impacts more files, more fields, and more methods. We also observed that after a fault is fixed, the number of occurrences of design smells in the classes involved in the fault decreases. Understanding the impact of design smells on development effort is important to help development teams better assess and forecast the impact of their design decisions and therefore lead their effort to improve the quality of their software systems. Development teams should monitor and remove design smells from their software systems because they are likely to increase the change efforts. The third contribution concerns design smells detection. During maintenance and evolution tasks, it is important to have a tool able to detect design smells incrementally and iteratively. This incremental and iterative detection process could reduce costs, effort, and resources by allowing practitioners to identify and take into account occurrences of design smells as they find them during comprehension and change. Researchers have proposed approaches to detect occurrences of design smells but these approaches have currently four limitations: (1) they require extensive knowledge of design smells; (2) they have limited precision and recall; (3) they are not incremental; and (4) they cannot be applied on subsets of systems. To overcome these limitations, we introduce SMURF, a novel approach to detect design smells, based on a machine learning technique—support vector machines—and taking into account practitioners’ feedback. Through an empirical study involving three systems and four design smells, we showed that the accuracy of SMURF is greater than that of DETEX and BDTEX when detecting design smells occurrences. We also showed that SMURF can be applied in both intra-system and inter-system configurations. Finally, we reported that SMURF accuracy improves when using practitioners’ feedback

    Persuasive Explanation of Reasoning Inferences on Dietary Data

    Get PDF
    Explainable AI aims at building intelligent systems that are able to provide a clear, and human understandable, justification of their decisions. This holds for both rule-based and data-driven methods. In management of chronic diseases, the users of such systems are patients that follow strict dietary rules to manage such diseases. After receiving the input of the intake food, the system performs reasoning to understand whether the users follow an unhealthy behaviour. Successively, the system has to communicate the results in a clear and effective way, that is, the output message has to persuade users to follow the right dietary rules. In this paper, we address the main challenges to build such systems: i) the natural language generation of messages that explain the reasoner inconsistency; ii) the effectiveness of such messages at persuading the users. Results prove that the persuasive explanations are able to reduce the unhealthy users’ behaviours

    Insights from an OTTR-centric Ontology Engineering Methodology

    Full text link
    OTTR is a language for representing ontology modeling patterns, which enables to build ontologies or knowledge bases by instantiating templates. Thereby, particularities of the ontological representation language are hidden from the domain experts, and it enables ontology engineers to, to some extent, separate the processes of deciding about what information to model from deciding about how to model the information, e.g., which design patterns to use. Certain decisions can thus be postponed for the benefit of focusing on one of these processes. To date, only few works on ontology engineering where ontology templates are applied are described in the literature. In this paper, we outline our methodology and report findings from our ontology engineering activities in the domain of Material Science. In these activities, OTTR templates play a key role. Our ontology engineering process is bottom-up, as we begin modeling activities from existing data that is then, via templates, fed into a knowledge graph, and it is top-down, as we first focus on which data to model and postpone the decision of how to model the data. We find, among other things, that OTTR templates are especially useful as a means of communication with domain experts. Furthermore, we find that because OTTR templates encapsulate modeling decisions, the engineering process becomes flexible, meaning that design decisions can be changed at little cost.Comment: Paper accepted at the 14th Workshop on Ontology Design and Patterns (WOP 2023

    Get my pizza right: Repairing missing is-a relations in ALC ontologies (extended version)

    Full text link
    With the increased use of ontologies in semantically-enabled applications, the issue of debugging defects in ontologies has become increasingly important. These defects can lead to wrong or incomplete results for the applications. Debugging consists of the phases of detection and repairing. In this paper we focus on the repairing phase of a particular kind of defects, i.e. the missing relations in the is-a hierarchy. Previous work has dealt with the case of taxonomies. In this work we extend the scope to deal with ALC ontologies that can be represented using acyclic terminologies. We present algorithms and discuss a system
    • 

    corecore