\documentclass{acm_proc_article-sp}
\usepackage{graphicx,calc,alltt,amssymb,latexsym,oz}
\input{Macros}
\input{nocomments}
\begin{document}
%
% --- Author Metadata here ---
%\conferenceinfo{OOPSLA}{'05 San Diego, CA USA}
%\setpagenumber{50}
%\CopyrightYear{2002} % Allows default copyright year (2002) to be over-ridden - IF NEED BE.
%\crdata{0-12345-67-8/90/01} % Allows default copyright data (X-XXXXX-XX-X/XX/XX) to be over-ridden.
% --- End of Author Metadata ---
\title{Extracting and Evolving Mobile Games Product Lines}
%
% You need the command \numberofauthors to handle the "boxing"
% and alignment of the authors under the title, and to add
% a section for authors number 4 through n.
%
% Up to the first three authors are aligned under the title;
% use the \alignauthor commands below to handle those names
% and affiliations. Add names, affiliations, addresses for
% additional authors as the argument to \additionalauthors;
% these will be 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{1}
%
% You can go ahead and credit authors number 4+ here;
% their names will appear in a section called
% "Additional Authors" just before the Appendices
% (if there are any) or Bibliography (if there
% aren't)
\additionalauthors{Additional authors: John Smith (The
Th{\o}rv\"{a}ld Group, email: {\texttt{jsmith@affiliation.org}}) and
Julius P.~Kumquat (The Kumquat Consortium, email:
{\texttt{jpkumquat@consortium.net}}).}
% Put no more than the first THREE authors in the \author command
\author{
%
% 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.
\alignauthor Vander Alves Pedro Matos Jr. Leonardo Cole \\ Alexandre Damasceno Pedro Sampaio Paulo Borba\\ Geber Ramalho\ \affaddr{Informatics Center}\ \affaddr{Federal University of Pernambuco}\ \affaddr{Meantime Mobile Creations}\ \affaddr{Recife, Pernambuco, Brazil}\ \email{\{vra,poamj,lcn,phmb,glr\}@cin.ufpe.br}\ \email{\{pedro.macedo,alexandre.damasceno\}@meantime.com.br}\%\alignauthor Pedro Matos Jr.\%% \affaddr{Institute for Clarity in Documentation}\%% \affaddr{P.O. Box 1212}\%% \affaddr{Dublin, Ohio 43017-6221}\% \email{poamj@cin.ufpe.br}
%\alignauthor Leonardo Cole\%% \affaddr{The Th{\large{\sf{\o}}}rv{$\ddot{\mbox{a}}$}ld Group}\%% \affaddr{1 Th{\large{\sf{\o}}}rv{$\ddot{\mbox{a}}$}ld Circle}\%% \affaddr{Hekla, Iceland}\% \email{lcn@cin.ufpe.br}
%\alignauthor Paulo Borba \% \email{phmb@cin.ufpe.br}
%\alignauthor Alexandre Damasceno\% \email{algd@cesar.org.br}
%\alignauthor Pedro Sampaio\% \email{pedro.macedo@meantime.com.br}
%\alignauthor Geber Ramalho\% \email{glr@cin.ufpe.br}
}
\date{30 July 1999}
\maketitle
\begin{abstract}
In order to benefit from the product line approach, an adoption
strategy must be in place. Frequently, the proactive strategy is
inadequate due to the prohibitively high investment and risks,
whereas the extractive and the reactive approaches are incremental
and offer moderate cost. However, combining the latter two has been
not been addressed systematically. This paper presents a systematic
approach for extracting a product line and evolving it. The method
relies on a strategy combining application of refactorings, which
are expressed in terms of simpler aspect-oriented programming laws.
The approach is evaluated with a case study, involving an
industrial-strength J2ME game.
\end{abstract}
\section{Introduction}
As software demands grow in various domains with ever-increasing
quality standards and shorter development cycles, software product
lines have emerged as a promise to not only improve quality and
lower development costs, but also to reduce time-to-market. A
software product line (PL) consists of a set of products developed
from the same set of artifacts and targeted at a specific
domain~\cite{lindanbook}. Indeed, by moving to the product line
approach, an organization may increase its competitiveness in a
specific domain of software development. At the same time, adopting
this approach involves both organizational and technical
commitments.
The first key task in the PL approach is deciding on adoption. A
number of alternatives exist, such as the proactive, reactive and
extractive approaches~\cite{kruegerPFE04}. Since the proactive
approach scopes and supports all products in the foreseeable
horizon, it demands a high up front investment and offers risks;
therefore, it is not suitable for many organizations. In contrast,
the other two approaches have shorter scope and thus require less
investment, but are incremental approaches. An interesting paradigm
is combining the two latter approaches, which has not been addressed
systematically at architectural and coding levels.
In either adoption strategies, variability management must be
addressed in the domain: while focusing on exploiting the
communality within the products, adequate support must be available
for customizing the core in order to derive a particular product
line instance. The more diverse the domain, the harder it is to
accomplish this task, which in some cases may outweigh the cost of
developing the product line core itself.
There are a number of techniques for accomplishing this from
requirements to code level. Most of them rely on object-oriented
concepts such as inheritance. These techniques, however, are
well-known for failing to capture crosscutting concerns. In fact,
highly variant domains frequently present this kind of concerns.
Mobile games, in particular, must comply with a strict portability
requirement, whose implementation is considerably crosscutting,
which suggests applying Aspect-Oriented Programming~\cite{}
This paper addresses the issue of structuring and evolving product
lines in highly variant domains. In particular, we present an
approach which relies on the combination of the extractive and the
reactive paradigms, by initially extracting variation from an
existing application and then reactively adapting the newly created
product line to encompass another product variant. The method
systematically supports both the extractive and the reactive tasks
by defining refactorings, which we derive formally from simpler
aspect-oriented programming laws. Further, we evaluate our approach
in the context of an industrial-strength mobile game product line.
The remainder of this paper is organized as follows.
Section~\ref{sec_variation} describes the variation issues in J2ME
games, which is our application domain. Section~\ref{sec_process}
describes our approach, including its strategy, extractive and
reactive refactorings, and basic programming laws from which these
refactorings can be systematically. The industrial case study
evaluating the approach is presented in Section~\ref{sec_case}. We
discuss related work in Section~\ref{sec_related} and conclude in
Section~\ref{sec_conclusion}.
\section{Variation in J2ME Games}
\label{sec_variation}
%fine-grained variation
Game development is usually regarded simpler for mobile devices than
for desktop platforms. Indeed, the resources provided by the latter
support more complex applications, and the development cycle tends
to be longer. On the other hand, mobile games (and mobile
applications, in general) must adhere to a stronger portability
requirement. This stems form business constraints: in order to
target more users, who own different kinds of devices, service
carriers typically demand from developers that a single application
be deployed in a dozen or more platforms.
Each platform generally provides some vendor-specific Application
Programming Interface (API) with mandatory or optional advanced
features, which the developer is likely to employ in order to
improve game quality. In addition, some devices may have memory
constraints for application size or heap size, which further
requires the developer to optimize the application. In either case,
adapting the game for each such platform is necessary.
At the same time, most functionality is shared among all
device-specific variants. Therefore, in order to optimize software
engineering effectiveness and efficiency, such communality should be
consolidated and maintained in a single source, and platform
variation should be managed in such a way that it is easily viewed,
reasoned about, and mechanized~\cite{kruegerPFE05}. As the number of
target devices grows, however, this becomes an issue.
Although this is a critical problem for this domain, most current
approaches address this problem in an \emph{ad hoc} or superficial
way. Indeed, current industrial solutions mostly rely on
non-scalable techniques such as conditional
compilation~\cite{antennaprep,j2mepolish} .or on general
guidelines~\cite{ngameforum,nportingforum,faconport}, which are more
descriptive than prescriptive and thus less effective. Contemporary
research in the area depends on a series of hypothesis constraining
applicability or have not been tested in industry
yet~\cite{aosdgui,aosdmixin}.
We consider game development for mobile phones using J2ME's MIDP
profile, which is targeted at mobile devices with constrained
resources, including reduced memory and computing power, and
intermittent low-bandwidth connectivity~\cite{midp10}. Our focus is
on analyzing and managing the specific kinds of variations arising
due to platform variation, where \emph{platform} means a combination
of MIDP and some vendor-specific API. Accordingly, some of the
specific challenges for managing variation in this domain are the
following:
\begin{itemize}
\item UI features, such as screen size, number of colors, pixel depth, sound, keypad display;
\item Available
heap memory and maximum application bytecode size;
\item Different profile versions (MIDP 1.0 and MIDP 2.0);
\item Different implementation of the same profile;
\item Proprietary APIs and optional packages ; \item Known
device-specific bugs\emph{Bugs} ;
\item Different idioms.
\end{itemize}
As our analysis in Section~\ref{sec_case} reveals, these specific
kinds of variation tend to be considerably fine-grained and
generally crusscut the game and tangle with other kinds of
variation. This suggests Aspect-Oriented Programming
(AOP)~\cite{kiczales97aspectoriented} as a suitable candidate for
representing these variations.
\section{Game Product Line}
\label{sec_case}
In our scope, we explore the platform variation arising due to use
of proprietary API. In particular, there are three platforms
($P_{A}$, $P_{B}$, and $P_{C}$) on which the same game GM is run
(the actual names are not relevant here). $P_{A}$ relies solely on
MIDP 1.0, whereas $P_{B}$ and $P_{C}$ rely on MIDP 1.0 and
proprietary API. GM is an actual game delivered by service carries
in South America and Asia. Figure 1 illustrates its main screen.
\begin{figure}[htb]
\begin{center}
\scalebox{0.37}{
\includegraphics{fig1.jpg}
} \caption{Platform
variation of the GM game}
\end{center} \label{fig_games}
\end{figure}
The variability issues in this game product line are as follows:
\begin{itemize}
\item optional images
\item proprietary API
\item bytecode size limit
\item screen dimensions
\item additional keys
\end{itemize}
One important remark is that these features are not independent.
Indeed, bytecode size constrains other features, such as optional
images and additional keys. The effect of these in source code of
two platforms has been cataloged in Table~\ref{tab:1}. Figures shows
a glimpse of the variation patterns in source code.
\begin{table}
\caption{Efeitos do porte no c\'{o}digo fonte, listando os tipos de
varia\c{c}\~{a}o e sua freq\"{u}\^{e}ncia. \label{tab:1}}
\begin{center}
\begin{tabular}{|l|c|}
\hline \hline Tipo de varia\c{c}\~{a}o & Freq\"{u}\^{e}ncia(\%)\\hline Argumento de chamada de m\'{e}todo & 34\\ \hline Constante
de classe & 20\\ \hline Vari\'{a}vel local & 11\\ \hline Atributo &
9\\ \hline API gr\'{a}fica & 8\\ \hline Express\~{a}o para detectar
soft key adicional & 5\\ \hline Express\~{a}o diferente & 4\\ \hline
Express\~{a}o de c\'{a}lculo gr\'{a}fico & 7\\ \hline Hierarquia de
classes & 3\\ \hline M\'{e}todo & 3\\ \hline
\end{tabular}
\end{center}
\end{table}
\begin{figure}[!]
\begin{center}
\scalebox{0.17}{
\includegraphics{t01.png}
} \caption{Platform
variation of the GM game}
\end{center} \label{fig_games}
\end{figure}
\begin{figure}[!]
\begin{center}
\scalebox{0.17}{
\includegraphics{t02.png}
} \caption{Platform
variation of the GM game}
\end{center} \label{fig_games}
\end{figure}
\begin{figure}[!]
\begin{center}
\scalebox{0.17}{
\includegraphics{t03.png}
} \caption{Platform
variation of the GM game}
\end{center} \label{fig_games}
\end{figure}
\begin{figure}!
\begin{center}
\scalebox{0.17}{
\includegraphics{t04.png}
} \caption{Platform
variation of the GM game}
\end{center} \label{fig_games}
\end{figure}
\begin{figure}!
\begin{center}
\scalebox{0.17}{
\includegraphics{t05.png}
} \caption{Platform
variation of the GM game}
\end{center} \label{fig_games}
\end{figure}
\begin{figure}!
\begin{center}
\scalebox{0.17}{
\includegraphics{t06.png}
} \caption{Platform
variation of the GM game}
\end{center} \label{fig_games}
\end{figure}
\section{Process}
\label{sec_process}
Contrary to the proactive approach, which is more like the waterfall
model and scopes for all products in the foreseeable horizon, we
rely instead on a combination of the extractive and the reactive
approaches. There are a number of reasons for this. First, small to
medium-sized organizations, which still want to benefit from the PL
approach, cannot afford the high cost incurred in adopting the
proactive adoption strategy. Second, depending on the domain, such
as mobile device game development, the development cycle is so short
that prevents the completion of the proactive planning. Third, there
are also risks associated in that strategy, since the scope may
become invalid due to new customer requirements.
Our approach first bootstraps the PL and then evolves it with a
reactive approach. Initially, there is only one product in the PL;
this implementation has been refactored in order to expose some
variation. Next, the PL scope is extended to encompass another
product: that is, the PL reacts to accommodate the new variant.
During this step, not only refactorings are performed-that maintain
the existing product- but also a PL extension that adds the new
variant. Then, at this point the PL may react to further extension
or may be refactored.
The proposed strategy is systematic because it relies on a
collection of refactorings. In the spirit of our previous work
\cite{cole:aosd:2005,cole:foal:2005}, such refactorings are
described in terms of templates, which are more concise and
declarative than the approach in \cite{fowler99refactoring}, which
entails a fixed implementation, whereas ours allows alternative
approaches such as program transformations tools. In addition, the
refactoring preconditions --a frequently subtle issue in
refactorings--, are more clearly organized. Furthermore, the
refactorings are systematically derived from more elementary and
simpler programming laws. The laws are appropriate for that because
they are considerably simpler than most refactorings. In contrast,
such laws involve only localized program changes, and each one
focuses on a specific language construct.
In the remaining of this section, we detail the steps of our
strategy, explaining the extractive and the reactive processes,and
their associated refactorings. In the next section, we present the
derivation of these refactorings from primitive programming laws.
\subsection{Extraction}
The first step of our strategy is extracting the PL: from one or more
existing product variants, we extract a common core and
corresponding product specific adaptation constructs. According to
the variability nature of our domain, these constructs correspond
to Aspectj constructs. Figure~\ref{fig_games} depicts this
approach.
\begin{figure}[htb]
\begin{center}
\scalebox{0.37}{
\includegraphics{figura1.png}
}
\caption{Bootstrapping the Product Line}
\end{center} \label{fig_games}
\end{figure}
Product1 and Product2 are existing versions of the game for two
platforms. Game Core contains encompasses common code to these
platforms. Aspect and Aspect' adapt the core for these respective
platforms.
In order to extract such variations, these must first be identified
in the existing base. When more than one variant exists, the
diff-like views also provide an alternative. In either case, however, is too
detailed a view at this point. Indeed, the developer needs to know
what are the general concerns involved. This could be described
more concisely and abstractly with concerns graphs~\cite{}. So the
actual first step in identifying these variations is to build a concern
graph corresponding to known variability issues. For our case study,
these would be the ones in Table~\ref{tab:1}. For example, the concern
graph for the optional images concern would be as follows:
The second step is to visit each of the concern members and analyze
the variability pattern the developer wishes to apply (only one prodcut exists)
or to represent (two or more products exist). At this point the more detailed view of
diff-like tools is appropriate. The developer must consider
whether the feature in question is alternative, optional, or
mandatory~\cite{gpbook} . Accordingly, s/he can apply one refactoring to handle a variation
pattern. For example, examining the optional figures concern,
\begin{verbatim}
class Resources {...
private static Image dragonRight;...
static void loadImages() { ...
dragonRight = Image.createImage("dragonRight.png");
...
}
}
\end{verbatim}
where we note that such static attribute is not used anywhere else
in \texttt{loadImages()}. We may decide that \texttt{dragonRight}
is an optional feature specific to one platform and thus could
extract it into an aspect with inter-type declaration and advice.
Thus we would have
\begin{verbatim}
class Resources { ...
static void loadImages() {...
}
Aspect Platform1 {
Image Resources.dragonRight;
after() : execution(Resources.loadImages()) {
dragonRight = Image.createImage("dragonRight.png");
}
}
\end{verbatim}
where \texttt{Resources} now represents a construct in Game Gore and
\texttt{Platform1} an aspect adapting it for a specific platform
(Figure~\ref{fig_games}). This refactoring occurred frequently and
we thus generalized it in the following template:
%%%%%%%%%% Extract Resource to Aspect - after %%%%%%%%%%%%%%%%%%%%%
\begin{Refactoring}{Extract Resource to Aspect - after}
\label{intr:extresafter}
\vspace{-0.3cm}
\begin{quote}
\begin{framedCode}
\cc{ts}
\cc{\class C \lbrace}
\cc{fs; T f}
\cc{ms}
\cc{T' m(ps) \lbrace}
\cc{body}
\cc{\this.f=exp;}
\cc{body'}
\cc{\rbrace}
\cc{\rbrace}
\end{framedCode}%
\codeIsEqualTo
\begin{framedCode}
\cc{ts}
\cc{\class C \lbrace}
\cc{fs}
\cc{ms}
\cc{T' m(ps) \lbrace}
\cc{body}
\cc{body'}
\cc{\rbrace}
\cc{\rbrace}
\cc{\paspect A \lbrace}
\cc{T C.f;}
\cc{pcs}
\cc{\after(context)}
\cc{\returning(T' t):}
\cc{\execution(\sigma(C.m))\&\&}
\cc{bind(context) \lbrace}
\cc{cthis.f=}
\cc{exp[cthis/\this]}
\cc{\rbrace}
\cc{as}
\cc{\rbrace}
\end{framedCode}
\end{quote}
\textbf{provided}
\begin{quote}
\begin{description}
\item[$(\rightarrow)$] $exp$ does not use local
variables; $exp$ dos not call \super; $body'$ does not update $f$ or
fields used in $exp$;
\item[$(\leftarrow)$] $A$ has the highest precedence on the join points involving the
signature $\sigma(C.m)$;
\end{description}
\end{quote}
\end{Refactoring}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
The variation patterns we observed in some games in this domain motivated the definition of the
refactorings listed in Table~\ref{tab2}.
Another variation pattern arises when examining the Flip concern,
specific to platform 2. The Flip feature of the device allows
flipping an image and thus there is no need for a flipped image
file. An examination of the following class shows Flip
implementation one of the class it affects
\begin{verbatim}
class Enemy {
paint(Graphics g) {
if (this.getXspeed() > 0) {
offSetX = -7*(this.getWidth());
g.drawImage(this.getImage(), this.getX()+offSetX,
this.getY(), g.TOP | g.LEFT);
}
else {
DirectGraphics dg = DirectUtils.getDirectGraphics(g);
dg.drawImage(this.getImage(),
this.getX()-offSetX,
this.getY(),
g.TOP | g.LEFT,
DirectGraphics.FLIP_HORIZONTAL);
}
}
}
\end{verbatim}
\begin{figure*}
\begin{center}
\scalebox{0.37}{
\includegraphics{p2.jpg}
} \caption{Evolving the
Product Line}
\end{center} \label{fig_games}
\end{figure*}
%%%%%%%%%% Extract Method to Aspect %%%%%%%%%%%%%%%%%%%%%
\begin{Refactoring}{Extract Method to Aspect}
\label{intr:extmeth}
\vspace{-0.3cm}
\begin{quote}
\begin{framedCode}
\cc{ts}
\cc{\class C \lbrace}
\cc{fs}
\cc{ms}
\cc{T m(ps) \lbrace}
\cc{body}
\cc{body'}
\cc{body'\-'}
\cc{\rbrace}
\cc{\rbrace}
\end{framedCode}%
\codeIsEqualTo
\begin{framedCode}
\cc{ts}
\cc{\class C \lbrace}
\cc{fs}
\cc{ms}
\cc{T m(ps) \lbrace}
\cc{body}
\cc{newm(\alpha\-ps');}
\cc{body'\-'}
\cc{\rbrace}
\cc{\rbrace}
\cc{\paspect A \lbrace}
\cc{T' C.newm(ps')\lbrace}
\cc{body'}
\cc{\rbrace}
\cc{pcs}
\cc{as}
\cc{\rbrace}
\end{framedCode}
\end{quote}
\textbf{provided}
\begin{quote}
\begin{description}
\item[$(\rightarrow)$] $body'$ does not change more than one local
variable;
\item[$(\leftarrow)$] Method $newm$ is not polymorphic;
\item[$(\leftrightarrow)$] $A$ does not introduce any field to $C$ with the same name of a $C$ field used in
$body'$;
\end{description}
\end{quote}
\end{Refactoring}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{figure*}
\begin{center}
\scalebox{0.37}{
\includegraphics{p3.jpg}
} \caption{Refactoring the
Product Line}
\end{center} \label{fig_games}
\end{figure*}
\begin{figure*}
\begin{center}
\scalebox{0.37}{
\includegraphics{p4.jpg}
} \caption{Further evolution
of the Product Line}
\end{center} \label{fig_games}
\end{figure*}
\subsection{Evolution}
Once the product line has been bootstrapped (either from one or more
products), it can evolve to encompass additional products.
%%%%%%%%%% merge advices before %%%%%%%%%%%%%%%%%%%%%
\begin{Refactoring}{Extract Aspect Communality}
\label{intr:mergeBefore} \vspace{-0.3cm}
\begin{quote}
\begin{framedCode}
\cc{} \cc{ts}
\cc{\paspect A \lbrace}
\cc{pcs}
\cc{bars}
\cc{\before(ps):exp1\lbrace}
\cc{body}
\cc{\rbrace}
\cc{bars'}
\cc{afs}
\cc{\rbrace}
\cc{\paspect B \lbrace}
\cc{pcs}
\cc{as}
\cc{bars}
\cc{\before(ps):exp2\lbrace}
\cc{body}
\cc{\rbrace}
\cc{bars'}
\cc{afs}
\cc{\rbrace}
\cc{\paspect C \lbrace}
\cc{pcs}
\cc{bars}
\cc{afs}
\cc{\rbrace}
\end{framedCode}%
\codeIsEqualTo
\begin{framedCode}
\cc{} \cc{ts}
\cc{\paspect A \lbrace}
\cc{pcs}
\cc{bars}
\cc{bars'}
\cc{afs}
\cc{\rbrace}
\cc{\paspect B \lbrace}
\cc{pcs}
\cc{bars}
\cc{bars'}
\cc{afs}
\cc{\rbrace}
\cc{\paspect C \lbrace}
\cc{pcs}
\cc{bars}
\cc{\before(ps):}
\cc{exp1||exp2 \lbrace}
\cc{body}
\cc{\rbrace}
\cc{afs}
\cc{\rbrace}
\end{framedCode}
\end{quote}
\textbf{provided}
\begin{quote}
\begin{description}
\item[$(\leftarrow)$] $exp1$ and $exp2$ bind all parameters in $ps$.
\item[$(\rightarrow)$] The set of join points captured by $exp1$ and $exp2$ are disjoint;
\item[$(\leftrightarrow)$] $exp1$ and $exp2$ do not rely on locally defined pointcuts;
\end{description}
\end{quote}
\end{Refactoring}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Refactoring decomposition}
** Colocar a ref do paper do workshop. No fonte latex coloquei o
bibtex dela em comentario*****
%@InProceedings{cole:foal:2005,
% Author = {Leonardo Cole and Paulo Borba and Alexandre Mota},
% Title = {Proving aspect-oriented programming laws},
% BookTitle = {FOAL 2005 Proceedings: Foundations of Aspect-Oriented
% Langauges Workshop at AOSD 2005},
% year = 2005,
% Organization = {Department of Computer Science, Iowa State University},
% Series = {Technical Report},
% month = Mar,
%}
In this section we use aspect-oriented programming laws and
refactorings derived from them \cite{cole:aosd:2005,cole:foal:2005}
to show that the previously discussed refactorings are behaviour
preserving transformations. Programming laws \cite{laws:1987} are
suitable for that because they are much simpler than most
refactorings. Contrasting with refactorings, they involve only
localized program changes, and each one focus on a specific language
construct. They also help to more precisely specify the
preconditions associated with those refactorings.
For example, the following law has the purpose of moving the
implementation of a single method into an aspect using an inter-type
declaration. This simple transformation is easier to understand and
reason about. According to the AspectJ semantics, visibility
modifiers of inter-type declarations are related to the aspect and
not to the affected class. Hence, it is possible to declare a
private field as a class member and as an inter-type declaration at
the same time and using the same name. As a consequence,
transforming a member method that uses this field, into an
inter-type declaration, imply that the method now uses the aspect
inter-typed field. This leads to a change in behaviour. A
precondition is necessary to avoid this problem.
%%%%%%%%%% move method to aspect %%%%%%%%%%%%%%%%%%%%%
\begin{Law}{19}{Move Method to Aspect}
\label{intr:moveMethod}
\vspace{-0.3cm}
\begin{quote}
\begin{framedCode}
\cc{ts}
\cc{\class C \lbrace}
\cc{fs}
\cc{ms}
\cc{T m(ps) \lbrace}
\cc{body}
\cc{\rbrace}
\cc{\rbrace}
\cc{\paspect A \lbrace}
\cc{pcs}
\cc{as}
\cc{\rbrace}
\end{framedCode}%
\codeIsEqualTo
\begin{framedCode}
\cc{ts}
\cc{\class C \lbrace}
\cc{fs}
\cc{ms}
\cc{\rbrace}
\cc{\paspect A \lbrace}
\cc{T C.m(ps) \lbrace}
\cc{body}
\cc{\rbrace}
\cc{pcs}
\cc{as}
\cc{\rbrace}
\end{framedCode}
\end{quote}
\textbf{provided}
\begin{quote}
\begin{description}
\item[$(\leftrightarrow)$] $A$ does not introduce any field to $C$ with the same name of a $C$ field used in
$body$
\end{description}
\end{quote}
\end{Law}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
We denote a set of pointcut declarations and a list of advice
declarations as \textit{pcs} and \textit{as}, respectively. The
presented law is the only aspect-oriented transformation necessary
to accomplish the Refactoring \ref{intr:extmeth}, showed in Section
\ref{sec:refactorings}. However, we first need to apply an
object-oriented refactoring. Deriving the refactoring from left to
right, we apply \textit{Extract Method} \cite{fowler99refactoring}.
This refactoring creates a new method in class $C$ called $newm$
with proper parameters and return type, which executes the piece of
code labeled as body'. The \textit{Extract Method} can only be
applied if the extracted code does not change more than one local
variable, or else the extracted method would need multiple return
values. In the opposite direction, we use \textit{Inline Method}
\cite{fowler99refactoring}, which can only be applied if method
$newm$ is not polymorphic. The object-oriented refactorings can be
proven to be sound using object-oriented programming laws
\cite{rool:2004}.
Note that the scenario after the method extraction is the left side
of Law 19. If the target aspect already exists, we can apply this
law to end the transformation. If the target aspect does not exist,
it would be necessary to use Laws 1 and 2 \cite{cole:aosd:2005} to
create a new aspect and make it privileged. At this point we
complete the derivation of Refactoring \ref{intr:extmeth}. The
sequence of laws necessary to accomplish this refactoring is shown
in Figure \ref{fig:extractMethod}.
\begin{figure}[ht]
\centering
\begin{tabular}{|cccc|} \hline
($\rightarrow$)&Extract Method&$\rightarrow$&Law 19\($\leftarrow$)&Law 19&$\rightarrow$&Extract Method\\hline
\end{tabular}
\caption{Extract Method to Aspect} \label{fig:extractMethod}
\end{figure}
Similarly to the previous refactoring, the Refactoring
\ref{intr:extresafter} (\textit{Extract Resource to Aspect - after})
can be represented as a sequence of object-oriented transformations
and aspect-oriented programming laws. In this case we first need to
rearrange the source code (left hand side) because AspectJ do not
provide any mechanism to introduce crosscutting behaviour in the
middle of a method. In order to move the crosscutting code to an
aspect we need to move the crosscutting code to the beginning or
ending of the method. This allows the creation of a \texttt{before}
or \texttt{after} advice, respectively. This code can generally be
moved if it is independent of the remaining method code, this means
that the crosscutting code do not update any state used by the
remaining method code. Once the crosscutting code is at the end of a
method, we can use Law 5 (\textit{Add after-execution returning
successfully}) to create a new advice that is triggered after the
method's successful execution.
\vspace{0.3cm}
%%%%%%%%%% Introduce new advice after a method execution returning successfully%%%%%%%%%%%%%%%%%%%%%
\begin{Law}{5}{Add After-Execution Returning Successfully}
\label{law:afterReturningExec}
\vspace{-0.3cm}
\begin{quote}
\begin{framedCode}
\cc{}\cc{ts}
\cc{\class C \lbrace}
\cc{fs}
\cc{ms}
\cc{T m(ps) \lbrace}
\cc{body;}
\cc{body'}
\cc{\rbrace}
\cc{\rbrace}
\cc{\paspect A \lbrace}
\cc{pcs}
\cc{bars}
\cc{afs}
\cc{\rbrace}
\end{framedCode}%
\codeIsEqualTo
\begin{framedCode}
\cc{}\cc{ts}
\cc{\class C \lbrace}
\cc{fs}
\cc{ms}
\cc{T m(ps) \lbrace}
\cc{body}
\cc{\rbrace}
\cc{\rbrace}
\cc{\paspect A \lbrace}
\cc{pcs}
\cc{bars}
\cc{afs}
\cc{\after(context)}
\cc{\returning(T t):}
\cc{\execution(\sigma(C.m))\&\&}
\cc{bind(context) \lbrace}
\cc{body'[cthis/\this]}
\cc{\rbrace}
\cc{\rbrace}
\end{framedCode}
\end{quote}
\textbf{provided}
\begin{quote}
\begin{description}
\item[$(\rightarrow)$] $body'$ does not declare or use local
variables; $body'$ does not call \super;
\item[$(\leftrightarrow)$] $A$ has the highest precedence on the join points involving the signature $\sigma(C.m)$;
\end{description}
\end{quote}
\end{Law}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
We use $\sigma(C.m)$ to denote the signature of method $m$ of class
$C$, including its return type and the list of formal parameters.
Moreover, we use $context$ to denote the list of advice parameters,
including the executing object (mapped to a parameter named $cthis$)
and the method's parameters ($ps$). We use $bind(context)$ to denote
the expression of pointcut designators that bind the advice
parameters (\texttt{this}, \texttt{target}, and \texttt{args}). The
laws always expose the maximum context available. For example, Law 5
can expose the executing object and the formal parameters of the
captured method. Considering a method \texttt{credit} in an
\texttt{Account} class, the expanded advice signature looks like the
code shown next. In this case, $context$ is the parameter list
(\texttt{Account cthis, float amount}) and $bind(context)$ is the
expression \texttt{this}\texttt{(cthis)} \&\&
\texttt{args}\texttt{(amount)}.
\begin{center}
\begin{verbatim}
before(Account cthis, float amount) :
execution(void Account.credit(float)) &&
this(cthis) && args(amount)
\end{verbatim}
\end{center}
Note that the advices can not be considered as a set, since order of
declaration dictates precedence of advices. According to the AspectJ
semantics, if two advices declared in the same aspect are
\texttt{after}, the one declared later has precedence; in every
other case, the advice declared first has precedence. Thus, we
divide the list of advices in two. The first part (\textit{bars})
contains the list of all \texttt{before} and \texttt{around}
advices, while the second part contains only \texttt{after} advices
(\textit{afs}). This separation ensures that \texttt{after} advices
always appear at the end of the aspect. It also allows us to define
exactly the point where the new advice should be placed to execute
in the same order in both sides of the law. Additionally, for
advices declared in different aspects, precedence depends on their
hierarchy or their order in a \texttt{declare precedence} construct.
Examining the left hand side of Law 5, we see that $body'$ executes
before all \texttt{after} advices declared for this join point. It
also executes before all the \texttt{around} advices, intercepting
this join point, call \texttt{proceed}\footnote{\texttt{Around}
advices may skip execution of lower precedence advices, as well as
the method itself, if it does not call \texttt{proceed}.}. This
means that the new advice on the right hand side of the law should
be the first one to execute, preserving the order in which the code
is executed in both sides of the law. Thus, the \texttt{after}
advice should be placed at the end of the \texttt{after} list.
Moreover, to ensure that the new advice created with Law 5 is the
first one to execute, we have a precondition stating that aspect $A$
has the highest precedence over other aspects defined in $ts$. This
precondition must hold in both directions.
As we move $body'$ to an aspect, its visible context changes as
well. Hence, it is necessary to constrain the context dependencies
in order to guarantee that the law relates valid AspectJ programs.
Therefore, we impose conditions on accessing local variables and
calls to \texttt{super} and \texttt{return}. Local variables can
generally be removed using object-oriented programming laws
\cite{rool:2004}. We obligate the use of \texttt{this} to access
class members to enable the mapping of accesses to the object
referenced by \texttt{this} to the object exposed as the executing
object on the advice ($cthis$). The mapping is denoted by the
expression $body'[cthis/$\this$]$, where we substitute all
occurrences of $this$ with the variable $cthis$ in $body'$.
Nevertheless, there are other implications that must be considered.
Changes to the method execution flow (calls to \texttt{return}) are
generally not allowed because the advice can not implement it, or it
would increase complexity. This precondition is necessary to ensure
that the law preserves behaviour.
Resuming the Refactoring \ref{intr:extresafter} derivation, we
restructure the code moving the crosscutting behaviour to the end of
a method. Then apply Law 5 to move the crosscutting behaviour to a
new advice that is triggered after the method finishes execution
with success. This accomplish the refactoring transformation from
left to right. To derive the transformation represented by the
opposite direction, we only need to inver the order of
transformations applied. This is different from Refactoring
\ref{intr:extmeth}, where we needed different object-oriented
refactorings to derive the two transformations. The summary of
transformations necessary to accomplish this refactoring is shown in
Figure \ref{fig:moveResource}.
\begin{figure}[ht]
\centering
\begin{tabular}{|cccc|} \hline
($\rightarrow$)&Rearrange Code&$\rightarrow$&Law 5\($\leftarrow$)&Law 5&$\rightarrow$&Rearrange Code\\hline
\end{tabular}
\caption{Extract Resource to Aspect - after}
\label{fig:moveResource}
\end{figure}
Other refactorings can similarly be derived from programming laws.
This increases the confidence that they preserve behaviour.
Additionally, representing the refactorings as a composition of
programming laws helps to better define the preconditions in which
those refactorings are valid.
\section{Related Work}
\label{sec_related}
\section{Conclusions}
\label{sec_conclusion}
\section{Acknowledgments}
We thank Meantime Mobile Creations for providing the game for the
case study, and, in particular, Alexandre Damasceno and Pedro
Sampaio for discussion regarding currently used porting techniques.
We also would like to thank our collaborators from the Software
Productivity Group for many important comments. This work was
partially supported by CAPES and CNPq, brazilian research
\bibliographystyle{abbrv}
\bibliography{refTotal}
\end{document}
Copyright © 2008-2025 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki?
Send feedback 
Edit | Attach | Print version | History: %REVISIONS% | Backlinks | Raw View | Raw edit | More topic actions