-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathDraft_Proposal.tex
194 lines (155 loc) · 11.3 KB
/
Draft_Proposal.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
% THIS IS SIGPROC-SP.TEX - VERSION 3.1
% WORKS WITH V3.2SP OF ACM_PROC_ARTICLE-SP.CLS
% APRIL 2009
%
% It is an example file showing how to use the 'acm_proc_article-sp.cls' V3.2SP
% LaTeX2e document class file for Conference Proceedings submissions.
% ----------------------------------------------------------------------------------------------------------------
% This .tex file (and associated .cls V3.2SP) *DOES NOT* produce:
% 1) The Permission Statement
% 2) The Conference (location) Info information
% 3) The Copyright Line with ACM data
% 4) Page numbering
% ---------------------------------------------------------------------------------------------------------------
% It is an example which *does* use the .bib file (from which the .bbl file
% is produced).
% REMEMBER HOWEVER: After having produced the .bbl file,
% and prior to final submission,
% you need to 'insert' your .bbl file into your source .tex file so as to provide
% ONE 'self-contained' source file.
%
% Questions regarding SIGS should be sent to
% Adrienne Griscti ---> [email protected]
%
% Questions/suggestions regarding the guidelines, .tex and .cls files, etc. to
% Gerald Murray ---> [email protected]
%
% For tracking purposes - this is V3.1SP - APRIL 2009
\documentclass{acm_proc_article-sp}
\begin{document}
\title{A Case Study of Variability Spaces in Bitmessage
%\titlenote{(Does NOT produce the permission block, copyright information nor page numbering). For use with ACM\_PROC\_ARTICLE-SP.CLS. Supported by ACM.}}
%\subtitle{[Extended Abstract]
% These stuff will should be commented
\titlenote{A full version of this paper is available as
\textit{Author's Guide to Preparing ACM SIG Proceedings Using
\LaTeX$2_\epsilon$\ and BibTeX} at
\texttt{www.acm.org/eaddress.htm}}}
%
% You need the command \numberofauthors to handle the 'placement
% and alignment' of the authors beneath the title.
%
% For aesthetic reasons, we recommend 'three authors at a time'
% i.e. three 'name/affiliation blocks' be placed beneath the title.
%
% NOTE: You are NOT restricted in how many 'rows' of
% "name/affiliations" may appear. We just ask that you restrict
% the number of 'columns' to three.
%
% Because of the available 'opening page real-estate'
% we ask you to refrain from putting more than six authors
% (two rows with three columns) beneath the article title.
% More than six makes the first-page appear very cluttered indeed.
%
% Use the \alignauthor commands to handle the names
% and affiliations for an 'aesthetic maximum' of six authors.
% Add names, affiliations, addresses for
% the seventh etc. author(s) as the argument for the
% \additionalauthors command.
% These 'additional authors' will be output/set for you
% without further effort on your part as the last section in
% the body of your article BEFORE References or any Appendices.
\numberofauthors{2} % in this sample file, there are a *total*
% of EIGHT authors. SIX appear on the 'first-page' (for formatting
% reasons) and the remaining two appear in the \additionalauthors section.
%
\author{
% You can go ahead and credit any number of authors here,
% e.g. one 'row of three' or two rows (consisting of one row of three
% and a second row of one, two or three).
%
% The command \alignauthor (no curly braces needed) should
% precede each author name, affiliation/snail-mail address and
% e-mail address. Additionally, tag each line of
% affiliation/address with \affaddr, and tag the
% e-mail address with \email.
%
% 1st. author
\alignauthor
Mukesh Jha \\ %\titlenote{Mr.~Mukesh insisted his name be first.}\\
\affaddr{Masdar Institute}\\
\affaddr{Masdar City}\\
\affaddr{Abu Dhabi,UAE}\\
\email{[email protected]}
% 2nd. author
\alignauthor
Abraham Xiao\\
\affaddr{Masdar Institute}\\
\affaddr{Masdar City}\\
\affaddr{Abu Dhabi,UAE}\\
\email{[email protected]}
}
% There's nothing stopping you putting the seventh, eighth, etc.
% author on the opening page (as the 'third row') but we ask,
% for aesthetic reasons that you place these 'additional authors'
% in the \additional authors block, viz.
%\additionalauthors{Additional authors: John Smith (The Th{\o}rv{\"a}ld Group,
%email: {\texttt{[email protected]}}) and Julius P.~Kumquat
%(The Kumquat Consortium, email: {\texttt{[email protected]}}).}
%\date{30 July 1999}
% Just remember to make sure that the TOTAL number of authors
% is the number that will appear on the first page PLUS the
% number that will appear in the \additionalauthors section.
\maketitle
\begin{abstract}
Most of software are built to address the generic requirement and can be configured by the individual users as per their requirement and the system being installed in. In this research, we present a case study of Bitmessage, it's configurable features and the possible conflicts between them. This involves understanding the project implementation and investigating for anomalies and inconsistencies. Our work focuses on understanding how variability is implemented in open-source software and tries to discover the inconsistency in the system. Our goals include quantifying the variability in the software and investigating how the anomalies are introduced. Understanding the root cause of induction of inconsistency in software will help developers to make rational decisions while designing the software. It will further help in development of robust open-source softwares. This paper addresses the variability consistency issues in open-source softwares through Bitmessage as a case study.
\end{abstract}
% A category with the (minimum) three required fields
\category{H.4}{Management}{Software configuration management}
%A category including the fourth, optional field follows...
\category{D.2.8}{Software Engineering}{Variability}[variability inconsistency]
\terms{Theory}
\keywords{Configuration,feature models, Software Variability, Maintenance,Variability Anomalies, Bitmessage} % NOT required for Proceedings
\section{Introduction}
Most of software encompass different features to address the different requirements of users and the system on which it will be deployed. A configurable software can be defined as a software which allows user to select the features as per their interest and enables to install the software with the specified configuration without any redundancy and inconsistency. Different flavor of same software can be generated from common code base. The various features are inter-related, have common modules and also have constraints between themselves. This can be presented in some form of modeling and a mapping scheme is required to map the features with the code-modules. The variability models represent similar and different features/modules in a product line, which can be referred by developers to manage the addition and evolution of features and their dependencies. There are various automated tools supporting the variability analysis and checking the model consistency or detecting dead features \cite{Berger} \cite{Benavides}. Various names have been suggested to describe these parts of the system like feature model, problem/solution space. Nadi \cite{Nadi} suggests the use of word configuration space, build space, and code space to characterize the three information space that support variability in a system. The different information space entails different feature of system variability like configuration space specifies the features and their inter-dependency, build space is related to compilation process as per feature specified by the user and the code space is related to the source code of various functionality \cite{Nadi}.
Tartler et al. \cite{Tartler} detected many dead and unreachable code segments due to inconsistencies between the constraints in the configuration and code spaces. They used automatic compile-time consistency checks for Linux and yielded various inconsistencies. They suggested an approach for automatic consistency checks for compile-time configurable software which can consider the source of variability and automatically (cross-)check them for configurability related issues.
%%%
Most of earlier work is focused on isolated study of these individual space or how two of the space co-evolve together based on case study of pre-existing software. There has been no attempt for such analysis of actively developing open-source software like Bitmessage.
Bitmessage is a Peer-to-Peer communication protocol that allows user to send messages to another user or to many subscribers. It has unique and inter-related features such as anonymity, trustless, encryption, decentralized, authentication, scalability,
% and Proof-of-work. # POW is part of Authentication, so no need for this.
which makes it fit for such type of analysis \cite{Warren}. Our goal is to analyze the overlap between the features and information spaces in Bitmessage and discover if there is any conflict between them.
A software % Abraham: uncountable, suggest [a copy of software or a piece of software?]
has to even take care of operating system it will be deployed on. Most of the open-source softwares are developed either for Linux platform or windows platform. Bitmessage is developed for cross-platform. This makes Bitmessage more relevant for such variability analysis.
%Berger et al. \cite{Berger} showed that possibility of extraction of the presence conditions of the source code files from Makefile. They presented an prospective from the Operating Systems Domain using Linux as case study.
In this work, we study developing configurable open-source software, i.e. Bitmessage, to analyze how variability is implemented in practice, and how independently developed separate features can conflict with each other in open source software development. Such analysis can contribute to designing better architecture for features separation and improving the maintainability of existing code.
%%%
%%%%
%ACKNOWLEDGMENTS are optional
% Abraham: This may be commented, as required by Dr. Davor
\section{Acknowledgments}
We thank Dr. Davor Svetinovic for his valuable inputs and insightful discussions.
%
% The following two commands are all you need in the
% initial runs of your .tex file to
% produce the bibliography for the citations in your paper.
\begin{thebibliography}{1}
\bibitem{Berger}
T. Berger, S. She, R. Lotufo, A. Wasowski, and K. Czarnecki, "Variability modeling in the real: a perspective from the operating systems domain," in ASE '10: Proceedings of the IEEE/ACM international conference on Automated software engineering. ACM, 2010, pp. 73-82.
\bibitem{Benavides}
D. Benavides, S. Segura, and A. Ruiz-Cortes. Automated analysis of feature models 20 years later: a literature review. Information Systems, 2010.
\bibitem{Nadi}
Sarah Nadi, "A Study of Variability Spaces in Open Source Software", ICSE 2013 May 18th - 26th, 2013
\bibitem{Tartler}
R. Tartler, D. Lohmann, J. Sincero, and W. Schröder-Preikschat, "Feature Consistency in Compile-Time Configurable System Software," in Proceedings of the EuroSys 2011 Conference (EuroSys '11), G. Heiser and C. Kirsch, Eds., New York, NY, USA, 2011, pp. 47-60.
\bibitem{Warren}
Bitmessage White paper, Bitmessage: A PeertoPeer Message Authentication and Delivery
System, Jonathan Warren, Nov 2012
\end{thebibliography}
% You must have a proper ".bib" file
% and remember to run:
% latex bibtex latex latex
% to resolve all references
%
% ACM needs 'a single self-contained file'!
%
\end{document}