11institutetext: Damian A. Tamburri 22institutetext: TUe - JADS,
’s-Hertogenbosch, Netherlands
22email<EMAIL_ADDRESS>33institutetext: Francesca Arcelli Fontana
44institutetext: University of Milano - Bicocca, Milano, Italy
44email<EMAIL_ADDRESS>55institutetext: Riccardo Roveda
66institutetext: Alten Italia, Milano, Italy
66email<EMAIL_ADDRESS>77institutetext: Valentina Lenarduzzi
(corresponding author) 88institutetext: University of Oulu, Finland
88email<EMAIL_ADDRESS>
# Architecture Smells vs. Concurrency Bugs: an Exploratory Study and Negative
Results

Damian Andrew Tamburri  Francesca Arcelli Fontana  Riccardo Roveda  Valentina
Lenarduzzi

###### Abstract

Technical debt occurs in many different forms across software artifacts. One
such form is connected to software architectures where debt emerges in the
form of structural anti-patterns across architecture elements, namely,
_architecture smells_. As defined in the literature, “Architecture smells are
recurrent architectural decisions that negatively impact internal system
quality”, thus increasing technical debt. In this paper, we aim at exploring
whether there exist manifestations of architectural technical debt beyond
decreased code or architectural quality, namely, whether there is a relation
between architecture smells (which primarily reflect structural
characteristics) and the occurrence of concurrency bugs (which primarily
manifest at runtime). We study 125 releases of 5 large data-intensive software
systems to reveal that (1) several architecture smells may in fact indicate
the presence of concurrency problems likely to manifest at runtime but (2)
smells are not correlated with concurrency in general — rather, for specific
concurrency bugs they must be combined with an accompanying articulation of
specific project characteristics such as project distribution. As an example,
a cyclic dependency could be present in the code, but the specific execution-
flow could be never executed at runtime.

###### Keywords:

Technical Debt Architectural Debt Architectural Smells Concurrency Bugs
Empirical Software Engineering

##  1 Introduction

Software architecture is a fundamental abstraction of software systems, their
visible properties, and operating parts Bass et al. (1998). In this paper we
investigate the existence of a relation between issues in the architecture and
_concurrency bugs_ , i.e., issues that are intimately tied to architectural
behavior as opposed to code flaws (e.g., code smells Palomba et al. (2016)).
This investigation is impactful for several reasons. First technical debt (TD)
may be used to study concurrency bugs from a different perspective; the
architectural technical debt metaphor offers such a perspective by summarizing
the technical compromises made on software artefacts (code, models,
architecture, and more) that, on the one hand, may yield short-term benefits
but, on the other hand, reveal themselves as long-term technical investments
accumulating additional project costs for their resolution Avgeriou et al.
(2016) and which may lead to nasty and unforeseen runtime manifestations whose
costs of occurrence are not clear nor managed in any way.

Similarly, of the many afflictions of TD, software architecture is
considerably important, since it summarizes the entire system and is often the
first artifact to be used for TD resolution Koziolek et al. (2013), but how
that impacts concurrency dimensions of the system remains unknown. What is
more, compromising architecture elements and their structural dept
characteristics may have unforeseen negative impacts many non-functional
characteristics beyond concurrency levels, e.g., performance, reliability, and
maintainability of the entire application; a dept-resolved lens over these may
help further maintenance and evolution practices and their prioritization.

To address the aforementioned gap, in this study we focused our attention on
understanding the degree to which known sub-optimal architecture
circumstances—architecture _smells_ Abebe et al. (2009); Bass et al.
(1998)—impact the concurrency characteristics of data-intensive software
systems. More in particular, we aim at establishing whether there exist
architectural violations that reflect a higher chance of generating
concurrency bugs.

To conduct our empirical inquiry, we use Arcan Arcelli Fontana et al. (2016a),
a tool developed to detect several major architectural smells (AS), structural
indicators that architectural TD may be present. We exercised Arcan over 125
releases of 5 large, open-source software packages. We overlapped the
concurrency bugs coded independently Asadollah et al. (2017) in our dataset
with Arcan smells detections.

If there exists relation between architectural smells and concurrency bugs
then, it will be possible to avoid concurrency bugs by not introducing or
removing the architectural smells. We expect to find correlations between
different architectural smells and concurrency bugs. As example, we expect to
find a good correlation between cyclic dependency and deadlock.

Our results indicate that architecture smells reflect concurrency bugs only if
the projects under analysis exhibit two characteristics at the same time, that
is: (1) they are intrinsically distributed, meaning that they are designed to
support distributed processing and are themselves parallel systems —this is
likely because in distributed systems the negative influence of architecture
smells becomes more grievous due to parallelization, which could be
established through further experimentation; (2) they are updated and released
very often—this is likely because of the frequency of code changes required by
architecture smells which necessarily leads to making more concurrency-related
issues while coding a distributed system.

This manuscript presents 2 major contributions:

  1. 1.

The exploration of empirical relations between architecture smells and
concurrency bugs. This contribution impacts research and practice in several
ways, e.g., by offering an architecture-specific lens to concurrency bug
prediction.

  2. 2.

The subsequent evaluation of Arcan Arcelli Fontana et al. (2016b, a) in
action; Arcan is a tool for automated architecture smells detection.

Structure of the Paper. The rest of this paper is structured as follows.
First, Sec. 2 outlines related work. Sec. 3 outlines our empirical study
design. Finally, Sec. 4 and Sec. 7 outline evaluation results and conclude the
paper, respectively.

##  2 Related Work

Several works offer a motivational basis or background for our work.

###  2.1 Architectural Smells Detection

Many tools have been developed for code smells detection but only a few tools
are currently available for architectural smells detection Azadi et al.
(2019). The following briefly reports on some of them.
AiReviewer111http://www.aireviewer.com is a commercial tool that supports the
detection of both code smells and some design or architectural smells.
Designite222http://www.designite-tools.com is another commercial tool able to
detect several design smells in C# and Java projects. Arcade Le et al. (2015)
is a tool developed for architectural smell detection in Java projects, the
authors propose also a classification of the smells. DV8 Cai and Kazman
(2019a) is a commercial tool able to detect six architectural smells, called
anti-patterns Mo et al. (2015), five patterns defined at the file level and
one at the package level. Other commercial tools are Sotograph, Sonargraph,
Structure 101 and Cast, which are not specialised in architectural smell
detection, but are able to detect different kinds of architectural violations,
such as dependency cycles.

Other tool prototypes have been proposed, e.g., SCOOP Macia et al. (2012a),
and one from Garcia et al. Garcia et al. (2011). Moreover, another tool to
measure software modularity, and to detect architecture anti-patterns were
defined by Cai and Kazman Cai and Kazman (2019b). Finally, Arcan is the tool
we used in this study able to detect different architectural smells through
the analysis of compiled Java files. Through Arcan it is possible to inspect
the results through graphs, more useful respect to other views, allowing to
better identify refactoring opportunities for the architectural smells. The
tool is freely available on request at
http://essere.disco.unimib.it/wiki/arcan.

###  2.2 Empirical studies on Architectural Issues Evaluation

In this section we report key empirical studies done or related to
architectural issues and smells.

Le et al. Le and Medvidovic (2016) propose an approach to build bug prediction
models based on both implicit and explicit features of a software system. The
authors especially consider architectural-based features, with a focus on
architectural smells and architectural decay metrics.

According to architectural changes, Behnamghader et al. Behnamghader et al.
(2017) conduct a large empirical study of changes found in software
architectures spanning many versions of different open-source systems. Their
study reveals several new findings regarding the frequency of architectural
changes in software systems, and the common points of departure in a system
architecture during system’s maintenance and evolution.

Moreover, some works explore the correlations between code smells or code
anomalies and architectural smells.

Macia et al. Macia et al. (2012b) studied the relationships between code
anomalies and architectural smells in 6 software systems (40 versions). They
considered 5 architectural smells and 9 code smells. They empirically found
that each architectural problem represented by each AS often reflects multiple
code anomalies. More than 80% of architectural problems were related to code
anomalies. Oizumi et al. Oizumi et al. (2014) analyzed 7 systems and suggest
that certain topologies of code smells agglomerations are better indicators,
than others, of architectural problems. They have considered six code smells
detected through the rule of Lanza Marinescu Lanza and Marinescu (2006) and 7
architectural smells detected through rules defined by Macia. Arcelli Fontana
et al Fontana et al. (2019) investigated the correlation between architectural
and code smells founding no statistical significant results.

We have not found in the literature any works on the analysis of the
correlation between architectural smells and concurrency bugs — the key goal
behind the work in this manuscript.

###  2.3 Concurrency Bugs in Data-Intensive Systems Evaluation

According to the taxonomy in Tchamgoue et al. Tchamgoue et al. (2011) there
exist four classes of concurrency bugs, namely: (1) data races —that is, a
shared memory is uncoordinately accessed with at least one write by both an
event handler and a non-event code or by multiple event handlers; (2)
atomicity and order violations —that is, the conditions when a program fails
to enforce the programmers’ execution order intention; (3) deadlocks - that
is, when an instruction or interleaving contains a blocking operation that
blocks indefinitely the execution of a program; (4) stack overflow when a
program attempts to use more memory space than is available on the stack.
Several works have touched upon all the afore-mentioned classes of concurrency
bugs, their nature, and nurture as well as their nasty effects on parallel and
concurrent systems’ operation. But little is known still on the architectural
choices or code smells which are more prone to concurrency violations.

In the concurrency bugs detection side, Zhang et al. Zhang et al. (2011) and
later Kidd et al. Kidd et al. (2011) propose tools specifically designed to
address specific classes of concurrency bugs, but their and similar approaches
are limited to detection and avoidance in the context of operative systems
design and operation rather than their maintenance and evolution. Also,
similar works tend to offer domain-specific lens of analysis with limited
generalisability, e.g., the works by Park Park (2012, 2013).

More in line with maintenance, the work by Kelly Kelly et al. (2009)
predicates the successful use of control engineering and control theory with
the goal of limiting the emergence and ultimately eradicating concurrency
bugs, at the same time, however, their work is limited in that it looks at
very low-level abstractions (i.e., programming constructs, bytecode, etc.)
rather than providing an investigation that serves higher levels of
abstraction such as our own (architecture level). Furthermore, along the lines
of maintenance by testing and refactoring, Smith Smith (2014) and later
Fonseca Fonseca (2015) cover an extensive study of concurrency bugs diagnosis
and removal, theoretically assessing their link with architecture-level
constructs and patterns as well as proposing early support for automated
refactoring of concurrency bugs. Similarly to these works, Kelk et al. Kelk et
al. (2013) offer a first, very specific attempt at automated program repair
designed to address specific classes of concurrency bugs. From a more
generalist perspective, Thompson explores the notion of _mechanical sympathy_
, a programming model wherefore the increasingly required synergy between
hardware and software makes the investigation of the issues which reflect on
both of paramount importance.

In line with these works, we choose to further the understanding and state of
the art in software architecture research as well as architecture-driven
evolution and modernization of concurrent systems by looking into the relation
between concurrency bugs and architecture smells in the context of distributed
systems such as Big Data middleware.

Finally, from a concurrency-specific perspective, the state of the art has
concentrated on assessing the recurrence of new types of concurrency bugs
(e.g., Accuracy Bugs Akturk et al. (2016)) and their impact on distributed
systems’ quality properties. Such works reinforce the need of further
understanding into maintaining large-scale distributed system architectures
with a bug- and concurrency-centric lens, e.g., with increasing granularity
level. In the scope of this study we intended to pursue this research
direction starting from the first possible level of abstraction, i.e.,
considering concurrency bugs regardless of their intimate nature (e.g.,
_intra-_ vs. _inter-_ process concurrency bugs or similar distinctions).

###  2.4 Summary and Study Context

From the overview above it is clear that there is an increasing need to study
software architectures in the context of distributed systems to understand how
concurrency bugs are produced and addressed. On one hand, the techniques
currently available mostly take an event-driven approach or focus on specific
classes of bugs, avoiding to touch higher-order artefacts such as software
architectures, which, de-facto, drive the actual development of the system. On
the other hand, software architecture and design constructs (e.g., software
architecture and design metrics, design patterns, code smells, architecture
smells, etc.) can aid in the detection and avoidance of classic concurrency
bugs, especially within the context of emerging concurrent and distributed
systems where reactive-programming Ramson and Hirschfeld (2017) and reactive
architecture styles Debski et al. (2018) are increasingly being considered in
both research and practice Voellmy et al. (2010).

In line with the above limitations, we focus on representatives of both
_intra-_ (i.e., within the scope of a process) and _inter-_ process (i.e.,
between multiple processes) concurrency bugs, to assess if their occurrence is
in any way related to the emergence of software architecture smells.

##  3 Study Design

###  3.1 Research Problem and Question

In the scope of this study, we focus on identifying and _measuring_ the
overlaps and correspondences between architecture smells and concurrency bugs
(defined in section 3) whose diagnosis and repair has not yet found an
exhaustive solution Khoshnood et al. (2015). The _focus_ and _context_ of
concurrency is well justified by the recent emergence of highly concurrent and
decentralized systems, e.g., based often on microservice architectures. In the
scope of such advanced architecture styles, it becomes critical to provide to
the _perspective_ of software architects, ways to understand and quantify the
impact (if any) of known software architecture issues over the emergence and
risk of concurrency bugs. Finding any relation thereof, would essentially
provide more advanced design principles to structure highly concurrent and
distributed systems.

Hence, we aim to answer the following research questions:

RQ1. To what extent do known architectural smells impact on the emergence of
major concurrency bugs?

RQ2. Is the presence of architectural smells independent from the presence of
concurrency bugs?

###  3.2 Architectural Smells Analysis

We describe below the architectural smells (AS) we have considered in this
study:

  1. 1.

_Unstable Dependency (UD)_ : describes a subsystem (component) that depends on
other subsystems that are less stable than itself. This may cause a ripple
effect of changes in the system Marinescu (2012). Detected on packages.

  2. 2.

_Hub-Like Dependency (HL)_ : arises when an abstraction has (outgoing and
ingoing) dependencies with a large number of other abstractions Suryanarayana
et al. (2015). Detected on classes and packages.

  3. 3.

_Cyclic Dependency (CD)_ : refers to a subsystem (component) that is involved
in a chain of relations that break the desirable acyclic nature of a
subsystem’s dependency structure. The subsystems involved in a dependency
cycle can be hardly released, maintained or reused in isolation. Detected on
classes and packages. Arcan is able to detect the cycles according to
different shapes (see Figure 1) as described in Al-Mutawa et al. (2014).

  4. 4.

_Multiple Architectural Smell (MAS)_ : this is not actually a smell, but we
list it here for simplicity. It is an index useful to identifies a subsystem
(component) that is affected by more than one architectural smell and provides
the number of the architectural smells involved.

We decided to consider these AS in the study since they represent relevant
problems related to dependency issues: components highly coupled and with a
high number of dependencies cost more to maintain. Hence, they can be
considered more critical and can lead to a progressive architectural debt
Ernst et al. (2015). In particular, Cyclic Dependency is one of the most
common architectural smell, more dangerous and difficult to remove Martini et
al. (2018), Rizzi et al. (2018).

AS have been detected through the Arcan tool Arcelli Fontana et al. (2016a),
Arcelli Fontana et al. (2017), The tool relies on graph database technology
to perform graph queries, which let on higher scalability during the detection
process and management of a huge number of different kinds of dependencies.
Once a Java project has been analyzed by Arcan, a new graph-database is
created containing the structural dependencies of the projects. It is then
possible to run detection algorithms on this graph to extract information
about the analyzed project: package/class metrics and architectural issues.

This tool detects architectural smells based on dependency issues, by
reckoning different metrics proposed by Martin Martin (1995) such as those
related to instability issues. The evaluation of Arcan detection performances,
through standard Information Retrieval performance metrics,(i.e., confusion
matrix elements and derivatives, like precision and recall) is reported in
Arcelli Fontana et al. (2017) and an evaluation on 10 open source projects in
Arcelli Fontana et al. (2016a). The results of Arcan were validated using the
feedbacks of the practitioners on four industrial projects Martini et al.
(2018).  Moreover, another recent study Fontana et al. (2019) applied Arcan to
detect architectural smells in 102 projects from Qualitas Corpus Terra et al.
(2012). The tool is freely available and easy to install and to use.
333http://essere.disco.unimib.it/wiki/arcan.

Figure 1: Cycles shapes Al-Mutawa et al. (2014) in the scope of architecture
technical debt detection.

###  3.3 Concurrency Bugs

We describe below a number of typically-occurring Zhou et al. (2015);
Leesatapornwongsa et al. (2016) concurrency bugs that we have considered in
our study.

  1. 1.

_Data-Race (DR):_ DR occurs when at least two threads access the same data and
at least one of them write the data Yoshiura and Wei (2014). The nasty effects
of data-racing occur when concurrent threads perform conflicting accesses by
trying to update the same memory location or shared variable Henningsson and
Wohlin (2004); Akhter and Roberts (2006).

  2. 2.

_Deadlock (DL):_ DL is a condition in a system where a process cannot proceed
because it needs to obtain a resource held by another process but it itself is
holding a resource that the other process needs Bhatia and Verma (2014). More
generally, it occurs when two or more threads attempts to access shared
resources held by other threads, and none of the threads can give them up
Henningsson and Wohlin (2004). During deadlock, all involved threads are in a
waiting state.

  3. 3.

_Livelock (LL):_ LL happens when a thread is waiting for a resource that will
never become available while the CPU is busy releasing and acquiring the
shared resource. It is similar to Deadlock except that the state of the
process involved in the livelock constantly changes and is frequently
executing without making progress Chapman et al. (2008).

  4. 4.

_Starvation (SS):_ SS is a condition in which a process indefinitely delayed
because other processes are always given preferences Stallings (2012).
Starvation typically occurs when high priority threads are monopolizing the
CPU resources. During starvation, at least one of the involved threads remains
in the ready queue.

  5. 5.

_Suspension-based locking (SBL):_ SBL occurs when a calling thread waits for
an unacceptably long time in a queue to acquire a lock for accessing a shared
resource Lin et al. (2013).

  6. 6.

_Order violation (OV):_ OV is defined as the violation of the desired order
between at least two memory accesses Jayasinghe and Xiong (2010). It occurs
when the expected order of interleaving does not appear Park et al. (2010). If
a program fails to enforce the programmer intended order of execution then an
Order violation bug could happen Lu et al. (2008).

  7. 7.

_Atomicity violation (AV):_ AV refers to the situation when the execution of
two code blocks (sequences of statements protected by lock, transactions,
etc.) in one thread is concurrently overlapping with the execution of one or
more code blocks of other threads such a way that the result is inconsistent
with any execution where the blocks of the first thread are executed without
being overlapping with any other code block.

###  3.4 Architecture Smells as mediators for Concurrency Bugs

In the following we discuss any connections and overlaps we report from the
state of the art concerning the concurrency bugs under investigation and
formulate a series of theoretical conjectures to be tested out in the scope of
our empirical study.

#### Data-Race

Architect Michael Barr explains444https://barrgroup.com/Embedded-Systems/How-
To/Top-Ten-Nasty-Firmware-Bugs that Starvation is connected to any condition
wherefore the architectural structure does not warrant for proper Deadlock and
racing freedom (i.e., riddance of data race conditions).

In the scope of our work, we aim to show whether reported race-conditions for
a complex software architecture may also be connected to its dependency
structure, and any smells thereof. For example, Demsky et Al. Demsky and Lam
(2010) outline an architectural refactoring tactic where software architecture
views are used to instrument fine-grained locking mechanisms that visibly
reduce or altogether avoid data-race conditions. The tactic in question would
work by reducing the number of dependencies across software architecture
modules and refactoring “gateway” modules that act as viewers to supervise
architecture operations.

#### Deadlock

The Microsoft Development Handbook
identifies555https://technet.microsoft.com/en-
us/library/ms177433(v=sql.105).aspx recurrent deadlock scenarios as being
connected to unstable dependency scenarios wherefore packages and modules
depend upon packages and modules that are less stable than them. Literature
generally agrees with the previous statement, remarking how circularity and
hierarchical structures offer fertile grounds for deadlocks to thrive Muhanna
(1991). For example, in distributed deadlock conditions, the modularity
structure and the degree of distribution of software systems encourage
deadlocks to manifest Kshemkalyani and Singhal (1994).

#### Livelock

Livelock happens when a thread is waiting for a resource that will never
become available while the CPU is busy releasing and acquiring a shared
resource currently busy elsewhere in the software architecture. The Livelock
condition is similar to deadlock except that the state of the process involved
constantly changes and is frequently executing without making progress Chapman
et al. (2008). Similarly to deadlock, we expect livelocks to be connected to
an increasing number of mutual dependencies present across the architecture —
the more complex the dependency structure, the more likely is that deadlocks
would occur in their active state, i.e., livelocks Dobrica and Niemelä (2002).
However, the existence of livelocks requires an additional element of active
mutual execution between the busy, resource-occupying process and the active,
resource-requiring process. this additional element is likely to make the
occurrence of Livelock concurrency bugs lesser than the generic deadlock
counterpart.

#### Starvation

Starvation is “a condition in which a process indefinitely delayed because
other processes are always given preferences?” Stallings (2012). Starvation
typically occurs when high-priority threads are monopolizing the CPU
resources. During starvation, at least one of the involved threads remains in
the ready-queue. On one hand, Architect Michael Barr et Al. explain that
Starvation is connected to any condition wherefore the architectural structure
does not warrant for proper racing freedom (i.e., avoidance of data races), a
condition which is well-outlined by en-field investigations in Software
Performance Engineering (SPE) and its study of software architectures. On the
other hand, SPE researchers have long been studying the connection between
high-density component-based designs and their proneness to race conditions,
e.g., in the context of real-time Zalewski (2005) or mobile systems Grassi and
Cortellessa (2000).

#### Suspension-based locking

Often referred to as “Spinlock”, SBL is a lock which causes a thread trying to
acquire it to simply wait in a suspend loop (“spin”) while repeatedly checking
if the lock is available. By its own definition, SBL is a condition where a
highly decoupled architecture likely features interdependent modules which
require more appropriate or specific synchronization mechanisms Schütz (2001);
Kostrzewa et al. (2016).

#### Order and Atomicity violation

Both order and atomicity violation reflect internal behavioral characteristics
of modular structures and architecture elements. We were not able to formulate
any conjectures reflecting these two concurrency bugs ourselves, however,
literature on the matter seems to concur that several structural peculiarities
and patterns across complex software architectures lead to an increase in
buggy conditions Lu et al. (2012); Letko et al. (2008); Wu et al. (2015). For
example, Shangru et Al. Wu et al. (2015) adopt an abstraction sub-space
reduction approach to identify sub-spaces in the variable abstraction space
across systems execution traces which may reflect buggy conditions thus aiding
in the removal of reported violations. In much the same vein, we argue that
Arcan helps uncovering architectural implications (if any) around violation
bugs in complex software architectures - these implications likely exhibit a
recurrent, time-resolved presence across a number of projects and across a
number of their releases.

Time-resolution (i.e., recurrence of correlation over several subsequent
releases Shull et al. (2008)) is required for an architecture smell to be
effectively considered a proxy of violation bugs. Also, for the sake of
generalization, such time-resolution needs to manifest across a statistically
relevant sub-set of projects across our sample Wohlin (2006).

###  3.5 Data Sampling and Control Factors

The principal research question in our empirical study assumes the
availability of an independently-coded evaluation dataset can be used,
featuring projects with architecture issues made explicit by an independent
party. As a key requirement for our dataset to fit with our purpose, the
projects involved need to be intrinsically distributed and show evidence of a
parallel computing paradigm in their programming model. As such, our dataset
was constructed focusing solely on large-scale Big Data middleware which are
distributed _by-design_. With this latter explicit choice we aimed at control
the _distributiveness_ factor by construction with our sampling strategy —
more specifically, all the projects we selected in our sample are distributed
both in terms of applications’ operations (i.e., all projects are data-
intensive middleware supporting the operations of distributed big-data
processing applications) and in terms of platform behavior (i.e., the
platforms themselves are intrinsically distributed systems).

However, for the sake of generalization, the dataset in question, needs to
reflect a series of controllable variables, in order to offer a reliable
evaluation. In our case, we chose to focus on controlling the following
variables to obtain a viable dataset:

  * •

_Project Size:_ The presence of certain architecture smells could be higher in
projects with certain size; for this reason we decided to consider equally
both small/medium (200 KSLOC - 500 KSLOC) and large ($>$ 501 KSLOC) projects.

  * •

_Team Size:_ The presence of certain organizational dynamics could lead to the
emergence of specific architecture smells; we aimed at assessing the validity
of Arcan in several team circumstances wherefore technical debt detection
makes sense. In this respect, we ensured team sizes across our dataset, to
warrant a sufficient coverage of small ($<$25 participants), medium (20-30
participants) and large ($>$35 participants) communities.

  * •

_Project Popularity:_ Popular projects tend to be subject of continuous
releases and continuous refactoring to code; these circumstances may therefore
increase the number of architectural smells across the sample such that Arcan
correctness in detection may be compromised. In this respect, we controlled
for project popularity making sure that a sufficiently different number of
stargazers (i.e., the number of stars the project has received from how many
distinct users) are present for the projects we consider in our dataset.

  * •

_Project Type:_ Very complex products and projects may tend to be more error-
prone at the architectural level than simpler projects; these circumstances
may compromise the ability of Arcan to detect architecture smells where code
or architectural complexity rather than code size may be compromising project
features. In this respect we controlled that the projects in our sample are
equally distributed across 5 categories: (1) Middleware, (2) Software
Application, (3) Development Library, (4) Application Framework and (5)
Scheduling System. All 5 characteristics are non-overlapping, meaning that
they reflect either a different level of architectural abstraction, a
different application lifecycle phase, or a different target component type
(i.e., the type of architectural component that the project is aimed at
supporting).

  * •

_Bug Quality/Quantity:_ Projects whose releases contain more bugs of a certain
type may invalidate our study because of an uneven probability distribution
over the entire dataset of the individual bug types. We chose to provide an
equilibrium of bug types, sampling projects and releases such that an equal
proportion of each individual concurrency bug type with respect to the sizes
of involved projects.

To address the above data requirements, we investigated the literature and
open datasets available from several communities (e.g., Mining Software
Repositories, International Conference on Software Maintainance and Evolution
to name a few). Our choice fell on the dataset made available by Asadollah et
al. in Asadollah et al. (2017). The authors analyze over 125 releases evenly
arranged across 5 open-source projects, namely: Apache Hadoop, Apache
ZooKeeper, Apache Oozie, Apache Accumulo, and Apache Spark. The projects are
recapped on Table 1 \- the table shows the projects’ demographics gathered
from https://www.openhub.net, in particular, rows address the controllable
variables of the study described previously, while the columns name the
specific project.

Table 1: Projects demographic data of the dataset

| Apache Projects
---|---
|  Accumulo |  Hadoop |  Oozie |  Spark |  ZooKeeper
Releases |  11 |  76 |  6 |  12 |  20
Size |  367.854 |  2.434.336 |  194.599 |  1.207.823 |  144.322
Popularity |  24 |  117 |  1 |  50 |  22
Team Size |  94 |  210 |  29 |  1552 |  18
Type |  (3) |  (1) |  (5) |  (2) |  (4)
Activity |  H |  VH |  M |  VH |  VL
Legenda - Project Type: (1) Middleware; (2) Software Application;
(3) Development Library; (4) Application Framework; (5) Scheduling System.
VH means Very High, H means High, M means Moderate, and VL means Very Low

Table 2: The detected architectural smells and the concurrency bugs of all projects | Accumulo | Hadoop | Oozie | Spark | ZooKeeper
---|---|---|---|---|---
UD | 138 | 1.132 | 36 | 39 | 128
CD | 234.449 | 1.249.351 | 10.864 | 52.347 | 32.089
HL | 2.007 | 5.421 | 241 | 118 | 337
MAS | 23.6594 | 1.255.904 | 11.141 | 52504 | 32554
AS | 4763.188 | 2.511.808 | 22.282 | 105.008 | 65.108
DATARACE | 23 | 121 | 9 | 0 | 66
STARVATION | 0 | 12 | 2 | 0 | 3
SUSPENSION | 18 | 33 | 1 | 2 | 9
ORDER | 2 | 41 | 3 | 6 | 14
DEATHLOCK | 4 | 46 | 5 | 1 | 18
NOTCLEAR | 0 | 16 | 0 | 0 | 0
ATOMICITY | 0 | 16 | 1 | 0 | 12
LIVELOCK | 0 | 5 | 0 | 0 | 0
BUGS | 47 | 290 | 21 | 9 | 122

Apache Hadoop is the biggest project, the most popular one and its developer
team has a very high work activity respect to the other projects of the
dataset. Apache Spark has the biggest team size of the dataset with 1552
developers. Apache Ozzie is the less popular of the dataset, but it has a
medium team size with a moderate development activity. Apache Accumulo is a
medium project size with a large community. Apache Zookeeper is the smallest
project of the dataset and it has a small and very low active development
team.

For each release of the 5 projects, the authors elicited JIRA666an issue
management platform allowing users to manage their issues throughout their
entire life cycle issue-tracking information and provided a list of issues and
buggy-classes per release, manually mapping every issue to a concurrency bug
Asadollah et al. (2017). In our study, we reuse the same dataset, manually
confirming every instance in the dataset 777openly available online:
https://goo.gl/wcdD16 (all the compile-available versions). To understand the
inter-rater agreement (IRR) of our manual coding with respect to the original
dataset inherited from related work Asadollah et al. (2017), we employed the
well-known Krippendorff Alpha coefficient Krippendorff (2004) — in the scope
of this study, the IRR agreement between our manual coding and the previously-
coded dataset amounted to $\alpha=0,84$ which is $>>$ than the usually
considered acceptable value of 0,800.

Further on, we operated over the dataset as follows. First, we cloned every
release found on the dataset. Second, we ran Arcan detection over the release.
Finally, we study the correlation between the human coding of concurrency bugs
available in Asadollah et al. Asadollah et al. (2017) and the architecture
smell detection provided by Arcan.

Table 2 shows the distribution of each concurrency bug and architectural smell
computed by Arcan with the respective total number (AS and BUGS columns). We
can observe that Spark project is the project with less bugs but with more
architectural smells than Oozie and ZooKeeper. Moreover, Hadoop is the project
having more bugs and architectural smells than the other projects as expected,
since we could consider much more versions ($76$) than other projects in the
dataset.

###  3.6 Data Analysis

In this Section we describe the data analyses protocol.

  * •

_Correlation Analysis_ : we performed two correlation analyses using the
Spearman rank correlation coefficient Spearman (1904) exercised between
concurrency bugs and architectural smells. Spearman rank correlation
coefficient is a nonparametric measure of rank correlation (statistical
dependence between the rankings of two variables). It assesses how well the
relationship between two variables can be described using a monotonic
function. The Spearman correlation between two variables assesses monotonic
relationships between those variable (whether linear or not). If there are no
repeated data values, a perfect Spearman correlation of +1 or -1 occurs when
each of the variables is a perfect monotone (increasing or decreasing)
function of the other. This analysis was conducted on the complete dataset
and, subsequently, focusing on each individual project. Moreover, we computed
the Kendall Kendall (1938) and Pearson Pearson (1895) correlation during the
setup phase of the study.

Pearson correlation is the most used one to measure the relationship degree
between linearly related variables, while Kendall rank correlation is another
of the non-parametric tests applied to measure the strength of dependence
between two variables Croux and Dehon (2010).

We have not reported those results since we noticed that the results were
comparable with the Spearman correlation tests.

  * •

_Associative-Rule Mining_ : we studied the associative rules existing in the
dataset using the Apriori Agrawal and Srikant (1994) algorithm which is
defined for discovering all significant associative rules between items in a
large database of transaction. However, we used the algorithm to study whether
architectural smells could be associated with one or more concurrency bugs and
vice versa, computed using the
apriori888https://cran.r-project.org/package=arules R package.

##  4 Empirical Study Results

In this section we describe the results obtained through the performed
analysis outlined in Section 3.6.

###  4.1 Correlation Results

Correlation analysis run over the entire dataset outlined in Table 3. The
table shows the correlation test results of Spearman tests among any type of
architectural smell and any type of concurrency bug. Moreover, the last column
of the table reports the results of the correlation between architecture
smells and each individual concurrency bug; we use the indication “Not clear”
when the bug instance type was not identifiable. Test results are represented
using heat-maps and therefore assume values in the range of [$-1,+1$] (from
blue to red). We noticed that the best results are obtained through the
correlation of any AS and the presence of a bug (see last column on the right
of Table 3). Furthermore, we noticed no correlation between several
architecture smells and _Suspension_ bugs (SBL).

However, even the best result obtained in our correlation tests was lower than
$0.20$ — the value is not enough to warrant a strong correlation. In this
instance, we were not able to make any conclusive observation. Hence, we
conducted a project-specific analysis of correlations to understand if any of
the factors influencing our sample may be also mediators in the correlations
under study.

Table 3: Spearman’s test AS over Concurrency bugs

AS/CB |  DR |  SS |  SBL |  OV |  DL |  NC |  AV |  LL |  BUG
---|---|---|---|---|---|---|---|---|---
CD |  -0.06 |  -0.06 |  0.13 |  0.07 |  0.05 |  0.11 |  -0.12 |  0.04 |  0.11
HL |  -0.04 |  -0.04 |  0.12 |  0.07 |  0.09 |  0.06 |  -0.09 |  0.04 |  0.14
MAS |  -0.06 |  -0.02 |  0.13 |  0.06 |  0.05 |  0.11 |  -0.12 |  0.04 |  0.11
UD |  -0.01 |  0.02 |  0.06 |  0.07 |  0.05 |  0.12 |  -0.05 |  0.08 |  0.19
Legend |  -1.00 |  -0.75 |  -0.50 |  -0.25 |  0.00 |  0.25 |  0.50 |  0.75 |  1.00
NC - whether is _Not Clear_ which is the type of concurrency bug
BUG - whether at least a concurrency bug is present

This second correlation analysis is outlined in Table 4. The table shows the
application of correlation analysis to individual projects.

Table 4: Spearman’s test AS over Concurrency bugs by project |  | Concurrency bugs
---|---|---
Projects |  AS | DR | SS | SBL | OV | DL | NC | AV | LL | BUG
Accumulo |  CD | 0.16 | * | -0.33 | 0.39 | -0.02 | * | * | * | 0.03
Accumulo |  HL | 0.01 | * | -0.3 | 0.41 | 0.05 | * | * | * | 0.03
Accumulo |  MAS | 0.16 | * | -0.33 | 0.39 | -0.02 | * | * | * | 0.03
Accumulo |  UD | 0.28 | * | -0.35 | 0.3 | -0.03 | * | * | * | 0.13
Hadoop |  CD | -0.07 | 0.00 | 0.1 | 0.2 | 0.01 | 0.1 | -0.18 | 0.01 | 0.11
Hadoop |  HL | -0.02 | -0.1 | 0.00 | 0.23 | 0.13 | 0.01 | -0.08 | 0.05 | 0.22
Hadoop |  MAS | -0.07 | -0.01 | 0.1 | 0.2 | 0.01 | 0.1 | -0.18 | 0.01 | 0.11
Hadoop |  UD | 0.00 | -0.06 | -0.01 | 0.17 | 0.04 | 0.04 | -0.07 | 0.06 | 0.17
Oozie |  CD | 0.17 | -0.41 | 0.15 | -0.11 | 0.22 | * | 0.15 | * | 0.24
Oozie |  HL | 0.2 | -0.55 | 0.15 | -0.11 | 0.22 | * | 0.15 | * | 0.18
Oozie |  MAS | 0.17 | -0.41 | 0.15 | -0.11 | 0.22 | * | 0.15 | * | 0.24
Oozie |  UD | -0.2 | 0.45 | -0.15 | 0.19 | -0.22 | * | -0.15 | * | -0.22
Spark |  CD | * | * | 0.42 | 0.03 | -0.28 | * | * | * | 0.17
Spark |  HL | * | * | 0.24 | 0.37 | -0.33 | * | * | * | 0.36
Spark |  MAS | * | * | 0.42 | 0.03 | -0.28 | * | * | * | 0.17
Spark |  UD | * | * | 0.38 | -0.34 | 0.38 | * | * | * | 0.06
Zookeeper |  CD | -0.07 | -0.06 | 0.16 | -0.14 | -0.04 | * | -0.02 | * | -0.17
Zookeeper |  HL | -0.06 | -0.01 | 0.21 | -0.17 | -0.07 | * | -0.04 | * | -0.13
Zookeeper |  MAS | -0.07 | -0.06 | 0.17 | -0.15 | -0.03 | * | -0.03 | * | -0.17
Zookeeper |  UD | 0.01 | 0.13 | 0.12 | -0.16 | -0.1 | * | 0.02 | * | -0.03
Legend | -1.00 | -0.75 | -0.50 | -0.25 | 0.00 | 0.25 | 0.50 | 0.75 | 1.00
NC - whether is _Not Clear_ which is the type of concurrency bug
BUG - whether at least a concurrency bug is present
* correlation non computed since there are not bug of the specified type in that projects
or the variance was $0$ or the associated p-value was $>0.05$

We observe that Data-Race (DR) seems meagerly correlated with all types of
architecture smells with a peak correlation value of $0.28$ with UD in the
scope of the Accumulo project, an intrinsically distributed datastore based on
the Google BigTable model. In addition, we observe that the Starvation (SS)
bug shows the highest correlation values in Oozie project where the values
showed a negative monotone correlation with CD, HL, and MAS architectural
smells assuming values $-0.41$, $-0.55$ and $-0.41$ respectively; there is a
positive monotone correlation with UD with value $0.45$. This correlation
behavior seems to indicate that Starvation bugs are growing in number when UD
grow linearly and while other AS are decreasing at the same time.

Suspension bug (SBL) has a negative correlation with all AS of at least $-0.3$
in Accumulo project but exhibits a positive correlation in Spark; in
particular, the bug has a correlation value of $0.42$ with CD and MAS, $0.38$
with UD and $0.24$ with HL. This seems to indicate that the Suspension bug
decreases while the AS are increasing in Accumulo. However, the Suspension bug
increases while the AS are decreasing in Spark. This evidence leads to the
conclusion that this type of bug is intrinsically dependent on the project
characteristics similarly to Data-Race conditions with the type of the
project, but could be related to the developers since more developers are
involved, more likely the correlation increase (Spark) or decrease (Accumulo)
with less developers involved.

Order violation (OV) bugs have the highest positive correlation with all AS in
Accumulo, and also in Hadoop and Spark. This seems to indicate that
architecture smells may cause nasty Order violation circumstances in highly
distributed systems such as in the projects listed above.

Deadlock bugs (DL) have a positive correlation in Oozie for CD, HL and MAS
with a value of $0.22$; there is a negative correlation in Spark with values
$-0.28$, $-0.33$ and $-0.28$ respectively. Moreover, UD has a negative
correlation in Oozie of $-0.22$ (positive with the other AS) and a positive
correlation in Accumulo of $0.38$ (negative with the other AS). This trend may
be connected to project Oozie’s nature of a centralized work-flow manager — in
this instance, it could mean that the more centralized the architectural
structure, the more prone to deadlocks is.

Finally, concerning the remaining concurrency bugs we explored in the scope of
our dataset, namely, the Notclear (NC) indicator, Atomicity (AV) and Livelock
(LL) bug, we observed no strong correlations in any project as outlined in the
results obtained on the full dataset and showed in Table 3. For these bugs,
there may _not_ exist any form of structural/behavioral relation.

Findings. The relation between architecture smells and concurrency bugs is
non-trivial and runs deeper than the structural correlation analysis we
operated in the scope of this paper. Nevertheless, we observed interesting and
project-specific behaviors for Data-Race, Suspension, Order violation, and
Deadlock conditions — their architectural implications deserve further study.
Finally, our observations concerning remaining bugs is inconclusive.

###  4.2 Associative Rules Results

In this section we describe the obtained results of the associative rules from
the execution of the Apriori association rule mining algorithm. Figure 2 and
Figure 3 show the _support_ and _confidence_ of the extracted associative
rules to identify whether an AS type is associated to a bug and vice versa.
Moreover, Figure 2 and Figure 3 show both the presence and the absence of a
bug or AS:

  * •

the _presence_ of a bug or an AS is given by indicating the value 1 (e.g.,
$AS.1$, $bug.1$);

  * •

the _absence_ of a bug or an AS is given by showing the value 0 (e.g., $AS.0$,
$bug.0$).

Figure 2: Boxplot of Support and Confidence of Apriori rules among Bugs. The
presence of the BUG type is given by the value $1$ and the absence is given by
the value $0$.

We start explaining the associative rules of a presence or absence of a bug
given any AS. Figure 2 shows that the confidence and support are too low for
the learned associative rules related to the presence of a specific type of
bug. However, several associative rules related to $bug.1$ have a support and
confidence higher than $0.7$. Most relevant rules associated to the presence
of AS are summarized in Table 5. The table shows the rules related to the
presence of any given concurrency _bug_ ; AS results are grouped by _lift_ ,
using a cut-off value of $0.7$ in both support and confidence. The rules
without HL and UD architecture smells, obtained better results — this uncovers
a clear relation existing among concurrency bugs, CD, and MAS. Furthermore, we
observed that the HL rules score slightly better results than UD rules.

Table 5: Rules of AS vs. a generic Bugs

Rules | Support | Confidence | Lift
---|---|---|---
{$cd=1$} $\Rightarrow$ {$bug=1$} | 0.779 | 0.779 | 1
{$mas=1$} $\Rightarrow$ {$bug=1$} | 0.779 | 0.779 | 1
{$cd=1,mas=1$} $\Rightarrow$ {$bug=1$} | 0.779 | 0.779 | 1
{$hl=1$} $\Rightarrow$ {$bug=1$} | 0.766 | 0.776 | 0.996
{$cd=1,hl=1$} $\Rightarrow$ {$bug=1$} | 0.766 | 0.776 | 0.996
{$hl=1,mas=1$} $\Rightarrow$ {$bug=1$} | 0.766 | 0.776 | 0.996
{$cd=1,hl=1,mas=1$} $\Rightarrow$ {$bug=1$} | 0.766 | 0.776 | 0.996
{$ud=1$} $\Rightarrow$ {$bug=1$} | 0.761 | 0.775 | 0.995
{$hl=1,ud=1$} $\Rightarrow$ {$bug=1$} | 0.761 | 0.775 | 0.995
{$cd=1,ud=1$} $\Rightarrow$ {$bug=1$} | 0.761 | 0.775 | 0.995
{$ud=1,mas=1$} $\Rightarrow$ {$bug=1$} | 0.761 | 0.775 | 0.995
{$cd=1,hl=1,ud=1$} $\Rightarrow$ {$bug=1$} | 0.761 | 0.775 | 0.995
{$hl=1,ud=1,mas=1$} $\Rightarrow$ {$bug=1$} | 0.761 | 0.775 | 0.995
{$cd=1,ud=1,mas=1$} $\Rightarrow$ {$bug=1$} | 0.761 | 0.775 | 0.995
{$cd=1,hl=1,ud=1,mas=1$} $\Rightarrow$ {$bug=1$} | 0.761 | 0.775 | 0.995

Figure 3: Boxplot of Support and Confidence of associative rules among AS. The
presence of the AS is given by the value $1$ and the absence is given by the
value $0$.

For what concerns associative rules constructed by using concurrency bugs to
assess the absence and presence of AS, Figure 3 shows that the obtained rules
have high confidence to indicate the presence of AS types, but the box of the
boxplot is condensed to low values of the support. The rules extracted for the
absence of architectural smells are not relevant (lower than $0.2$). Figure 3
shows that the confidence and the support of the rules is low in the case of
AS absence (values lower than $0.2$). However, the confidence for the presence
of AS is higher than $0.8$ in most all the cases (e.g., UD.1, MAS.1 and CD.1)
and the support have many outliers higher than $0.8$. We consider bugs as good
predictors for a general AS, as shown at Figure 3. We present some of the
rules related to the presence of bugs in Table 6. Table 6 shows the rules
associated to each type of architectural smell given by bugs. A bug is
associated with a Support equal to or higher than $0.98$ and a Confidence
equal to or higher than $0.76$ to the AS.

Table 6: Associative rules related to AS Rules | Support | Confidence | Lift
---|---|---|---
{$bug=1$} $\Rightarrow$ {$cd=1$} | 0.78 | 1.00 | 1.00
{$bug=1$} $\Rightarrow$ {$mas=1$} | 0.78 | 1.00 | 1.00
{$bug=1$} $\Rightarrow$ {$hl=1$} | 0.77 | 0.98 | 1.00
{$bug=1$} $\Rightarrow$ {$ud=1$} | 0.76 | 0.98 | 0.99

Moreover, the extraction of associative rules per projects was performed. We
identified the same rules among the projects. Support and Confidence of the
associative rules extracted from the projects with less bugs (i.e. Accumulo,
Oozie and Spark) have slightly higher values than the other projects (i.e.
Hadoop and Zookeeper). In conclusion, the results obtained in general on all
the projects are still valid also for single projects.

Findings. The associative rules of the absence and presence of a concurrency
bug and one (or more) architectural smell(s) show that CD and MAS give the
best results associated to the presence of a concurrency bug and vice versa.
The absence of a concurrency bug is not associated to the presence of an
architectural smell and similarly the absence of an architectural smell is not
associated to the presence of one (or more) concurrency bug(s).

##  5 Discussions

In order to answer our RQ1, we performed Spearman’s correlation tests by
project and for the entire projects as explained in Section 4. We noticed no
relevant correlation at dataset level, since the values are lower or equal to
$0.18$. We studied the correlation per project between concurrency bugs and
architectural smells, since we argue that it is in fact possible to highlight
correlations with respect to smells only in the context of some specific
project characteristics. For example, Suspension-based locking bugs show a
negative correlation with all AS in the Accumulo project, but positive with
all other projects and significantly stronger with Spark. In contrast with the
other projects, we observe that Accumulo teams are prone to reducing the
Unstable Dependency architecture smell while they are more prone on
introducing new Suspension-based locking bugs. In addition, Starvation has a
negative correlation with all the AS in the Arcan detection set and its
presence is predominant in the Oozie project.

Answering to RQ2, the presence of a concurrency bug is not correlated in
general to any AS across most projects, as shown in the _BUG_ column from
Table 6. To offer a more focused lens of analysis over the influences we
investigated, we extracted the associative rules using the Apriori algorithm,
as explained in Section 4. We observed that, while it is hard to discover
associative rules between architecture smells and a particular type of
concurrency bug, it is in fact evident that any AS is associated to the
occurrence of a concurrency bug with a support and confidence higher than or
equal to $0.76$. Moreover, a type of concurrency bug is related to any AS
where we extracted rules with a support and confidence higher than or equal to
$0.76$.

We conclude that there are in fact relations and implications between software
architecture smells and concurrency bugs, but the theory we outlined in Sec.
3.4 and all the relations thereto need further exploratory research to
pinpoint any characteristics that link concurrency bugs to architecture smells
further — in the scope of this paper we have been able to show that a relation
does in fact exist and is considerable enough to warrant further exploration.

##  6 Threats to Validity

External Validity By means of an externally-coded dataset which was prepared
previously to our study and in a totally independent fashion, we aimed
explicitly to strengthen external validity of this study. We explicitly aimed
at controlling variables that could warrant a higher external validity, as the
variables we controlled in the several options available to us for dataset
reuse. Although a number of variables remain uncontrolled (e.g., programming
language, code structure complexity, PL type, etc.) due to tool or other
limitations.  Arcan detection performance was evaluated in two industrial case
studies based on the feedback of the developers is described in Arcelli
Fontana et al. (2017), where the authors report a precision of 100%, since
Arcan found only correct instances of architectural smells, and a 63% value
for recall. The developers reported five more architectural smells, which were
false negatives, related to 180 external components outside the tool’s scope
of analysis. Moreover, in order to increase the reliability on Arcan, a
manually validation was performed in ten open-source projects Arcelli Fontana
et al. (2017) and in four industry projects on which the practitioners
evaluated the usefulness of the tool support Martini et al. (2018). The
detection tool usefulness was evaluated considering practitioners feedbacks on
the the automatic detection support of architectural smells detected by Arcan
Martini et al. (2018).

Construct and Internal Validity. The methods we adopted to evaluate our
solution are less prone to generalizability issues since their evaluation re-
uses established content analysis techniques and correlation analysis
previously known and widely-used in the literature. Given that the comparison
we operate in the context of this study relates to evaluating agreement with
the assessment made by independent human observers (i.e., the original
labelers of concurrency bugs in our dataset), we chose to run a simple
Spearman correlation test evaluation. We used a library implemented in _R_
called Corrplot999https://cran.r-project.org/package=corrplot. Other
correlation tests exist, e.g., Pearson and Kendall and we test them in the
setup study phase anyway.  We considered only four architectural smells since
only few available tools are able to detect several architectural smells
compared to tools to detect code debt.

Conclusion Validity. Our conclusions are based on the manual inspection of the
correlation tests scores between a human predictor triangulated independently
in a completely unrelated study and the precision of the Arcan, architecture
smells detector. We argue that our interpretation is valid since it is limited
to assessing whether the overlap successfully addresses our research question.

Replication Package. We provide an extensive replication package containing:
(a) the version of Arcan that was used for the purpose of this study, as well
as instructions to setup and run the tool101010Arcan and instruction for setup
and run the tool, https://goo.gl/DhwHPq; (b) the original dataset from
Asadollah et Al. 111111Dataset of Concurrency bugs, https://goo.gl/DFg5f5;(c)
The data extracted by Arcan121212Dataset of Arcan, https://goo.gl/Jw51ND.

##  7 Conclusions and Future Work

This paper seeks to shed light over the possible relations between software
architecture smells and concurrency bugs. In the context of our study, we used
Arcan, a configurable tool to detect and rank dependency-based architecture
smells. More in particular, we employed Arcan on 125 releases of 5 large open-
source products. We analyzed Arcan results in combination with the concurrency
bugs reported independently across the dataset by external observers. The
relation between architecture smells and concurrency bugs is non-trivial and
runs deeper than the structural correlation analysis we operated in the scope
of this paper. Nevertheless, we observed interesting and project-specific
behaviors for Data-Race, Suspension, Order violation, and Deadlock conditions.
Finally, our observations concerning remaining bugs are inconclusive or may
suggest no relation with structural/behavioral property. As a major
contribution of this study, we assessed that there is in fact an empirical
relation between architectural smells and concurrency bugs. Namely, our study
reveals that there is in fact a sensible relation between architecture smells
and several Deadlock, and Suspension conditions. These relations need further,
more specific and possibly qualitative exploratory research asking developers
feedbacks, but provide significant hints to developers on parts to be
carefully checked. In the future, we plan to investigate more thoroughly the
role of each individual architecture smell in the scope of each individual
concurrency bug we are targeting in the scope of this study. Moreover, we plan
to instrument a case-study campaign specifically designed to further
understand the architectural implications of every single concurrency bug,
from a combined qualitative and quantitative perspective. We could also
explore the impact of the severity of the architectural smells and the
Architectural Debt Index Roveda et al. (2018). We have considered the
architectural smells detected by Arcan, but others can be considered in the
future not strictly based on dependency issues, as for example the micro
services smells Taibi and Lenarduzzi (2018).

## References

  * Abebe et al. (2009) Abebe SL, Haiduc S, Tonella P, Marcus A (2009) Lexicon bad smells in software. In: Proc. Working Conf. on Reverse Engineering, IEEE, pp 95–99
  * Agrawal and Srikant (1994) Agrawal R, Srikant R (1994) Fast algorithms for mining association rules in large databases. In: Proceedings of the 20th International Conference on Very Large Data Bases, Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, VLDB ’94, pp 487–499, URL http://dl.acm.org/citation.cfm?id=645920.672836
  * Akhter and Roberts (2006) Akhter S, Roberts J (2006) Multi-core programming, vol 33. Intel press Hillsboro
  * Akturk et al. (2016) Akturk I, Akram R, Islam MM, Muzahid A, Karpuzcu UR (2016) Accuracy bugs: A new class of concurrency bugs to exploit algorithmic noise tolerance. TACO 13(4):48:1–48:24, URL http://dblp.uni-trier.de/db/journals/taco/taco13.html#AkturkAIMK16
  * Al-Mutawa et al. (2014) Al-Mutawa HA, Dietrich J, Marsland S, McCartin C (2014) On the shape of circular dependencies in java programs. In: Proc. 23rd Australian Software Engineering Conference (ASWEC 2014), IEEE, Sydney, Australia, pp 48–57, DOI 10.1109/ASWEC.2014.15
  * Arcelli Fontana et al. (2016a) Arcelli Fontana F, Pigazzini I, Roveda R, Zanoni M (2016a) Automatic detection of instability architectural smells. In: Proceedings of the 32nd International Conference on Software Maintenance and Evolution (ICSME 2016) - ERA Track, IEEE, Raleigh, North Carolina, USA
  * Arcelli Fontana et al. (2016b) Arcelli Fontana F, Roveda R, Zanoni M (2016b) Tool support for evaluating architectural debt of an existing system: An experience report. In: Proceedings of the 31st ACM/SIGAPP Symposium on Applied Computing (SAC 2016), ACM, Pisa, Italy
  * Arcelli Fontana et al. (2017) Arcelli Fontana F, Pigazzini I, Roveda R, Tamburri DE, Zanoni M, Nitto ED (2017) Arcan: a tool for architectural smells detection. In: IEEE International Conference on Software Architecture (ICSA 2017), DOI 10.1109/MTD.2016.11
  * Asadollah et al. (2017) Asadollah SA, Sundmark D, Eldh S, Hansson H (2017) Concurrency bugs in open source software: a case study. J Internet Services and Applications 8(1):4:1–4:15, DOI 10.1186/s13174-017-0055-2
  * Avgeriou et al. (2016) Avgeriou P, Kruchten P, Ozkaya I, Seaman CB (2016) Managing technical debt in software engineering (dagstuhl seminar 16162). Dagstuhl Reports 6(4):110–138, DOI 10.4230/DagRep.6.4.110
  * Azadi et al. (2019) Azadi U, Fontana FA, Taibi D (2019) Architectural smells detected by tools: a catalogue proposal. In: Proceedings of the Second International Conference on Technical Debt, TechDebt@ICSE 2019, Montreal, QC, Canada, May 26-27, 2019, pp 88–97
  * Bass et al. (1998) Bass L, Clements P, Kazman R (1998) Software Architecture in Practice. Addison Wesley
  * Behnamghader et al. (2017) Behnamghader P, Le DM, Garcia J, Link D, Shahbazian A, Medvidovic N (2017) A large-scale study of architectural evolution in open-source software systems. Empirical Software Engineering 22(3):1146–1193, DOI 10.1007/s10664-016-9466-0
  * Bhatia and Verma (2014) Bhatia Y, Verma S (2014) Deadlocks in distributed systems. International Journal of Research 1(9):1249–1252
  * Cai and Kazman (2019a) Cai Y, Kazman R (2019a) Dv8: automated architecture analysis tool suites. In: 2019 IEEE/ACM International Conference on Technical Debt (TechDebt), IEEE, pp 53–54
  * Cai and Kazman (2019b) Cai Y, Kazman R (2019b) Dv8: Automated architecture analysis tool suites. In: International Conference on Technical Debt, p 53–54
  * Chapman et al. (2008) Chapman B, Jost G, Van Der Pas R (2008) Using OpenMP: portable shared memory parallel programming, vol 10. MIT press
  * Croux and Dehon (2010) Croux C, Dehon C (2010) Influence functions of the spearman and kendall correlation measures. Statistical Methods & Applications 19(4):497–515
  * Debski et al. (2018) Debski A, Szczepanik B, Malawski M, Spahr S, Muthig D (2018) A scalable, reactive architecture for cloud applications. IEEE Software 35(2):62–71, URL http://dblp.uni-trier.de/db/journals/software/software35.html#DebskiSMSM18
  * Demsky and Lam (2010) Demsky B, Lam P (2010) Views: object-inspired concurrency control. In: Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering - Volume 1, ACM, New York, NY, USA, ICSE ’10, pp 395–404, DOI 10.1145/1806799.1806858, URL http://doi.acm.org/10.1145/1806799.1806858
  * Dobrica and Niemelä (2002) Dobrica L, Niemelä E (2002) A survey on software architecture analysis methods. IEEE Trans Software Eng 28(7):638–653, URL http://dblp.uni-trier.de/db/journals/tse/tse28.html#DobricaN02
  * Ernst et al. (2015) Ernst NA, Bellomo S, Ozkaya I, Nord RL, Gorton I (2015) Measure it? manage it? ignore it? software practitioners and technical debt. In: Proc. of the 2015 10th Joint Meeting on Foundations of Software Engineering, ACM, New York, NY, USA, ESEC/FSE 2015, pp 50–60, DOI 10.1145/2786805.2786848, URL http://doi.acm.org/10.1145/2786805.2786848
  * Fonseca (2015) Fonseca PJSd (2015) Effective testing for concurrency bugs. PhD thesis, Uni Saarbrücken
  * Fontana et al. (2019) Fontana FA, Lenarduzzi V, Roveda R, Taibi D (2019) Are architectural smells independent from code smells? an empirical study. Journal of Systems and Software 154:139 – 156
  * Garcia et al. (2011) Garcia J, Popescu D, Mattmann C, Medvidovic N, Cai Y (2011) Enhancing architectural recovery using concerns. In: 26th IEEE/ACM International Conference on Automated Software Engineering (ASE 2011), pp 552–555, DOI 10.1109/ASE.2011.6100123
  * Grassi and Cortellessa (2000) Grassi V, Cortellessa V (2000) Performance evaluation of mobility-based software architectures. In: Workshop on Software and Performance, pp 44–46, URL http://dblp.uni-trier.de/db/conf/wosp/wosp2000.html#GrassiC00
  * Henningsson and Wohlin (2004) Henningsson K, Wohlin C (2004) Assuring fault classification agreement-an empirical evaluation. In: International Symposium on Empirical Software Engineering, ISESE’04, IEEE, pp 95–104
  * Jayasinghe and Xiong (2010) Jayasinghe D, Xiong P (2010) Core: Visualization tool for fault localization in concurrent programs. Internet: http://www cc gatech edu/grads/i/ijayasin/resources/core_falcon pdf
  * Kelk et al. (2013) Kelk D, Jalbert K, Bradbury JS (2013) Automatically repairing concurrency bugs with arc. In: Lourenço J, Farchi E (eds) MUSEPAT, Springer, Lecture Notes in Computer Science, vol 8063, pp 73–84
  * Kelly et al. (2009) Kelly T, Wang Y, Lafortune S, Mahlke SA (2009) Eliminating concurrency bugs with control engineering. IEEE Computer 42(11):52–60, URL http://dblp.uni-trier.de/db/journals/computer/computer42.html#KellyWLM09
  * Kendall (1938) Kendall MG (1938) A new measure of rank correlation. Biometrika 30(1/2):81–93
  * Khoshnood et al. (2015) Khoshnood S, Kusano M, Wang C (2015) Concbugassist: constraint solving for diagnosis and repair of concurrency bugs. In: Young M, Xie T (eds) ISSTA, ACM, pp 165–176
  * Kidd et al. (2011) Kidd N, Reps TW, Dolby J, Vaziri M (2011) Finding concurrency-related bugs using random isolation. STTT 13(6):495–518, URL http://dblp.uni-trier.de/db/journals/sttt/sttt13.html#KiddRDV11
  * Kostrzewa et al. (2016) Kostrzewa A, Tobuschat S, Saidi S, Ernst R (2016) Supporting suspension-based locking mechanisms for real-time networks-on-chip. In: RTNS, ACM, pp 215–224
  * Koziolek et al. (2013) Koziolek H, Domis D, Goldschmidt T, Vorst P (2013) Measuring architecture sustainability. IEEE Software 30(6), DOI 10.1109/MS.2013.101
  * Krippendorff (2004) Krippendorff K (2004) Content Analysis: An Introduction to Its Methodology (second edition). Sage Publications
  * Kshemkalyani and Singhal (1994) Kshemkalyani AD, Singhal M (1994) Efficient detection and resolution of generalized distributed deadlocks. IEEE Trans Software Eng 20(1):43–54, URL http://dblp.uni-trier.de/db/journals/tse/tse20.html#KshemkalyaniS94
  * Lanza and Marinescu (2006) Lanza M, Marinescu R (2006) Object-Oriented Metrics in Practice. Springer
  * Le and Medvidovic (2016) Le D, Medvidovic N (2016) Architectural-based speculative analysis to predict bugs in a software system. In: Proceedings of the 38th International Conference on Software Engineering Companion, ACM, New York, NY, USA, ICSE ’16, pp 807–810, DOI 10.1145/2889160.2889260
  * Le et al. (2015) Le DM, Behnamghader P, Garcia J, Link D, Shahbazian A, Medvidovic N (2015) An empirical study of architectural change in open-source software systems. In: 2015 IEEE/ACM 12th Working Conference on Mining Software Repositories, pp 235–245, DOI 10.1109/MSR.2015.29
  * Leesatapornwongsa et al. (2016) Leesatapornwongsa T, Lukman JF, Lu S, Gunawi HS (2016) Taxdc: A taxonomy of non-deterministic concurrency bugs in datacenter distributed systems. In: ASPLOS, ACM, pp 517–530
  * Letko et al. (2008) Letko Z, Vojnar T, Krena B (2008) Atomrace: data race and atomicity violation detector and healer. In: PADTAD, ACM, p 7
  * Lin et al. (2013) Lin S, Wellings A, Burns A (2013) Supporting lock-based multiprocessor resource sharing protocols in real-time programming languages. Concurrency and Computation: Practice and Experience 25(16):2227–2251
  * Lu et al. (2008) Lu S, Park S, Seo E, Zhou Y (2008) Learning from mistakes: a comprehensive study on real world concurrency bug characteristics. In: ACM Sigplan Notices, ACM, vol 43, pp 329–339
  * Lu et al. (2012) Lu S, Park S, Zhou Y (2012) Finding atomicity-violation bugs through unserializable interleaving testing. IEEE Trans Software Eng 38(4):844–860, URL http://dblp.uni-trier.de/db/journals/tse/tse38.html#LuPZ12
  * Macia et al. (2012a) Macia I, Arcoverde R, Cirilo E, Garcia A, von Staa A (2012a) Supporting the identification of architecturally-relevant code anomalies. In: Proc. of the 28th IEEE Intern.Conf. on Soft. Maint.(ICSM 2012), IEEE, Italy, pp 662–665, DOI 10.1109/ICSM.2012.6405348
  * Macia et al. (2012b) Macia I, Arcoverde R, Garcia A, Chavez C, von Staa A (2012b) On the relevance of code anomalies for identifying architecture degradation symptoms. In: Proceedings of the 15th European Conference on Software Maintenance and Reengineering (CSMR 2012), IEEE Computer Society, Szeged, Hungary, pp 277–286, DOI 10.1109/CSMR.2012.35
  * Marinescu (2012) Marinescu R (2012) Assessing technical debt by identifying design flaws in software systems. IBM Journal of Research and Development 56(5):9:1–9:13, DOI 10.1147/JRD.2012.2204512
  * Martin (1995) Martin RC (1995) Object oriented design quality metrics: An analysis of dependencies. ROAD 2(3)
  * Martini et al. (2018) Martini A, Arcelli Fontana F, Biaggi A, Roveda R (2018) Identifying and prioritizing architectural debt through architectural smells: a case study in a large software company. In: Proc. of the European Conf. on Software Architecture (ECSA), Springer, Madrid, Spain
  * Mo et al. (2015) Mo R, Cai Y, Kazman R, Xiao L (2015) Hotspot patterns: The formal definition and automatic detection of architecture smells. In: 12th Working IEEE/IFIP Conference on Software Architecture, WICSA 2015, Montreal, QC, Canada, May 4-8, 2015, pp 51–60
  * Muhanna (1991) Muhanna WA (1991) Composite programs: Hierarchical construction, circularity, and deadlocks. IEEE Trans Software Eng 17(4):320–333, URL http://dblp.uni-trier.de/db/journals/tse/tse17.html#Muhanna91
  * Oizumi et al. (2014) Oizumi WN, Garcia AF, Colanzi TE, Ferreira M, von Staa A (2014) When code-anomaly agglomerations represent architectural problems? an exploratory study. In: 2014 Brazilian Symposium on Software Engineering, Maceió, Brazil, September 28 - October 3, 2014, pp 91–100, DOI 10.1109/SBES.2014.18
  * Palomba et al. (2016) Palomba F, Zanoni M, Fontana FA, Lucia AD, Oliveto R (2016) Smells like teen spirit: Improving bug prediction performance using the intensity of code smells. In: ICSME, IEEE Computer Society, pp 244–255
  * Park (2012) Park CS (2012) Active testing: Predicting and confirming concurrency bugs for concurrent and distributed memory parallel systems. PhD thesis, University of California, Berkeley, USA, base-search.net (ftcdlib:qt7n4120mp)
  * Park (2013) Park S (2013) Debugging non-deadlock concurrency bugs. In: Pezzè M, Harman M (eds) ISSTA, ACM, pp 358–361
  * Park et al. (2010) Park S, Vuduc RW, Harrold MJ (2010) Falcon: fault localization in concurrent programs. In: Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering-Volume 1, ACM, pp 245–254
  * Pearson (1895) Pearson K (1895) Note on regression and inheritance in the case of two parents. Proceedings of the Royal Society of London 58:240–242
  * Ramson and Hirschfeld (2017) Ramson S, Hirschfeld R (2017) Active expressions: Basic building blocks for reactive programming. Programming Journal 1(2):12, URL http://dblp.uni-trier.de/db/journals/programming/programming1.html#RamsonH17
  * Rizzi et al. (2018) Rizzi L, Fontana FA, Roveda R (2018) Support for architectural smell refactoring. In: Proceedings of the 2nd International Workshop on Refactoring, IWoR@ASE 2018, Montpellier, France, September 4, 2018, pp 7–10
  * Roveda et al. (2018) Roveda R, Arcelli Fontana F, Pigazzini I, Zanoni M (2018) Towards an architectural debt index. In: Proceedings of the Euromicro Conference on Software Engineering and Advanced Applications (SEAA), Technical Debt track, IEEE, Prague, Czech Republic
  * Schütz (2001) Schütz D (2001) Permit based locking. In: EuroPLoP, UVK - Universitaetsverlag Konstanz, pp 347–360
  * Shull et al. (2008) Shull FJ, Carver JC, Vegas S, Juristo N (2008) The role of replications in empirical software engineering. Empirical Software Engineering 13(2):211–218
  * Smith (2014) Smith SO (2014) Raft : automated techniques for diagnosing, reproducing, and fixing concurrency bugs. PhD thesis, University of Cambridge, UK, british Library, EThOS
  * Spearman (1904) Spearman C (1904) The proof and measurement of association between two things. American Journal of Psychology 15:88–103
  * Stallings (2012) Stallings W (2012) Operating Systems: Internals and Design Principles. Pearson
  * Suryanarayana et al. (2015) Suryanarayana G, Samarthyam G, Sharma T (2015) Refactoring for Software Design Smells, 1st edn. Morgan Kaufmann
  * Taibi and Lenarduzzi (2018) Taibi D, Lenarduzzi V (2018) On the definition of microservice bad smells. IEEE Software 35(3):56–62, DOI 10.1109/MS.2018.2141031, URL https://doi.org/10.1109/MS.2018.2141031
  * Tchamgoue et al. (2011) Tchamgoue GM, Ha OK, Kim KH, Jun YK (2011) A taxonomy of concurrency bugs in event-driven programs. In: Kim Th, Adeli H, Kim Hk, Kang Hj, Kim KJ, Kiumi A, Kang BH (eds) Software Engineering, Business Continuity, and Education, Springer Berlin Heidelberg, Berlin, Heidelberg, pp 437–450
  * Terra et al. (2012) Terra R, Valente MT, Czarnecki K, Bigonha RS (2012) Recommending refactorings to reverse software architecture erosion. In: Proceedings of the 2012 16th European Conference on Software Maintenance and Reengineering, IEEE Computer Society, Washington, DC, USA, CSMR ’12, pp 335–340, DOI 10.1109/CSMR.2012.40, URL http://dx.doi.org/10.1109/CSMR.2012.40
  * Voellmy et al. (2010) Voellmy A, Agarwal A, Hudak P (2010) Nettle: Functional reactive programming for OpenFlow networks. Tech. rep., Yale University
  * Wohlin (2006) Wohlin C (2006) Empirical software engineering: Teaching methods and conducting studies. In: Empirical Software Engineering Issues, Springer, Lecture Notes in Computer Science, vol 4336, pp 135–142
  * Wu et al. (2015) Wu S, Yang C, Chan WK (2015) Asr: Abstraction subspace reduction for exposing atomicity violation bugs in multithreaded programs. In: QRS, IEEE, pp 272–281
  * Yoshiura and Wei (2014) Yoshiura N, Wei W (2014) Static data race detection for java programs with dynamic class loading. In: International Conference on Internet and Distributed Computing Systems, Springer International Publishing, Cham, pp 161–173, DOI 10.1007/978-3-319-11692-1˙14
  * Zalewski (2005) Zalewski J (2005) From software sensitivity to software dynamics: performance metrics for real-time software architectures. SIGBED Review 2(3):20–24, URL http://dblp.uni-trier.de/db/journals/sigbed/sigbed2.html#Zalewski05
  * Zhang et al. (2011) Zhang W, Lim J, Olichandran R, Scherpelz J, Jin G, Lu S, Reps T (2011) ConSeq: Detecting Concurrency Bugs Through Sequential Errors. In: Proceedings of the Sixteenth International Conference on Architectural Support for Programming Languages and Operating Systems, ACM, ASPLOS XVI, pp 251–264, DOI 10.1145/1950365.1950395
  * Zhou et al. (2015) Zhou B, Neamtiu I, Gupta R (2015) Predicting concurrency bugs: how many, what kind and where are they? In: Lv J, Zhang HJ, Babar MA (eds) EASE, ACM, pp 6:1–6:10


# Measurement of strong coupling constant by using event shape moments in
perturbative theory

L. Khajooee  T. Kalalian  R. Saleh-Moghaddam  A. Sepehri  M. E. Zomorrodian
Department of Physics, Faculty of sciences, Ferdowsi university of Mashhad,
91775-1436, Mashhad, Iran

###### Abstract

We measure the strong coupling constant at NNLO corrections. We do this
analysis with moments of event shape variables: thrust, C parameter, heavy
hemisphere mass, wide and total jet broadening, by fitting the L3 and DELPHI
data with NNLO model. Our real data are consistent with NNLO calculations,
because it involves higher order terms in QCD calculations.

13.66.Bc; 11.15.Me; 12.38.Bx Keywords: Hadron production in e+ e-
interactions; Strong coupling constant; Perturbative theory

##  1 Introduction

Analyses of events originating from ${e}^{+}e{}^{-}$ annihilation into hadrons
allow for studies [1, 2, 3, 4, 5, 6] of Quantum Chromo Dynamics (QCD), the
theory of the strong interaction [7, 8, 9, 10, 11, 12]. Comparison of
observables such as jet production rates or event shapes with theoretical
predictions provides access to the determination of the strong coupling
($\alpha_{s}$). Recently significant progress in the theoretical calculations
of event shape moments and three jet rates has been made [13].

Event shape variables are interesting for studying the interplay between
perturbative and non-perturbative dynamics. Apart from distributions of these
observables one can study mean values and higher moments. The $n\ th$ moment
of an event shape observable $Y$ is defined by [14]:

$\left\langle
y^{n}\right\rangle=\,\frac{1}{\sigma_{had}}\int_{\,\,\,0}^{\,\,\,y_{\max}}y^{n}\,\frac{d\sigma}{dy}dy$
(1)

where ${y}_{\max}$ is the kinematically allowed upper limit of the observable.

Measurements of the strong coupling ($\alpha_{s}$) of QCD, the theory of
strong interaction, using different observables and different analysis methods
serve as an important consistency test of QCD.

In section 2, we perform a new extraction of $\alpha_{s}$ from L3 and DELPHI
data with Next to Next Leading Order (NNLO) model and measure the strong
coupling constant at NNLO then we compare the moment observables with other
experiments. The last section includes our conclusions.

##  2 NNLO corrections to event shape moments in electron positron
annihilation

###  2.1 Definition of the observables

The properties of hadronic events may be characterized by a set of event shape
observables. In this subsection 2.1 briefly recall the definitions of the
relevant event shape observables. The event shape variables are defined by the
following sentences.

Thrust (T) defined by the expression [15, 16, 17, 18]:

$T=\max\left(\frac{\sum_{i}\left|\vec{P}_{i.}\vec{n}\right|}{\sum_{i}\left|p_{i}\right|}\right)$
(2)

The thrust axis $\vec{n}_{T}$ is the direction $\vec{n}$ which maximizes the
expression in parentheses the value of the thrust can vary between $0.5$ and
$1$.

A plane through the origin and perpendicular to $\vec{n}_{T}$ divides the
event into two hemispheres ${H}_{1}$ and ${H}_{2}$.

C-Parameter: The linearized momentum tensor $\theta^{ij}$ is defined by [19,
20]:

$\theta^{ij}=\frac{1}{\sum_{1}\left|\vec{P}_{L}\right|}\sum_{k}\frac{P_{k}^{i}P_{k}^{i}}{\left|\vec{P}_{k}\right|},i,j=1,2,3$
(3)

Where the sum runs over all final state particles and ${P}_{k}^{i}$ is the $i\
th$ component of the three – momentum $\vec{P}_{k}$of particle $k$ in the
center of mass system. The tensor $\theta$ is normalized to have unit trace.
In terms of the eigenvalues of the $\theta$ tensor,
$\lambda_{1},\lambda_{2},\lambda_{3},with\lambda_{1}+\lambda_{2}+\lambda_{3}=1,$
one defines

$C=3(\lambda_{1}\lambda_{2}+\lambda_{2}\lambda_{3}+\lambda_{3}\lambda_{1})$
(4)

The c-parameter exhibits in perturbation theory a singularity at the three-
parton boundary $c=\frac{3}{4}$

Heavy hemisphere mass ( $\rho$): The hemisphere masses are defined by [21]

$M_{i}^{2}=\,\left(\begin{array}[]{l}{\sum Pj}\\\ {j\in
H_{i}}\end{array}\right)^{2},i=1,2$ (5)

where ${P}_{j}$ denotes the four-momentum of particle j. The heavy hemisphere
mass ${M}_{H}$ is then defined by:

$M_{H}^{2}=\,\max\,\left(M_{1}^{2}\,,\,M_{2}^{2}\right)$ (6)

It is convenient to introduce the dimensionless quantity

$\rho=\frac{M_{H}^{2}}{Q^{2}}$ (7)

where $Q$ is the centre of mass energy. In leading order the distribution of
the heavy hemisphere mass ($\rho$) is identical to the distribution of
$(1-T)$.

Jet broadening observables ${B}_{T}$ and ${B}_{W}$:

The hemisphere broadening [22, 23, 24, 25, 26] are defined by

$B_{K}=\,\left(\frac{\sum_{i\in\,H_{K}}\left|\vec{p}_{i}\times\vec{n}_{T}\right|}{2\sum_{i}\left|\vec{p}_{i}\right|}\right)$
(8)

For each of the two event hemispheres, ${H}_{K}$ defined above. The two
observables are defined by:

$B_{T}=B_{1}+B_{2}\,\,\,\,\,\,\,\,\,\,\,\,,\,and\,\,\,\,\,\,B_{W}=\max\,\left(B_{1},B_{2}\right)$
(9)

where ${B}_{T}$ is the total and ${B}_{W}$ is the wide jet broadening.

###  2.2 Theoretical framework

The perturbative QCD expansion for the moment of the event shape observable
$y$ up to NNLO at centre-of- mass energy $\sqrt{S}$ for renormalization scale
$\mu^{2}=s$ and $\alpha_{s}\equiv\,\alpha_{s}\left(S\right)$ is given by [14]:

$\left\langle
y^{n}\right\rangle\,\,\left(s,\,\mu^{2}=s\right)=\,\left(\frac{\alpha_{s}}{2\pi}\right)^{1}\,\overline{A}_{y,n}+\,\left(\frac{\alpha_{s}}{2\pi}\right)^{2}\,\overline{B}_{y,n}+\,\left(\frac{\alpha_{s}}{2\pi}\right)^{3}\,\overline{C}_{y,n}+O\left(\alpha_{s}\right)^{4}$
(10)

The detailed calculations of the coefficients ${A}_{y,n}$ , ${B}_{y,n}$ and
${C}_{y,n}$ was achieved by Gehrmann et.al, [14, 27]. In addition
$\overline{A}_{y,n},\,\,\overline{B}_{y,n}\,\,and\,\,\,\overline{C}_{y,n}$ are
related to ${A}_{y,n}$ , ${B}_{y,n}$ and ${C}_{y,n}$ according to;

$\displaystyle\overline{A}_{y,n}$ $\displaystyle=\,A_{y,n}$ (11)
$\displaystyle\overline{B}_{y,n}$
$\displaystyle=\,B_{y,n}-\,\frac{3}{2}\,C_{F}\,\,A_{y,n},$ (12)
$\displaystyle\overline{C}_{y,n}$
$\displaystyle=\,C_{y,n}-\frac{3}{2}\,C_{F}B_{y,n}+\left(\frac{9}{4}C_{F}^{2}-K_{2}\right)A_{y,n}$
(13)

The constant ${K}_{2}$ is given by [28, 29]

$K_{2}=\frac{1}{4}\left[-\frac{3}{2}C_{F}^{2}+C_{F}\,C_{A}\left(\frac{123}{2}-44\zeta_{3}\right)+C_{F}T_{R}N_{F}\left(-22+16\zeta_{3}\right)\right]$
(14)

Where the QCD color factors are:

$C_{A}=N\,,\,\,C_{F}=\frac{N^{2}-1}{2N},\,\,\,\,T_{R}=\frac{1}{2}$ (15)

For $N=3$ colours and ${N}_{F}$ light quark flavors. The coefficients $A$, $B$
and $C$ have been computed for several event-shape variables In terms of the
running coupling $\alpha_{s}\left(\mu^{2}\right)$ the NNLO expression for an
event shape moment measured at centre-of-mass energy squared s becomes [14]:

$\left\langle
y^{n}\right\rangle\,\left(s,\mu^{2}\right)=\,\left(\frac{\alpha_{s}\left(\mu\right)}{2\pi}\right)\,\overline{A}_{y,n}+\,\left(\frac{\alpha_{s}\left(\mu\right)}{2\pi}\right)^{2}\left(\overline{B}_{y,n}+\overline{A}_{y,n}\,\beta_{\circ}\,\log\,\frac{\mu^{2}}{s}\right)+\left(\frac{\alpha_{s}\left(\mu\right)}{2\pi}\right)^{3}$
$\left(\overline{C}_{y,n}+2\overline{B}_{y,n}\,\beta_{\circ}\,\log\,\frac{\mu^{2}}{s}+\overline{A}_{y,n}\left(\beta_{\circ}^{2}\,\log^{2}\,\frac{\mu^{2}}{s}+\beta_{1}\,\log\,\frac{\mu^{2}}{s}\right)\right)+o\left(\alpha_{s}^{4}\right).$
(16)

In which

$\begin{array}[]{l}{\beta_{\circ}=\,\frac{11C_{A}-4T_{R}N_{F}}{6}}\\\
{\beta_{1}=\,\frac{17C_{A}^{2}\,\,-10C_{A}\,T_{R}\,N_{F}\,-6C_{F}\,T_{R}\,N_{F}}{6}}\end{array}$
(17)

##  3 physics results

Moments of event shapes have been measured by various ${e}^{+}e^{-}$ collider
experiments at centre-of- mass energies ranging from $40$ GeV to $207$ GeV
[30, 31].

To determine $\alpha_{s}$ at each energy point, the measured distributions are
fitted in the ranges of energies. In this paper we use the experimental data
for the five variables at $\left\langle\sqrt{s}\right\rangle=200.2\ GeV$. The
scale uncertainly is obtained by repeating the fit for different values of the
renormalization scale in the interval $0.5\sqrt{s}\leq\mu\leq 2\sqrt{s}$ [32].

The moments of the five standard event shapes are displayed in Figures 1 and
2. The predictions are compared to ${L}_{3}$ and DELPHI data. Our real data
are consistent with NNLO, compared with NLO or LO calculations, because it
involves higher order terms in QCD calculations [14].

Figure 1: First moments of Five event shape variables fitted with eq (16), the
data are from the $L3$ and DELPHI experiments, taken from refs [30, 31].
Figure 2: Second moments of Five event shape variables fitted with eq(16), the
data are from the L3 and DELPHI experiments, taken from refs [30, 31].

The value of $\alpha_{s}$ was estimated by fitting the data [30, 31] with NNLO
expression for an event shape moment (16). Separate fits were performed to
each of the five observables at centre-of- mass energies ranging from $40$ GeV
to $207$ GeV [30, 31]. The fitted values for $\alpha_{s}$ change for different
choices of the renormalization scale. This is demonstrated for the moments of
event shapes in tables 1-5. The given errors are the statistical errors. We
also have indicated on each table the value of ${\alpha}_{{\rm
S}}{\rm(}M_{Z}{\rm)}$ extracted at $M_{{\rm Z}}$ energy. We don’t observe any
significant change between the values of strong coupling constant for
different event shape moments and renormalization scales.

Table 1: Measurement of $\alpha_{s}$ from $\left\langle{(B}_{T})\right\rangle$ and $\left\langle{{(B}_{T})}^{2}\right\rangle$ moments for different choices of the renormalization scale. Event shape variable | $\mu$ | $\alpha_{s}$
---|---|---
$\left\langle{(B}_{T})\right\rangle$ | ${\sqrt{s}}/{4}$ | $0.1327\pm 0.0008$
$M_{{\rm Z}}$ | $0.1268\pm 0.0008$
${\sqrt{s}}/{3}$ | $0.1254\pm 0.0009$
${\sqrt{s}}/{2}$ | 0.1188$\pm 0.0009$
$\sqrt{s}$ | $0.1131\pm 0.0009$
| $2\sqrt{s}$ | $0.1104\pm 0.0009$
$\left\langle{{(B}_{T})}^{2}\right\rangle$ | ${\sqrt{s}}/{4}$ | $0.1345\pm 0.0022$
$M_{{\rm Z}}$ | $0.1294\pm 0.0020$
${\sqrt{s}}/{3}$ | $0.1285\pm 0.0021$
${\sqrt{s}}/{2}$ | 0.1230$\pm$0.0021
$\sqrt{s}$ | $0.1182\pm 0.0021$
| $2\sqrt{s}$ | $0.1159\pm 0.0020$
Table 2: Measurement of $\alpha_{s}$ from $\left\langle 1-T\right\rangle$ and $\left\langle{\left(1-T\right)}^{2}\right\rangle$ moments for different choices of the renormalization scale. Event shape variable | $\mu$ | $\alpha_{s}$
---|---|---
$\left\langle 1-T\right\rangle$ | ${\sqrt{s}}/{4}$ | $0.1339\pm 0.0024$
$M_{{\rm Z}}$ | $0.1298\pm 0.0021$
${\sqrt{s}}/{3}$ | $0.1273\pm 0.0023$
${\sqrt{s}}/{2}$ | $0.1211\pm 0.0022$
$\sqrt{s}$ | $0.1158\pm 0.0021$
| $2\sqrt{s}$ | $0.1133\pm 0.0021$
$\left\langle{\left(1-T\right)}^{2}\right\rangle$ | ${\sqrt{s}}/{4}$ | $0.1377\pm 0.0049$
$M_{{\rm Z}}$ | $0.1364\pm 0.0039$
${\sqrt{s}}/{3}$ | $0.1316\pm 0.0047$
${\sqrt{s}}/{2}$ | $0.1260\pm 0.0045$
$\sqrt{s}$ | $0.1210\pm 0.0043$
| $2\sqrt{s}$ | $0.1186\pm 0.0042$
Table 3: Measurement of $\alpha{}_{s}$ from $\left\langle{(B}_{W})\right\rangle$ and $\left\langle{{(B}_{W})}^{2}\right\rangle$ moments for different choices of the renormalization scale. Event shape variable | $\mu$ | $\alpha_{s}$
---|---|---
$\left\langle{(B}_{W})\right\rangle$ | ${\sqrt{s}}/{4}$ | $0.1297\pm 0.0009$
$M_{{\rm Z}}$ | $0.1249\pm 0.0006$
${\sqrt{s}}/{3}$ | $0.1228\pm 0.0008$
${\sqrt{s}}/{2}$ | $0.1159\pm 0.0007$
$\sqrt{s}$ | $0.1097\pm 0.0006$
| $2\sqrt{s}$ | $0.1068\pm 0.0006$
$\left\langle{{(B}_{W})}^{2}\right\rangle$ | ${\sqrt{s}}/{4}$ | $0.1231\pm 0.0016$
$M_{{\rm Z}}$ | $0.1195\pm 0.0013$
${\sqrt{s}}/{3}$ | $0.1166\pm 0.0015$
${\sqrt{s}}/{2}$ | $0.1107\pm 0.0014$
$\sqrt{s}$ | $0.1055\pm 0.0014$
| $2\sqrt{s}$ | $0.1031\pm 0.0013$
Table 4: Measurement of $\alpha_{s}$ from $\left\langle\ C\ \right\rangle$ and $\left\langle\ C^{2}\ \right\rangle$ moments for different choices of the renormalization scale. Event shape variable | $\mu$ | $\alpha_{s}$
---|---|---
$\left\langle\ C\ \right\rangle$ | ${\sqrt{s}}/{4}$ | $0.1324\pm 0.0019$
$M_{{\rm Z}}$ | $0.1272\pm 0.0017$
${\sqrt{s}}/{3}$ | $0.1258\pm 0.0019$
${\sqrt{s}}/{2}$ | $0.1197\pm 0.0018$
$\sqrt{s}$ | $0.1144\pm 0.0018$
| $2\sqrt{s}$ | $0.1120\pm 0.0017$
$\left\langle\ C^{2}\ \right\rangle$ | ${\sqrt{s}}/{4}$ | $0.1364\pm 0.0039$
$M_{{\rm Z}}$ | $0.1335\pm 0.0029$
${\sqrt{s}}/{3}$ | $0.1305\pm 0.0038$
${\sqrt{s}}/{2}$ | $0.1249\pm 0.0036$
$\sqrt{s}$ | $0.1200\pm 0.0035$
| $2\sqrt{s}$ | $0.1177\pm 0.0035$
Table 5: Measurement of $\alpha_{s}$ from $\left\langle\ \rho\ \right\rangle$ and $\left\langle\ {\rho}^{2}\ \right\rangle$ moments of the renormalization scale. Event shape variable | $\mu$ | $\alpha_{s}$
---|---|---
$\left\langle\ \rho\ \right\rangle$ | ${\sqrt{s}}/{4}$ | $0.1367\pm 0.0021$
$M_{{\rm Z}}$ | $0.1304\pm 0.0020$
${\sqrt{s}}/{3}$ | $0.1287\pm 0.0020$
${\sqrt{s}}/{2}$ | $0.1215\pm 0.0019$
$\sqrt{s}$ | $0.1153\pm 0.0018$
| $2\sqrt{s}$ | $0.1124\pm 0.0018$
$\left\langle\ {\rho}^{2}\ \right\rangle$ | ${\sqrt{s}}/{4}$ | $0.1317\pm 0.0035$
$M_{{\rm Z}}$ | $0.1260\pm 0.0033$
${\sqrt{s}}/{3}$ | $0.1246\pm 0.0033$
${\sqrt{s}}/{2}$ | $0.1180\pm 0.0030$
$\sqrt{s}$ | $0.1124\pm 0.0029$
| $2\sqrt{s}$ | $0.1098\pm 0.0028$

We observe that our obtained values for coupling constant considering the NNLO
corrections for different event shape variables are in good agreement with the
other experiments [10].

##  4 Conclusions

In this paper we have presented measurements of the strong coupling constant
for hadronic events produced at $L3$ and DELPHI in the centre-of-mass energies
$40$ GeV to $207$GeV. We measured the coupling constant considering the
moments of the event shape observables using next-to-next leading order (NNLO)
calculations for different choices of the renormalization scale. Our results
are consistent with those obtained from other experiments, as well as with the
QCD theory.

## References

  * [1] V. Abazov, et al, D Collaboration Phys. Rev. D 80 071102 (2009).
  * [2] Alexey Pak, Mikhail Rogal and Matthias Steinhauser, Phys. Lett. B 679 473-477 (2009).
  * [3] T. Aaltonen, et al, Phys.Rev.D 80 051104 (2009).
  * [4] V. Abazov, et al, Phys.Rev.Lett.103132001 (2009).
  * [5] U. Langenfeld, S. Moch, P. Uwer, Phys. Rev. D 80 054009 (2009).
  * [6] R. Barate et.al [ALEPH Collaboration] Eur. Phys. J. C 18 1(2000) [arXiv: hep-ex/0008013].
  * [7] G. Abbiendi et.al [OPAL Collaboration] Eur. Phys. J. C 21 411(2001) [arXiv: hepex/0105046].
  * [8] G. Abbiendi et.al [JADE and OPAL Collaboration] Eur. Phys. J. C 17 19 (2000).
  * [9] W Bartel et.al [JADE Collaboration] Z. Phys. C 33 23 (1986).
  * [10] A. Gehrmann, T. Gehrmann, E.W.N. Glover and G. Heinrich, JHEP 0712 094 (2007).
  * [11] A. Gehrmann, T. Gehrmann, E.W.N. Glover and G. Heinrich, POS (RAD COR) 048 (2007).
  * [12] Stefan Weinzierl, JHEP 0906 041 (2009).
  * [13] M. E. zomorrodian, A. Sepehri, A. Moradi Marjaneh, International Journal of Physics 1 3 1-10 (2010).
  * [14] A. Gehrmann-De Ridder, T. Gehrmann, E.W.N. Glover and G. Heinrich, JHEP 0905 106 (2009) [100].
  * [15] A. Gehrmann, T. Gehrmann,E.W.N. Glover and G. Heinrich, JHEP 0711 058 (2007).
  * [16] G. Dissertori, A. Gehrmann, T. Gehrmann, E.W.N. Glover, G. Heinrich and H. Stenzel, Nucl.Phys.Proc.Suppl.183 2-7(2008).
  * [17] D.A. Kosower, Phys. Rev. D 57 5410 (1998).
  * [18] A. Daleo, T. Gehrmann and D. Maˆ$\imath$tre, JHEP 0704 016 (2007).
  * [19] A. Gehrmann-De Ridder, T. Gehrmann and E.W.N. Glover, JHEP 0509 056 (2005).
  * [20] A. Gehrmann-De Ridder, T. Gehrmann, E.W.N. Glover and G. Heinrich, Phys. Rev. Lett. 100 172001 (2008).
  * [21] A. Gehrmann-De Ridder, T. Gehrmann, E.W.N. Glover and G. Heinrich, Phys. Rev. Lett. 99 132002 (2007).
  * [22] Stefan Weinzierl, JHEP 0906 041(2009).
  * [23] Stefan Weinzierl, Phys.Rev.Lett.101 162001 (2008).
  * [24] Stefan Weinzierl, JHEP 0907 009 (2009).
  * [25] G. Dissertori, A. Gehrmann-De Ridder, T. Gehrmann, E.W.N. Glover, G. Heinrich and H. Stenzel, Nucl.Phys.Proc.Suppl.183 2-7 (2008).
  * [26] S. Catani, B. R. Webber, Y. L. Dokshitzer and F. Fiorani, Nucl. Phys. B 383 419 (1992).
  * [27] A. Gehrmann-De Ridder, T. Gehrmann, E.W.N. Glover and G. Heinrich, JHEP 0712 094 (2004).
  * [28] S. Catani, S. Dittmaier and Z. Trocsanyi, Phys. Lett. B 500 149 (2001) [arXiv: hep-ph/0011222].
  * [29] M. Cacciari and S. Catani, Nucl. Phys. B 617 253 (2001) [arXiv: hep-ph/0107138].
  * [30] S. Catani, S. Dittmaier, M. H. Seymour and Z. Trocsanyi, Nucl. Phys. B 627 189 (2002) [arXiv: hep-ph/0201036].
  * [31] M. Cacciari and E. Gardi, Nucl. Phys. B 664 299 (2003) [arXiv: hep-ph/0301047].
  * [32] L3 Collaboration, Phys.Rept.399 71-174 (2004).