Anas Shatnawi

Recovering Architectural Variability of a Family of Product Variants

A Software Product Line (SPL) aims at applying a pre-planned systematic reuse of large-grained software artifacts to increase the software productivity and reduce the development cost. The idea of SPL is to analyze the business domain of a family of products to identify the common and the variable parts between the products. However, it is common for companies to develop, in an ad-hoc manner (e.g. clone and own), a set of products that share common functionalities and differ in terms of others. Thus, many recent research contributions are proposed to re-engineer existing product variants to a SPL. Nevertheless, these contributions are mostly focused on managing the variability at the requirement level. Very few contributions address the variability at the architectural level despite its major importance. Starting from this observation, we propose, in this paper, an approach to reverse engineer the architecture of a set of product variants. Our goal is to identify the variability and dependencies among architectural-element variants at the architectural level. Our work relies on Formal Concept Analysis (FCA) to analyze the variability. To validate the proposed approach, we experimented on two families of open-source product variants; Mobile Media and Health Watcher. The results show that our approach is able to identify the architectural variability and the dependencies.

Reverse engineering reusable software components from object-oriented APIs

Object-oriented Application Programing Interfaces (APIs) support software reuse by providing pre-implemented functionalities. Due to the huge number of included classes, reusing and understanding large APIs is a complex task. Otherwise, software components are accepted to be more reusable and understandable entities than object-oriented ones. Thus, in this paper, we propose an approach for reengineering object-oriented APIs into component-based ones. We mine components as a group of classes based on the frequency they are used together and their ability to form a quality-centric component. To validate our approach, we experimented on 100 Java applications that used four APIs.

Mining reusable software components from object-oriented source code of a set of similar software

One of the most important approaches that support software reuse is Component Based Software Engineering (CBSE). Nevertheless the lack of component libraries is one of the major obstacles to widely use CBSE in the industry. To help filling this need, many approaches have been proposed to identify components from existing object-oriented software. These approaches identify components from singular software. Therefore the reusability of these components may be limited. In this paper, we propose an approach to mine reusable components from a set of similar object-oriented software, which were developed in the same domain, ideally by the same developers. Our goal is to enhance the reusability of mined components compared to those mined from single software. In order to validate our approach, we have applied it onto two open source Java applications of different sizes; small and large-scale ones. The results show that the components mined from the analysis of similar software are more reusable than those which are mined from single ones.

Migrating large object-oriented Applications into component-based ones: instantiation and inheritance transformation

Large object-oriented applications have complex and numerous dependencies, and usually do not have explicit software architectures. Therefore they are hard to maintain, and parts of them are difficult to reuse. Component-based development paradigm emerged for improving these aspects and for supporting effective maintainability and reuse. It provides better understandability through a high-level architecture view of the application. Thereby migrating object-oriented applications to component-based ones will contribute to improve these characteristics (maintainability and reuse). In this paper, we propose an approach to automatically transform object-oriented applications to component-based ones. More particularly, the input of the approach is the result provided by software architecture recovery: a component-based architecture description. Then, our approach transforms the object-oriented source code in order to produce deployable components. We focus in this paper on the transformation of source code related to instantiation and inheritance dependencies between classes that are in different components. We experimented the proposed solution in the transformation of a collection of Java applications into the OSGi framework. The experimental results are discussed in this paper.

Migrating Large Object-Oriented Applications into Component-Based Ones

Large object-oriented applications have complex and numerous dependencies, and usually do not have explicit software architectures. Therefore they are hard to maintain, and parts of them are difficult to reuse. Component-based development paradigm emerged for improving these aspects and for supporting effective maintainability and reuse. It provides better understandability through a high-level architecture view of the application. Thereby migrating object-oriented applications to component-based ones will contribute to improve these characteristics (maintainability and reuse). In this paper, we propose an approach to automatically transform object-oriented applications to component-based ones. More particularly, the input of the approach is the result provided by software architecture recovery: a component-based architecture description. Then, our approach transforms the object-oriented source code in order to produce deployable components. We focus in this paper on the transformation of source code related to instantiation and inheritance dependencies between classes that are in different components. We experimented the proposed solution in the transformation of a collection of Java applications into the OSGi framework. The experimental results are discussed in this paper.

Recovering software product line architecture of a family of object-oriented product variants

Software Product Line Engineering (SPLE) aims at applying a pre-planned systematic reuse of large-grained software artifacts to increase the software productivity and reduce the development cost. The idea of SPLE is to analyze the business domain of a family of products to identify the common and the variable parts between the products. However, it is common for companies to develop, in an ad-hoc manner (e.g. clone and own), a set of products that share common services and differ in terms of others. Thus, many contributions are proposed to re-engineer existing product variants to a software product line. Nevertheless, these contributions are mostly focused on managing the variability at the requirement level. Few contributions address the variability at the architectural level despite its major importance. Starting from this observation, we propose an approach to reverse engineer the architecture of a set of product variants. Our goal is to identify variability and dependencies among architectural-element variants. Our work relies on formal concept analysis to analyze the variability. To validate the proposed approach, we experimented on two families of open-source product variants; Mobile Media and Health Watcher. %The results show that our approach is able to identify the architectural variability and the dependencies.

Mining Software Components from Object-Oriented APIs

Object-oriented Application Programing Interfaces (APIs) support software reuse by providing pre-implemented functionalities. Due to the huge number of included classes, reusing and understanding large APIs is a complex task. Otherwise, software components are admitted to be more reusable and understandable entities than object-oriented ones. Thus, in this paper, we propose an approach for reengineering object- oriented APIs into component-based ones. We mine components as a group of classes based on the frequency they are used together and their ability to form a quality-centric component. To validate our approach, we experimented on 100 Java applications that used Android APIs.

Materializing Architecture Recovered from Object-Oriented Source Code in Component-Based Languages

In the literature of software engineering, many approaches have been proposed for the recovery of software architectures. These approaches propose to group classes into highly-cohesive and loosely-coupled clusters considered as architectural components. The recovered architecture plays mainly a documentation role, as high-level design views that enhance software understandability. In addition, architecture recovery can be considered as an intermediate step for migration to component-based platforms. This migration allows to fully benefit from all advantages brought by software component concept. For that, the recovered clusters should not be considered as simple packaging and deployment units. They should be treated as real components: true structural and behavior units that are instantiable from component descriptors and connected together to materialize the architecture of the software. In this paper, we propose an approach for revealing component descriptors, component instances and component-based architecture to materialize the recovered architecture of an object-oriented software in component-based languages. We applied our solution onto two well known component-based languages, OSGi and SOFA.

How to Implement Dependencies in Server Pages of JEE Web Applications.

Java Enterprise Edition (JEE) applications are implemented in terms of a set of components developed based on several JEE technologies includ- ing, but not limited to, Servlet, JSP, JSF, EJB, JavaBeans. These JEE technologies rely on a varied set of communication mechanisms to commu- nicate between each others. Examples of these communication mechanisms are HTTP requests, Remote Method Invocation (RMI), Java DateBase Connectivity (JDBC), etc. These communication mechanisms represent program dependencies between JEE components. However, one communi- cation mechanism can be implemented following different implementation ways by different JEE technologies. Therefore, to be able to detect related dependencies, we identify these implementation ways used by a set of JEE technologies. In this technical report, we focus on the Web tier technologies that are Servlets, JSPs and JSFs. Also, we present how these technologies access the JavaBeans and Manage Beans components.

Identifying KDM Model of JSP Pages.

In this report, we propose our approach that identifies a KDM model of JSP pages. Our approach is based on two main steps. The first one aims to reduce the problem space by translating JSP pages into Java Servlets where we can use existing tools to identify a KDM model. The second step aims to complete the resulting KDM model by identifying dependencies of JSP tags that are not codified by the translation step.