Studying Cross-cutting Contributors in Software Ecosystem

Roshan Dibya Ranjan
Apr 4, 2017
5 min read

Cross-cutting Concerns

Cross-cutting contributors are making cross-cutting concerns in the software ecosystem which is changing the modularity, Hence hampering the quality of the products.

Identifying, Assigning And Quantifying Cross-cutting Concerns

Problem:

Due to cross cutting concern, the code related to concern is scattered across the program and after tangled with the code related to other concerns cross cutting is distributing modularity.

Supports:

This is imported to classify the concerns into cross cutting and non-cross cutting. Also,to remove ambiguities than previous approaches and to study the degree to which the concerns cross cuts the program.

Difficulties:

It is difficult directly to apply DOS and DOF before applying DOS, we first check all the code is related to that concern and before applying DOF, we need to check the concerns related to all the code in that component.

Concern as an element from a program logical specification.

Components which are meaningful depending upon the languages in the program is expressed.

Our modes allows concern identification assignment and qualification at multiple granularity levels.

Concern is scattered if it is related to multiple target elements.

Tangled if both it and at least one other concern are related to the same target element.

Cross cutting concern that is scattered.

We define closeness metrics in terms of our model and extend them to from basic concern metrics our metrics as independent of the particular methodology used to identify and assign concerns

DOS - Degree of scattering

CONC. (Concentration) - it measures how many source lines with concern as present in a particular component.

Concentration do not allow concerns to be compared to some this we created DOS metrics

DOS:

It is the measure of the variance of the concentration of a concern over all components art worst can. DOF (Degree of focus)

DEDI:

Dedication measures how many source lines within a component are related to concern. DOF: It is used to get how well the concerns are separated in a component.

ADOF: By averaging the degree of focus, we obtain how concerns are separated in the program. *A program should have low ADOS and higher ADOF.

Methodology

Concern identification

The concern domain should have objective and definitive membership criteria.

The concern domain should be finite.

Concern Assignment: Primitive components

Container components

Declarations

Subclasses

Virtual methods

These guidelines ensure consistency whether the assignment is performed at statement,method,class level,or highers.

Benchmark/evaluation: Hypothesis : Our concern metrics are max descriptive than previous metrics.

To evaluate hypothesis 1, we used c program called goblin, which is a platform for developing virtual reality applications.

-exception/error detection

-exception/ error handling

-clean shutdown

Testing hypothesis 1, we compared DOS with the concern diffusion over components [CDC] metrics.

These metrics are comparable because they both measure properties of concern at clas level.

Second hypothesis

Our concern metrics are more descriptive than traditional oo matrices.

For testing second hypothesis we compared DOF with the popular as metrics, coupling between object classes [CBO] which counts the no. of classes referenced by a class at compilation time.

Both metrics measure class dependencies on classes for CBO. and on concerns. Thus both are comparable.

Results:

95% of the requirements were scattered across multiple classes .

100% across multiple methods.

My view :

Explore the usefulness of metrics to predict change impact Concern code mapping should be developer an option to make changes in the right place.

Fan in Analysis

Aspect mining:

Reverse engineering process that at finding cross cutting concerns in the existing system.

This approach is based on determining methods that are called from many different places having high FAN-in, which is the main symptom of cross cutting concerns. ease a semi automatic process.

THREE PROCESSES: Metric calculation

Method filtering

Call site analysis(seed analysis)

Fan - in Analysis implementation is done to three open source java system having around 20000 lines of code.

Each of the three processes are supported by the tools and a significant numbers of cross cutting concerns are recognized by fan in Analysis.

IDENTIFYING CROSS CUTTING CONCERNS

PROBLEM

Finding cross cutting concerns in Non-aspect oriented code?

After identifying the concerns,they can be used for the program understanding or refactoring purposes.

IMPORTED:

It is imported for finding out methods that are called from different call sites and functionality is needed across different methods by computing the fan-in metric using the system static call graph.

METHODOLOGY:

We have go through three processes to find out the cross cutting concerns as FAN.in analysis is a semi-automated process.

Process 1

We identify the methods with higher fan.in value

Process 2

Filler out methods that may have high in out for which it is unlikely that there is a systematic pattern in their usage.

Process 3

Inspect the call sites of high fan.in methods to determine if the methods in question does implement cross cutting functionality.

Application of Fan - in Analysis

Open source systems

..The web shop PETSTORE

..The drawing application JHOTDRAW

..The servlet container TOMCAT

TERMINOLOGY:

What constitutes a concerns?

Concern intent: Objective of the concern.

Concern extent: Representation of that concern in the system's source code.

ASPECT MINING:

Search for the code elements that belongs to the extent of concern which crosscuts the modulating construct.

It aims at finding cross cutting concerns in aspect oriented software non-aspect oriented code .

Developed to avoid the maintenance problems carried by scattering and tangling by maching use of new aspect of modularization construct.

QUERY BASED APPROACHES

Only rely on search patterns provided by the user.

ASPECT BROWSER

..uses lexical pattern matching for querying the code map metaphor for visualizing the results

CME - Concern manipulation environment

GENERATION APPROACHES

CLONE DETECTION - Based on program dependence graphs and the comparison of individuals statements abstract systems trees for mining aspects in JAVA SOURCE CODE.

It uses program analysis techniques to look for symptoms of code scattering and tangling and identifying code elements exhibiting symptoms that can act as candidate aspect seeds

THREE CLONE DETECTION TOOLS … implementing matching of tokens

… abstract syntax trees

... program dependence graphs.

Fan in metric for Aspect mining

We count the number of different method bodies that call for some other method and it also deal with call to polymorphic methods.

METHOD FILTERING

After calculating fan-in values of alll methods ,we apply fillers in carries to obtain a smaller set of methods with a higher chance of implementing cross cutting behavior Absolute fan-in value-10.

STUDY

.. found 10 to be useful tradeoff between the no. of concerns that one can find the no. of methods that need to be inspected.

.. we filter getters and setters from the list of methods. It is based on on naming conventions or an analysis of the methods implementation.

SEED ANALYSIS:

..Analysis follows no. of guidelines.

..conduct manual analysis of the remaining set of methods.

..reasoning can take a top down or bottom up approach.

PETSTORE

JHOTDRAW

TOMCAT

RESULT:

This approach paper shows that after appropriate filtering more than 50% of the methods are cross cutting concerns.

On the variation and specialization of workload.

A case study of the GNOME ecosystem community

GNOME

Open source ecosystem
Social point of view

Historical data about contributors to all GNOME projects.

...Identity matching

..Associating different activity types to the contributors.

..Traditional ,source code related information

..Mining

..Analyzing the actual source code

GNOME PROGRAMMING GUIDELINES

..GNOME stack

..programmers to know about development processes, conventions and philosophies .

..knowing GNOME ecosystem-programmers can use GNOME API’S and development of applications are easier and more natural

Differences - Occasional contributors, frequent contributors

The Onion Patch/The Onion Model

Individuals joining an open source community follow a socialization process.

*Newcomers join project by 1st contributing at the periphery through

.. mailing list discussions

..bug tracker

*Newcomers develop slice and reputation to the community, they tend to contribute code and design decisions

*Modern open source landscape only have few projects which operate independently, otherwise others are under the umbrella of software ecosystems which is the main reason for the cross cutting concerns