573,517 research outputs found

    The Yale-Potsdam Stellar Isochrones (YaPSI)

    Get PDF
    We introduce the Yale-Potsdam Stellar Isochrones (YaPSI), a new grid of stellar evolution tracks and isochrones of solar-scaled composition. In an effort to improve the Yonsei-Yale database, special emphasis is placed on the construction of accurate low-mass models (Mstar < 0.6 Msun), and in particular of their mass-luminosity and mass-radius relations, both crucial in characterizing exoplanet-host stars and, in turn, their planetary systems. The YaPSI models cover the mass range 0.15 to 5.0 Msun, densely enough to permit detailed interpolation in mass, and the metallicity and helium abundance ranges [Fe/H] = -1.5 to +0.3, and Y = 0.25 to 0.37, specified independently of each other (i.e., no fixed Delta Y/Delta Z relation is assumed). The evolutionary tracks are calculated from the pre-main sequence up to the tip of the red giant branch. The isochrones, with ages between 1 Myr and 20 Gyr, provide UBVRI colors in the Johnson-Cousins system, and JHK colors in the homogeneized Bessell & Brett system, derived from two different semi-empirical Teff-color calibrations from the literature. We also provide utility codes, such as an isochrone interpolator in age, metallicity, and helium content, and an interface of the tracks with an open-source Monte Carlo Markov-Chain tool for the analysis of individual stars. Finally, we present comparisons of the YaPSI models with the best empirical mass- luminosity and mass-radius relations available to date, as well as isochrone fitting of well-studied steComment: 17 pages, 14 figures; accepted for publication in the Astrophysical Journa

    Open Source Software Evolution and Its Dynamics

    Get PDF
    This thesis undertakes an empirical study of software evolution by analyzing open source software (OSS) systems. The main purpose is to aid in understanding OSS evolution. The work centers on collecting large quantities of structural data cost-effectively and analyzing such data to understand software evolution dynamics (the mechanisms and causes of change or growth). We propose a multipurpose systematic approach to extracting program facts (e. g. , function calls). This approach is supported by a suite of C and C++ program extractors, which cover different steps in the program build process and handle both source and binary code. We present several heuristics to link facts extracted from individual files into a combined system model of reasonable accuracy. We extract historical sequences of system models to aid software evolution analysis. We propose that software evolution can be viewed as Punctuated Equilibrium (i. e. , long periods of small changes interrupted occasionally by large avalanche changes). We develop two approaches to study such dynamical behavior. One approach uses the evolution spectrograph to visualize file level changes to the implemented system structure. The other approach relies on automated software clustering techniques to recover system design changes. We discuss lessons learned from using these approaches. We present a new perspective on software evolution dynamics. From this perspective, an evolving software system responds to external events (e. g. , new functional requirements) according to Self-Organized Criticality (SOC). The SOC dynamics is characterized by the following: (1) the probability distribution of change sizes is a power law; and (2) the time series of change exhibits long range correlations with power law behavior. We present empirical evidence that SOC occurs in open source software systems

    Empirical evaluation of an architectural technical debt index in the context of the Apache and ONAP ecosystems

    Get PDF
    Background. Architectural Technical Debt (ATD) in a software-intensive system denotes architectural design choices which, while being suitable or even optimal when adopted, lower the maintainability and evolvability of the system in the long term, hindering future development activities. Despite the growing research interest in ATD, how to gain an informative and encompassing viewpoint of the ATD present in a software-intensive system is still an open problem. Objective. In this study, we evaluate ATDx, a data-driven approach providing an overview of the ATD present in a software-intensive system. The approach, based on the analysis of a software portfolio, calculates severity levels of architectural rule violations via a clustering algorithm, and aggregates results into different ATD dimensions. Method. To evaluate ATDx, we implement an instance of the approach based on SonarQube, and run the analysis on the Apache and ONAP ecosystems. The analysis results are then shared with the portfolio contributors, who are invited to participate in an online survey designed to evaluate the representativeness and actionability of the approach. Results. The survey results confirm the representativeness of the ATDx, in terms of both the ATDx analysis results and the used architectural technical debt dimensions. Results also showed the actionability of the approach, although to a lower extent when compared to the ATDx representativeness, with usage scenarios including refactoring, code review, communication, and ATD evolution analysis. Conclusions. With ATDx, we strive for the establishment of a sound, comprehensive, and intuitive architectural view of the ATD identifiable via source code analysis. The collected results are promising, and display both the representativeness and actionability of the approach. As future work, we plan to consolidate the approach via further empirical experimentation, by considering other development contexts (e.g., proprietary portfolios and other source code analysis tools), and enhancing the ATDx report capabilities

    Open-source software product line extraction processes: the ArgoUML-SPL and Phaser cases

    Get PDF
    Software Product Lines (SPLs) are rarely developed from scratch. Commonly, they emerge from one product when there is a need to create tailored variants, or from existing variants created in an ad-hoc way once their separated maintenance and evolution become challenging. Despite the vast literature about re-engineering systems into SPLs and related technical approaches, there is a lack of detailed analysis of the process itself and the effort involved. In this paper, we provide and analyze empirical data of the extraction processes of two open source case studies, namely ArgoUML and Phaser. Both cases emerged from the transition of a monolithic system into an SPL. The analysis relies on information mined from the version control history of their respective source-code repositories and the discussion with developers that took part in the process. Unlike previous works that focused mostly on the structural results of the final SPL, the contribution of this study is an in-depth characterization of the processes. With this work, we aimed at providing a deeper understanding of the strategies for SPL extraction and their implications. Our results indicate that the source code changes can range from almost a fourth to over half of the total lines of code. Developers may or may not use branching strategies for feature extraction. Additionally, the problems faced during the extraction process may be due to lack of tool support, complexity on managing feature dependencies and issues with feature constraints. We made publicly available the datasets and the analysis scripts of both case studies to be used as a baseline for extractive SPL adoption research and practice.This research was partially funded by CNPq, grant no. 408356/2018-9; FAPPR, grant no. 51435; and FAPERJ PDR-10 Fellowship 202073/2020. Open access funding provided by Johannes Kepler University Lin

    Automatically Documenting Software Artifacts

    Get PDF
    Software artifacts, such as database schema and unit test cases, constantly change during evolution and maintenance of software systems. Co-evolution of code and DB schemas in Database-Centric Applications (DCAs) often leads to two types of challenging scenarios for developers, where (i) changes to the DB schema need to be incorporated in the source code, and (ii) maintenance of a DCAs code requires understanding of how the features are implemented by relying on DB operations and corresponding schema constraints. On the other hand, the number of unit test cases often grows as new functionality is introduced into the system, and maintaining these unit tests is important to reduce the introduction of regression bugs due to outdated unit tests. Therefore, one critical artifact that developers need to be able to maintain during evolution and maintenance of software systems is up-to-date and complete documentation. In order to understand developer practices regarding documenting and maintaining these software artifacts, we designed two empirical studies both composed of (i) an online survey of contributors of open source projects and (ii) a mining-based analysis of method comments in these projects. We observed that documenting methods with database accesses and unit test cases is not a common practice. Further, motivated by the findings of the studies, we proposed three novel approaches: (i) DBScribe is an approach for automatically documenting database usages and schema constraints, (ii) UnitTestScribe is an approach for automatically documenting test cases, and (iii) TeStereo tags stereotypes for unit tests and generates html reports to improve the comprehension and browsing of unit tests in a large test suite. We evaluated our tools in the case studies with industrial developers and graduate students. In general, developers indicated that descriptions generated by the tools are complete, concise, and easy to read. The reports are useful for source code comprehension tasks as well as other tasks, such as code smell detection and source code navigation

    Effective Control System Framework Selection through Checklist-based Software Quality Evaluation

    Get PDF
    The Herzberg Astronomy and Astrophysics Research Centre (HAA) of the National Research Council (NRC) is Canada's premier center for astronomy and astrophysics. It maintains the largest and most powerful observatories in Canada and represents Canada at many of the world's leading astronomical events. In the context of my pursuit of a master's degree, a collaborative effort unfolded between HAA and myself, centered around the multifaceted project named ARTTA4. In the realm of control systems, the significance of prioritizing the evaluation of open-source software's quality is undeniable. This emphasis arises from the essential role that a thorough appraisal of these components plays in safeguarding the security, stability, and efficiency of such systems. Neglecting this assessment exposes control systems to a range of vulnerabilities, including bugs and compatibility concerns that could result in operational disruptions, security breaches, and potential risks across diverse industries. Ensuring the integrity and performance of control systems demands a rigorous approach to software quality assessment, serving to preempt unforeseen complications and bolstering the overall reliability and functionality of these systems. Through my engagement with HAA, I recognized the pivotal role of an open-source control system toolkit named Tango Controls in shaping their antenna control system. Consequently, a comprehensive evaluation of Tango Controls' software quality emerged as a vital undertaking for guaranteeing the ultimate dependability and maintainability of the resultant control system. Accordingly, we conducted a generalizable checklist-driven software quality assessment approach to examine Tango Controls. This evaluation brought to light three specific limitations within this open-source toolkit. This finding prompted me to investigate a substitute control system toolkit to replace Tango Control. Thus, we adopted a Component-based Software Development (CBSD) methodology to propose two potential substitute solutions. These alternatives were put into practice through the implementation of a control system module at HAA, in parallel with the utilization of Tango Controls. To quantify their efficacy, we used SonarQube to generate a static source code analysis report. Furthermore, we conducted an empirical comparison centered around the development process spanning all three methodologies. Drawing from empirical and quantitative analyses, it became evident that one of the proposed solutions outperformed Tango Controls in terms of efficacy and performance. In conclusion, this thesis stands as a pivotal stepping stone in the realm of open-source software selection for the development of industrial control systems. As we move forward, the path to fully realizing the potential of open-source technologies lies in sustained research efforts and collaborative endeavors. By delving into the criteria commonly referenced by industry practitioners, we can glean insights that refine the selection process. Furthermore, the introduction of a natural language processing-based tool holds promise in revolutionizing how we approach open-source software comparison and adoption. Such a tool aims to streamline the process by autonomously aggregating pertinent information from diverse online sources. Through this holistic approach, we aspire to foster an environment where open-source technologies are harnessed to their fullest extent, driving the evolution of industrial control systems and propelling technological advancement

    An empirically-based characterization and quantification of information seeking through mailing lists during Open Source developers' software evolution

    Get PDF
    Context Several authors have proposed information seeking as an appropriate perspective for studying software evolution. Empirical evidence in this area suggests that substantial time delays can accrue, due to the unavailability of required information, particularly when this information must travel across geographically distributed sites. Objective As a first step in addressing the time delays that can occur in information seeking for distributed Open Source (OS) programmers during software evolution, this research characterizes the information seeking of OS developers through their mailing lists. Method A longitudinal study that analyses 17 years of developer mailing list activity in total, over 6 different OS projects is performed, identifying the prevalent information types sought by developers, from a qualitative, grounded analysis of this data. Quantitative analysis of the number-of-responses and response time-lag is also performed. Results The analysis shows that Open Source developers are particularly implementation centric and team focused in their use of mailing lists, mirroring similar findings that have been reported in the literature. However novel findings include the suggestion that OS developers often require support regarding the technology they use during development, that they refer to documentation fairly frequently and that they seek implementation-oriented specifics based on system design principles that they anticipate in advance. In addition, response analysis suggests a large variability in the response rates for different types of questions, and particularly that participants have difficulty ascertaining information on other developer's activities. Conclusion The findings provide insights for those interested in supporting the information needs of OS developer communities: They suggest that the tools and techniques developed in support of co-located developers should be largely mirrored for these communities: that they should be implementation centric, and directed at illustrating "how" the system achieves its functional goals and states. Likewise they should be directed at determining the reason for system bugs: a type of question frequently posed by OS developers but less frequently responded to

    Empirical studies of open source evolution

    Get PDF
    Copyright @ 2008 Springer-VerlagThis chapter presents a sample of empirical studies of Open Source Software (OSS) evolution. According to these studies, the classical results from the studies of proprietary software evoltion, such as Lehman’s laws of software evolution, might need to be revised, if not fully, at least in part, to account for the OSS observations. The book chapter also summarises what appears to be the empirical status of each of Lehman’s laws with respect to OSS and highlights the threads to validity that frequently emerge in these empirical studies. The chapter also discusses related topics for further research
    corecore