Visualizing Modules and Dependencies of OSGi-based Applications

The architecture of software it not tangible; but in different situations it is preferable to have it tangible. For example, while reviewing it against the intended design, introducing the software to others, or starting to develop on a new part. Basic aspects of a software architecture are the modules the software is constructed of and the dependencies between them. To comprehend these aspects is important especially for software using a technology such as OSGi, which key concept is modularization. In this paper, we describe interactive visualization tools that we developed to comprehend OSGi-based applications with their modules and dependencies. We focus on concepts to treat large number of modules and dependencies: navigation, filtering, and selection. We applied our solution for OSGi-based applications with hundreds of modules containing multiple submodules each. With the resulting visualizations, we can explore the modularization of the software architecture

A Case Study on Software Evolution towards Service-Oriented Architecture.

The evolution of any software product over its lifetime is unavoidable, caused both by bugs to be fixed and by new requirements appearing in the later stages of the product’s lifecycle. Traditional development and architecture paradigms have proven to be not suited for these continual changes, resulting in large maintenance costs. This has caused the rise of approaches such as Service Oriented Architectures (SOA), based on loosely coupled, interoperable services, aiming to address these issues. This paper describes a case study of the evolution of an existing legacy system towards a more maintainable SOA. The proposed process includes the recovery of the legacy system architecture, as a first step to define the specific evolution plan to be executed and validated. The case study has been applied to a medical imaging system, evolving it into a service model

Visualization of OSGi Based Software Architectures in Virtual Reality

Classic software architecture visualizations such as UML diagrams widely used in practice but are not always the best solution, for example to get an high level overview of large component-based software systems. In this talk, we show other suitable technologies for software visualization to understand complex software architectures. Especially, we show how to visualize OSGi based software architectures in Virtual Reality (VR) using VR headsets. We address the question, how software visualizing can help during the development process and what are the resulting benefits for developers and software testers. We focus on four aspects: Development, evaluation, quality assurance, and visualization technology. We demonstrate software visualization using the software ''IslandViz'', which visualizes OSGi based software systems using an island metaphor, where islands on a virtual water level represents OSGi bundles, regions on the islands represents packages, and buildings represents classes. We describe how to get all relevant data for the visualization by repository mining on the whole source tree and data mining on source code level. We store all data in a graph database for further analysis and visualization. Through software visualization we were able to answer many important questions, which have already taken a lot of time in development and test-phases. In addition, it's very important to make the software architecture tangible, which makes it easier way to talk about technical problems in teams formed by people with different knowledge, communications skills, and backgrounds

Studying and Leveraging API Usage Patterns

Software projects make use of libraries extensively. Libraries have intended API surfaces—sets of exposed library interfaces that library developers expect clients to use. However, in practice, clients only use small fractions of intended API surfaces of libraries. Clients also use libraries in unexpected ways sometimes. Understanding usage patterns of library APIs by clients is beneficial to both client and library developers—targeting issues such as version upgrades, breaking changes and software bloating. We have implemented a tool to study both static and dynamic interactions between clients, the libraries they use, and those libraries’ direct dependencies. We use this tool to carry out a detailed study of API usage patterns on 90 clients and 11 libraries. We present a classification framework for developers to classify API uses. We then describe two additional developer-focussed applications of the data that our tool produces: a secondary visualization tool VizAPI, as well as the concept of library fission. Conceivably, VizAPI can allow client and library developers to answer the following queries about the interaction of their code and the libraries they depend on: Will my client code be affected by breaking changes in library APIs? Which APIs in my library’s source code are commonly used by clients? The concept of library fission, by which we mean the splitting of libraries into sub-modules, is based on the usage patterns that we observe. This can potentially help library developers release backward compatible versions of their libraries. It could also help client developers isolate breaking changes and reduce the likelihood of vulnerabilities and version conflicts that may be introduced through direct or transitive dependencies

Applying Software Product Lines to Build Autonomic Pervasive Systems

In this Master Thesis, we have proposed a model-driven Software Product Line (SPL) for developing autonomic pervasive systems. The work focusses on reusing the Variability knowledge from the SPL design to the SPL products. This Variability knowledge enables SPL products to deal with adaptation scenarios (evolution and involution) in an autonomic way.Cetina Englada, C. (2008). Applying Software Product Lines to Build Autonomic Pervasive Systems. http://hdl.handle.net/10251/12447Archivo delegad

Some issues in the 'archaeology' of software evolution

During a software project's lifetime, the software goes through many changes, as components are added, removed and modified to fix bugs and add new features. This paper is intended as a lightweight introduction to some of the issues arising from an `archaeological' investigation of software evolution. We use our own work to look at some of the challenges faced, techniques used, findings obtained, and lessons learnt when measuring and visualising the historical changes that happen during the evolution of software

Some issues in the 'archaeology' of software evolution

During a software project's lifetime, the software goes through many changes, as components are added, removed and modified to fix bugs and add new features. This paper is intended as a lightweight introduction to some of the issues arising from an `archaeological' investigation of software evolution. We use our own work to look at some of the challenges faced, techniques used, findings obtained, and lessons learnt when measuring and visualising the historical changes that happen during the evolution of software

Identifying Components from Object-Oriented APIs Based on Dynamic Analysis

The reuse at the component level is generally more effective than the one at the object-oriented class level. This is due to the granularity level where components expose their functionalities at an abstract level compared to the fine-grained object-oriented classes. Moreover, components clearly define their dependencies through their provided and required interfaces in an explicit way that facilitates the understanding of how to reuse these components. Therefore, several component identification approaches have been proposed to identify components based on the analysis object-oriented software applications. Nevertheless, most of the existing component identification approaches did not consider co-usage dependencies between API classes to identify classes/methods that can be reused to implement a specific scenario. In this paper, we propose an approach to identify reusable software components in object-oriented APIs, based on the interactions between client applications and the targeted API. As we are dealing with actual clients using the API, dynamic analysis allows to better capture the instances of API usage. Approaches using static analysis are usually limited by the difficulty of handling dynamic features such as polymorphism and class loading. We evaluate our approach by applying it to three Java APIs with eight client applications from the DaCapo benchmark. DaCapo provides a set of pre-defined usage scenarios. The results show that our component identification approach has a very high precision.Comment: 11 pages, 5 figure