Semantic Versioning Checking in a Declarative Package Manager

Semantic versioning is a principle to associate version numbers to different software releases in a meaningful manner. The correct use of version numbers is important in software package systems where packages depend on other packages with specific releases. When patch or minor version numbers are incremented, the API is unchanged or extended, respectively, but the semantics of the operations should not be affected (apart from bug fixes). Although many software package management systems assumes this principle, they do not check it or perform only simple syntactic signature checks. In this paper we show that more substantive and fully automatic checks are possible for declarative languages. We extend a package manager for the functional logic language Curry with features to check the semantic equivalence of two different versions of a software package. For this purpose, we combine CurryCheck, a tool for automated property testing, with program analysis techniques in order to ensure the termination of the checker even in case of possibly non-terminating operations defined in some package. As a result, we obtain a software package manager which checks semantic versioning and, thus, supports a reliable and also specification-based development of software packages

Putting the Semantics into Semantic Versioning

The long-standing aspiration for software reuse has made astonishing strides in the past few years. Many modern software development ecosystems now come with rich sets of publicly-available components contributed by the community. Downstream developers can leverage these upstream components, boosting their productivity. However, components evolve at their own pace. This imposes obligations on and yields benefits for downstream developers, especially since changes can be breaking, requiring additional downstream work to adapt to. Upgrading too late leaves downstream vulnerable to security issues and missing out on useful improvements; upgrading too early results in excess work. Semantic versioning has been proposed as an elegant mechanism to communicate levels of compatibility, enabling downstream developers to automate dependency upgrades. While it is questionable whether a version number can adequately characterize version compatibility in general, we argue that developers would greatly benefit from tools such as semantic version calculators to help them upgrade safely. The time is now for the research community to develop such tools: large component ecosystems exist and are accessible, component interactions have become observable through automated builds, and recent advances in program analysis make the development of relevant tools feasible. In particular, contracts (both traditional and lightweight) are a promising input to semantic versioning calculators, which can suggest whether an upgrade is likely to be safe.Comment: to be published as Onward! Essays 202

Ring: a Unifying Meta-Model and Infrastructure for Smalltalk Source Code Analysis Tools

International audienceSource code management systems record different versions of code. Tool support can then compute deltas between versions. To ease version history analysis we need adequate models to represent source code entities. Now naturally the questions of their definition, the abstractions they use, and the APIs of such models are raised, especially in the context of a reflective system which already offers a model of its own structure. We believe that this problem is due to the lack of a powerful code meta-model as well as an infrastructure. In Smalltalk, often several source code meta-models coexist: the Smalltalk reflective API coexists with the one of the Refactoring Engine or distributed versioning system such as Monticello or Store. While having specific meta-models is an adequate engineered solution, it multiplies meta-models and it requires more maintenance efforts (e.g., duplication of tests, transformation between models), and more importantly hinders navigation tool reuse when meta-models do not offer polymorphic APIs. As a first step to provide an infrastructure to support history analysis, this article presents Ring, a unifying source code meta-model that can be used to support several activities and proposes a unified and layered approach to be the foundation for building an infrastructure for version and stream of change analyses. We re-implemented three tools based on Ring to show that it can be used as the underlying meta-model for remote and off-image browsing, scoping refactoring, and visualizing and analyzing changes. As a future work and based on Ring we will build a new generation of history analysis tools

Metamodel for Tracing Concerns across the Life Cycle

Several aspect-oriented approaches have been proposed to specify aspects at different phases in the software life cycle. Aspects can appear within a phase, be refined or mapped to other aspects in later phases, or even disappear.\ud Tracing aspects is necessary to support understandability and maintainability of software systems. Although several approaches have been introduced to address traceability of aspects, two important limitations can be observed. First, tracing is not yet tackled for the entire life cycle. Second, the traceability model that is applied usually refers to elements of specific aspect languages, thereby limiting the reusability of the adopted traceability model.We propose the concern traceability metamodel (CTM) that enables traceability of concerns throughout the life cycle, and which is independent from the aspect languages that are used. CTM can be enhanced to provide additional properties for tracing, and be instantiated to define\ud customized traceability models with respect to the required aspect languages. We have implemented CTM in the tool M-Trace, that uses XML-based representations of the models and XQuery queries to represent tracing information. CTM and M-Trace are illustrated for a Concurrent Versioning System to trace aspects from the requirements level to architecture design level and the implementation

Flexible Views for View-based Model-driven Development

Modern software development faces the problem of fragmentation of information across heterogeneous artefacts in different modelling and programming languages. In this dissertation, the Vitruvius approach for view-based engineering is presented. Flexible views offer a compact definition of user-specific views on software systems, and can be defined the novel ModelJoin language. The process is supported by a change metamodel for metamodel evolution and change impact analysis

Using the General Intensional Programming System (GIPSY) for Evaluation of Higher-Order Intensional Logic (HOIL) Expressions

The General Intensional Programming System (GIPSY) has been built around the Lucid family of intensional programming languages that rely on the higher-order intensional logic (HOIL) to provide context-oriented multidimensional reasoning of intensional expressions. HOIL combines functional programming with various intensional logics to allow explicit context expressions to be evaluated as first-class values that can be passed as parameters to functions and return as results with an appropriate set of operators defined on contexts. GIPSY's frameworks are implemented in Java as a collection of replaceable components for the compilers of various Lucid dialects and the demand-driven eductive evaluation engine that can run distributively. GIPSY provides support for hybrid programming models that couple intensional and imperative languages for a variety of needs. Explicit context expressions limit the scope of evaluation of math expressions (effectively a Lucid program is a mathematics or physics expression constrained by the context) in tensor physics, regular math in multiple dimensions, etc., and for cyberforensic reasoning as one of the use-cases of interest. Thus, GIPSY is a support testbed for HOIL-based languages some of which enable such reasoning, as in formal cyberforensic case analysis with event reconstruction. In this paper we discuss the GIPSY architecture, its evaluation engine and example use-cases.Comment: 14 pages; 8 figure

OrpheusDB: an attempt towards data version control on relational database

This thesis will cover the deign, manual, and implementation detail of OrpheusDB

Technical Debt Analysis and Project Architecturization of a Jenkins Platform based on Groovy

Actualment, el Deute Tècnic (DT) és un problema latent a la gran majoria de projectes software. A causa del ràpid creixement del mercat, la visió empresarial està cada cop més enfocada a reduir el time-to-market del producte, deixant de banda la qualitat interna del seu codi. Per això, el cost global anual de mantenir aquest codi de mala qualitat, puja aproximadament a 81.000 € milions. La tesi se centra a analitzar profundament una plataforma corporativa amb molt DT i definir-ne una nova arquitectura, tenint en compte els seus requeriments i prioritzant la qualitat del producte mentre es redueix el seu deute tècnic. Per aconseguir això, es faran servir tècniques de refactorització, implementació de noves funcionalitats i la definició de protocols interns per a l'equip. A la tesi queden documentats els passos a seguir per analitzar i rearquitecturitzar un projecte amb unes característiques similars. A més, es crea una forta consciència sobre el deute tècnic i els seus problemes, una qüestió que afecta directament el codi i indirectament la salut mental dels seus desenvolupadors.Currently, Technical Debt (TD) is a latent problem in the vast majority of software projects. Due to the rapid growth of the market, its business vision is focusing on reducing the time-to-market of the product, leaving aside the internal quality of its code. As a result, the global annual cost of maintaining such poor quality code comes to approximately $85 billion. The thesis focuses on deeply analyzing a corporate platform with a heavy TD and defining a new architecture for it based on its requirements, prioritizing the quality of the product while reducing its technical debt. To achieve this, I will use refactoring techniques, implementation of new functionalities and the definition of internal protocols for the team. In the thesis, the steps to follow to analyze and re-architect a project with similar characteristics are documented. In addition, strong awareness is raised regarding the technical debt and its problems, an issue that directly affects the code and indirectly impacts the mental health of its developers