Вы находитесь на странице: 1из 8

“thesis” — 2011/2/25 — 15:51 — page 3 — #21

Chapter 1

Introduction

This dissertation presents research contributions that deal with the architecture
level modelling and analysis support for software performance in legacy systems.
In this chapter we lay out the research setting. We start with describing the
context of the research in section 1.1. Next to the context, in section 1.2
we elaborate research problems and state aim and objectives to solve these
problems. In section 1.3, we formulate a research strategy to achieve the defined
objectives. A summary of our contributions is given in section 1.4. We conclude
this chapter with an outline of the thesis text in section 1.5.

1.1 Context

1.1.1 Quality Attributes

Quality Attributes (QA) which are also known as non-functional requirements,


are characteristics of a software system that define its quality factors. Among
them are performance, availability, security and extensibility. Although there is
no universal agreement on a standard list of QAs, their significant impact on
the overall quality of a system is recognized widely. They provide the means
for measuring the quality of a system, which according to IEEE Standard 1061-
1992 is "Software quality is the degree to which software possesses a desired
combination of quality attributes" [13].
Software performance, which is linked with multiple quality factors is one
of the important QAs of a software system [5]. Its linkage with multiple

3
“thesis” — 2011/2/25 — 15:51 — page 4 — #22

4 INTRODUCTION

quality factors makes it harder to agree upon a single widely accepted definition
of performance. However, we find following two definitions more expressive.
According to IEEE Standard Glossary of Software Engineering Terminology
[IEEE-610.12], performance is "The degree to which a system or component
accomplishes its designated functions within given constraints, such as speed,
accuracy, or memory usage" [14]. Smith in [30] describes performance as
"Performance refers to responsiveness: either the time required to respond to
specific events or the number of events processed in a given interval of time".
Based on these definitions, performance can be perceived as a characteristic of
the system that represents its timeliness behaviour.

1.1.2 Architecture Level Evaluation of Quality Attributes

Although a system should work correctly according its functional requirements,


it must also achieve its quality goals set in the form of QAs. In order to know
if a system has achieved its required quality or not, it needs to be evaluated.
Failing to meet the quality goals generally endangers the success of a system.
Determining what, when and how to evaluate a system’s quality is a difficult
task. Potential risks to QAs should be find and fix early in the development
life cycle. Any unresolved issue with QAs may lead to a major refactoring,
increased cost and delays.
Architectural decisions are among the earliest made in the development life cycle,
preventing errors with them can help in building a high quality system. It has
long been acknowledged that architecture level analysis of QAs is a cost-effective
approach [6][20]. For a legacy system it provides an opportunity to find and
fix issues before extensions to the system. Additionally, it provides support to
recover and document design decisions made during the system development.
Whereas for new systems, in an iterative development methodology, architecture
level analysis helps in assessing the quality of the system before moving to the
next iteration.
Considering the importance of the performance QA, it is vital to ensure up-front,
that right architectural choices has been made to meet performance specific
quality goals. From the point of view of performance evaluation, success or
failure of a system is mostly determined by the choices that are made at the
architectural level [27]. For existing systems where no information about design
decisions is available, it becomes a challenging task to recover performance
specific architecture of the system. Although it is hard, but once reconstructed,
an architecture of an existing system is valuable artefact for future extensions
to the system.
“thesis” — 2011/2/25 — 15:51 — page 5 — #23

PROBLEM STATEMENT 5

1.2 Problem Statement

Within the context of evaluating QAs at architecture level for legacy systems,
we investigated two research problems. These problems deal with two aspects
of the performance: the use of parallelism and flow latencies. In the following
subsections we elaborate both research problems.

1.2.1 Parallelism

The use of parallelism (multithreading) for software systems is becoming


increasingly more important because of the potential benefits it provides.
Multithreaded applications are considered to be more efficient because of
their better software and hardware resource utilization caused by the parallel
execution of tasks. However, overheads and difficulties associated to parallelism
amplify dramatically as the number of threads increase. Among them are
context switches and thread creation/deletion overheads, incorrect time and
task distribution and complex thread management structure. Especially in
legacy systems, where design decisions are usually not available, excessive use of
multithreading proves to be problematic. Identification and mitigation of these
issues in such cases is extremely hard. Parallelism-intensive software systems,
which employ a large number of threads to perform required system functionality,
suffer from the above-mentioned overheads. An optimized threading model
is important to attain the true benefits of multithreading, which is generally
nonexistent for such systems.
Techniques, such as source code analysis and profiling are commonly used to
analyze threads of a multithreaded software system. However, as the size of the
code base increases the use of these techniques becomes difficult. Furthermore,
for legacy systems whose design decisions are usually not available, these
techniques are not suitable to understand the decisions made for the thread
model of the system.
A variety of specialized tools is also available to analyze the thread model of
a software system, such as Intel Parallel Studio [15], Rational PurifyPlus [25],
Valgrind [33] and Acumem ThreadSpotter [1]. These tools provide support for
analyzing the thread model from a single perspective. None of the available
tools provides support for analyzing a system for aforementioned problems on
the whole. For instance, Intel Parallel Studio, Valgrind and ThreadSpotter
can be used to analyze threads for deadlocks and data race issues. Rational
PurifyPlus on the other hand, offers support for time distribution across threads.
Moreover, the majority of them are commercial tools, which associates a cost.
Using multiple tools together is neither a feasible nor a cost-effective solution.
“thesis” — 2011/2/25 — 15:51 — page 6 — #24

6 INTRODUCTION

We argue that comprehensive support for thread analysis is indispensable to


mitigate overheads associated to threads. Such support is currently lacking
in existing techniques and tools. To provide such comprehensive support we
introduce the use of architecture level analysis.

1.2.2 Flow Latencies

In general, every software system consists of multiple flows of information. These


flows carry a piece of information from one component of a system to another,
or from one place to another in the same component. Flowing information from
one point to another consumes a certain time, which is called latency of the
flow. Flow latency is the amount of time it takes for information to flow from
the starting point to its destination [9]. Such flows are also called End-to-End
(EtE) because they have a starting and an ending point. Because latencies are
directly linked with the timing property of a system, any unresolved issue with
them can degrade the performance of a system. An architecture description of
flows can be used to find and fix issues with latencies upfront. However, support
provided by Architecture Description Languages (ADL) to describe and analyze
flows at architecture level is limited. We find lack of support particularly while
describing those EtE flows which themselves are internally composed of multiple
EtE flows. We call these flows as composite flows. Modelling and analysis
support for such flows is important because they help in understanding flows
and their latencies at different level of abstractions. A single EtE flow being at
one level of abstraction, whereas a combination of multiple EtE in the form of
a composite flow defines another level of abstraction.
An example of composite flow can be seen from the electron microscope software
system. A fundamental function of an electron microscope is to move a specimen
from one point to another. The software system receives a command from its
user to move the specimen, moves it and sends an acknowledgment back to the
user when that movement is finished. An EtE flow in this case is the specimen
move command. This single EtE flow internally is composed of many EtE flows,
which were created as a part of propagating the move command through various
components of the system.
Our research problem is to provide modelling support for those flows (composite
flows) which are composed of multiple EtE flows, and provide analysis
capabilities to analyze their latencies.
“thesis” — 2011/2/25 — 15:51 — page 7 — #25

RESEARCH STRATEGY 7

1.2.3 Aim and Objectives

Overall aim of the research presented in this dissertation is to provide


architecture level modelling and analysis support for:

• parallelism of parallelism-intensive software systems


• composite flows of flow intensive software systems

Following objectives have been set to fulfil this aim:

1. Develop techniques for extracting parallelism specific execution informa-


tion.
2. A methodology for developing architectural models from the extracted
information.

3. Develop analysis techniques to analyze architectural models for perfor-


mance overheads.
4. Find suitable modelling formalism to model flows.
5. Develop modelling techniques to model composite flows.

6. Provide necessary support to analyze latencies of the composite flows.

1.3 Research Strategy

To achieve the first two objectives, we developed an architecture viewpoint called


Parallelism Viewpoint (PV). It is a domain-specific form of the concurrency
viewpoint [12], which is used to describe the concurrent structure of a system.
The concurrency viewpoint mainly provides support for describing concerns
related to the communication and synchronization mechanisms of concurrent
systems. We extend this support for concurrent systems by describing parallelism
related concerns with our viewpoint. We identify parallelism specific concerns
and corresponding stakeholders, and develop architectural models that describe
these concerns.
We attain the third objective by developing a structured approach to perform
thread pool analysis. In our approach we analyze parallelism specific
architectural models of a software system, to find threads that are suitable to
be replaced with a small sized thread pool.
“thesis” — 2011/2/25 — 15:51 — page 8 — #26

8 INTRODUCTION

We achieve the fourth objective by performing a survey of existing ADLs, to


find an ADL with adequate support for modelling flows.
To achieve the last two objectives we extend the modelling and analysis
capabilities of the selected ADL for composite flows.

1.4 Contributions

We can categorized the contribution of this PhD dissertation into following two
categories.
Major Contributions

• Parallelism Viewpoint:
An architecture viewpoint to model parallelism behaviour of parallelism
intensive software system. The key feature of the viewpoint is to
provide an insight into the thread model of the system to find anomalies.
The viewpoint identifies parallelism specific concerns and corresponding
stakeholders of a system. We propose a parallelism specific execution
metamodel, which helps in focusing on parallelism related performance
overheads. Moreover, we propose a structured approach to harvest
information for elements of the metamodel and generating domain specific
architectural models from this information.

• Thread Pool Analysis:


We put forward a structured approach to analyze threads of a software
system for thread pooling. Thread pooling is an efficient multithreading
technique in which thread are reused from an existing pool, instead of
creating new threads for new jobs [24]. In our approach, by using the PV
models we identify the underused threads in a system and replace them
with a small sized pool of threads. By introducing a two level filtering in
the proposed approach we makes sure that right threads are picked for
replacement.
• Composite Flow Modelling and Analysis:
We devise a modelling technique for composite flows. In the proposed
technique we create necessary links between multiple EtE flows to compose
them into a single flow (composite flow). In addition, we render necessary
tool support to analyze latencies and composition of the composite flows.
“thesis” — 2011/2/25 — 15:51 — page 9 — #27

THESIS OUTLINE 9

Minor Contributions

• Extension to AADL:
Architecture Analysis and Design Language (AADL) is one of the best
known and most actively used architecture description language [10].
Originally developed for modelling and analysis of systems in the domain
of avionics [8], it has been standardized by the Society of Automotive
Engineers. Because of its rich modelling and analysis capabilities it is
widely used for systems in other domains as well. A big community in
research and industry is working to extend AADL’s capabilities to make it
a general purpose modeling language, which is suitable for systems from
a verity of domains. In our research work, we extended AADL to provide
modeling support for composite flows. Although, AADL provides basic
support for modelling EtE flows it lacks support for composite flows. We
believe that our extension to AADL is a step forward, to make it suitable
for flow-intensive software systems.

• Toolset
The information harvesting and model generation activities of the
viewpoint require a lot of efforts, which we reduce by providing necessary
tool support. We also automize various activities of the thread pool
analysis to reduce the associated labour and to perform a quicker analysis.

1.5 Thesis Outline

This dissertation contains six chapters. The remainder five chapters are
structured as following:
Background: In this chapter we present background material on architecture
views and viewpoints, and architecture description languages. We describe
AADL architecture description language in some detail. In the end, we introduce
three research cases that we used to validate our research. Among them are
a software system for electron microscope, Mozilla Firefox web browser and a
large-scale vehicular network system.
Parallelism Viewpoint: A Viewpoint to Model Parallelism in
Parallelism-Intensive Software Systems: In this chapter we describe the
fundamental building blocks of the Parallelism Viewpoint. We start with
identifying parallelism-specific concerns and their corresponding stakeholders in
section 3.1. In section 3.2, we outline a parallelism-specific execution metamodel,
an approach to harvest information for elements of the metamodel and generate
“thesis” — 2011/2/25 — 15:51 — page 10 — #28

10 INTRODUCTION

viewpoint models from this information. Finally, we present detailed description


of these models.
Thread Pool Analysis: This chapter starts with describing the proposed
thread pool analysis approach. Followed by its application for two research
cases: electron microscope software system and Firefox web browser. We discuss
results of the application and reflect upon the strengthens and meeknesses of
the proposed approach.
Modelling and Analyzing Composite Flows: In this chapter we elaborate
on composite flow, their scope and available modelling formalism to model
them. We describe the proposed modelling technique. Subsequently we use
it for electron microscope software system and large-scale vehicular network
system.
Conclusions and Future Work: In the final chapter we summarize our
research approach and contributions. We outline the important lesson learned
and the possible directions of future work.

Вам также может понравиться