Horizontal Decomposition of Prevayler
Irum Godil and Hans-Arno Jacobsen
Middleware Systems Research Group, University of Toronto

as to persist data objects. Over the lifetime of the

Abstract
software system, it often evolves through the ad-

dition of new features and the modification of
Aspect-Oriented Programming (AOP) is an
existing ones. While some of these changes are
emerging paradigm to modularize crosscutting
imperative for the core functional requirements
concerns. A series of guidelines to refactor a
addressed by the system, others mainly increase
software system into a common core and a set of
the capabilities of the system without being cru-
variable functionalities have become known as
cial to the main cause. The evolution and imple-
Horizontal Decomposition (HD). In this paper we
mentation of all these features most often results
apply the HD principles to the Prevayler main
in entanglement in the code space of the system.
memory database management system. The objec-
Separation of concerns, feature modularization,
tive is to evaluate and refine these principles and
and a configurable product line architecture of the
to extract patterns of their use through a case
system is thus not easily achievable.
study on a popular open-source software system.
Aspect-oriented programming (AOP), an
Our evaluation shows that HD reveals six cross-
emerging programming paradigm, aims at achiev-
cutting functionalities. The refactoring of these
ing increased separation of concerns and modular-
concerns yield 36 different configurations of the
ity, especially with respect to crosscutting features
Prevayler system which were previously not pos-

[1]. AOP's steady progress from "bleeding edge"
sible. The refactoring also reduces the core Pre-
research to mainstream technology [2], demands
vayler code size by 53%, demonstrates a decrease
well-defined approaches, methodologies, and
of coupling between core functionality compo-
mechanisms for identifying and refactoring cross-
nents by 43%, and reduces the lack of cohesion of
cutting concerns as aspects in software systems.
the core system by 71%. Given the heterogeneous
The horizontal decomposition (HD) principles
nature of crosscutting displayed in Prevayler, the
constitute one set of techniques for this purpose
size and separation of concern metrics have not

[3]. The HD principles are a set of guidelines to,
reduced for the overall refactored system, i.e., for
firstly and most importantly, distinguish aspect
the core composed with the aspects. A posterior
functionalities from non-aspect ones, in order to
analysis of the re-engineering process reveals 22
lay out clear responsibilities for AOP and, sec-
refactoring patterns that could be readily used by
ondly, to enable superimpositional architectures
an automatic aspect refactoring tool.

[3]. A superimpositional architecture is a software
architecture that can be enriched with features
1 Introduction
represented by aspects according to the require-
ments of the user, the application domain, and the
A software system often supports a set of core
runtime environment. The HD principles have
functionalities. These functionalities constitute the
been successfully applied to resolve feature con-
essence of the system without which the system
volution from middleware systems [3]. Convolu-
does not achieve its main purpose. For instance,
tion in this context is a metaphor to refer to the
the main goal of a database system could be seen
interaction of many non-modularized features at a

single point in the code space of the system. Con-
Copyright ? 2005 Irum Godil. Permission to copy is
volution prevents modularity and prevents the
hereby granted provided the original copyright notice is
exclusion and inclusion of features as desired.
reproduced in copies made.
1

---

Figure 1: Prevayler System Architecture
Our primary objective in this paper is to
represent candidates independently developed in
evaluate the applicability of horizontal decompo-
related work.
sition in a domain other than middleware, where
The rest of this paper is structured as follows.
the principles originated. We perform this evalua-
Section 2, discusses the Prevayler architecture,
tion by applying the principles to the refactoring
introduces the horizontal decomposition princi-
of a non-trivial, open source software system, by
ples, and provides an overview of the aspect-
quantifying this refactoring effort through the use
oriented programming (AOP) paradigm. Section
of standard software engineering metrics, and by
3, presents a detailed study of the systematic ap-
reflecting on the refactoring process to gather
plication of the HD principles to the refactoring of
universally applicable patterns that could guide
the Prevayler system. To quantify the impact of
other refactoring efforts. We selected the Pre-
applying horizontal decomposition, Section 4
vayler database system for our purposes [4].
presents software engineering metrics applied to
This paper makes three main contributions.
the Prevayler sources before and after the refac-
First, we apply horizontal decomposition to the
toring. Section 5 reflects on the aspect-oriented
Prevayler database system validating the HD
refactoring process and extracts a list of refactor-
principles on a further case study. In the process
ing patterns that crystallized in refactoring of Pre-
we establish six features as crosscutting concerns
vayler. Section 6 presents related work to put our
and isolate them as configurable aspect compo-
efforts into perspective.
nents. The refactored aspect-oriented code for the
system can be found at [5]. We also suggest cer-
2 Background
tain modifications to make horizontal decomposi-
tion applicable to software systems exhibiting
2.1 Prevayler System Overview
mostly fine granular crosscutting. Second, we
quantify the results of performing aspect-oriented
Prevayler is a Java application that implements
refactoring and empirically evaluate the benefits
“Object Prevalence”; a concept developed by
of horizontal decomposition. Third, we reflect on
Klaus Wuestefeld and some colleagues at the Ob-
the refactoring process and generalize our efforts
jective Solutions. The idea of Object Prevalence is
by discovering 22 refactoring patterns, out of
to keep everything in RAM, as if “we were just
which 17 are unique to our efforts and 5 patterns
using a programming language” [6].
2

---

Functionality
Classes in Prevayler Code Base
Prevaylent Object
Prevayler, PrevaylerImpl, PrevaylerFactory
Transaction and
Transaction, TransactionWithQuery, Query, Prevayler, PrevaylerImpl, Trans-
Query
actionPublisher, CentralPublisher, AbstractPublisher, PrevaylerFactory,
TransactionSubscriber, TransactionTimeStamp, TransactionWithQueryExecuter
Transaction
TransactionLogger, PersistentLogger, DurableOutputStream, FileManager,
Logging
SimpleInputStream, Stopwatch, TransientLogger, CentralPublisher, Pre-
vaylerFactory
Snapshot
SnapshotManager, XMLSnapshotManager, NullSnapshotManager, PrevaylerFac-
Management
tory, PrevaylerImpl, Prevayler
Replication
ClientPublisher, TransactionPublisher, ServerConnection, TransactionSub-
scriber, POBOX, PrevaylerFactory, ServerListener
Multi-Threading
Turn, DurableOutputStream, PersistentLogger, TransientLogger, Transac-
tionLogger, CentralPublisher, ServerConnection, ClientPublisher, Pre-
vaylerImpl, BrokenClock, POBOX, AbstractPublisher,
StrictTransactionCensor, ServerListener
Censoring
TransactionCensor, LiberalTransactionCensor, StrictTransactionCensor, Pre-
vaylerFactory, CentralPublisher, SnapshotManager
Clock
Clock, PausableClock, MachineClock, BrokenClock, Prevayler, PrevaylerImpl,
TransactionPublisher, CentralPublisher, AbstractPublisher, ClientPub-
lisher, PrevaylerFactory, Transaction, TransactionWithQuery, Query, Trans-
actionTimeStamp, TransactionWithQueryExecuter, TransactionSubscriber,
POBOX, ServerConnection, TransactionCensor, LiberalTransactionCensor,
StrictTransactionCensor, TransactionLogger, PersistentLogger, Transient-
Logger

Table 1: Prevayler Functionality and Components Summary

Prevayler implements a fully-functional data-
of logging mechanisms: Persistent Logging, which
base in which a business object may be persisted.
logs all the transactions to the file system and
The business object must be serializable, i.e., im-
Transient Logging, which logs the transactions to an
plement the java.io.Serializable inter-
in-memory data structure. Additionally, in low-
face, and be deterministic, i.e., given an input the
use periods, an object graph of the entire system,
object’s methods must always return the same
known as the snapshot, is stored on the hard disk.
output [6]. An architecture diagram of the Pre-
Snapshot Management is supported by various seri-
vayler system is shown in Figure 1. A list of main
alization mechanisms including Java and XML
Prevayler functionalities together with supporting
serialization methods. Upon failure recovery, the
components in the code space is also listed in
snapshot of the system is recovered first. Transac-
Table 1.
tions in the log files that were applied after the
The Prevalent Business Object represents the
snapshot was taken are then applied to the busi-
object to be persisted. Changes to the business
ness object, resulting in a full system restore.
object are made by executing Transactions1 on it.
Execution of transactions to the prevalent ob-
A transaction maybe executed by itself, or may
ject, failure recovery and logging of transactions
return a result after execution. A transaction that
is achieved by the TransactionPublisher
returns a result is known as a Transaction-
and TransactionSubscriber components.
WithQuery. The business object maybe queried
Prevayler supports rolling back of transac-
independently using the Query component.
tions through the Censorship feature. Before a
Prevayler achieves transaction durability via
transaction is logged, it is applied to a copy of the
the Transaction Logging and the Snapshot Manage-
prevalent system. Only successful trials of trans-
ment features. Before a transaction is applied to
actions are eventually logged and executed on the
the business object, it is logged by the
business object [7]. Prevayler ensures that any
Trans-
transactions that are applied to the business object
actionLogger. Prevayler supports two kinds
are time-sensitive; i.e., any future execution of the
transaction will take the same time reference as it

was first executed. This feature is very important
1 In this paper, we use the Arial Narrow font to distin-
when the exact time of the transaction is neces-
guish Prevayler functionalities and Courier New
sary for the business logic [8]. This feature is im-
font to highlight Prevayler components (i.e. classes and
aspects).
plemented by the Clock component.
3

---

Prevayler also implements Multi-Threading and
cutting mechanisms: dynamic crosscutting and
Replication. With Replication, multiple clients can
static crosscutting. Dynamic crosscutting is de-
connect to a server, and the data on the server and
fined by means of join points that denote well-
all clients is always kept synchronized. Multi-
defined points in the execution of a (Java) pro-
Threading enables concurrent execution of the sys-
gram. A pointcut refers to a collection of join
tem.
points and to parameters associated with the join
Finally, the PrevaylerFactory config-
points. A method-like construct, referred to as an
ures the entire Prevayler system and all its com-
advice, is used to define aspect code executed
ponents. Applications built on top of Prevayler
before, after or in place of a join point. Inter-type
define the business object to be persisted, and
declarations are used to implement static cross-
implement commands that are to be applied on the
cutting, which allows the developer to introduce
business object as Transactions.
new fields and methods into classes or interfaces
to modify the existing type hierarchy. An aspect
2.2 Horizontal Decomposition
module includes pointcuts, the associated advices

and possible inter-type declarations.
Horizontal decomposition (HD) is a set of princi-
ples that have been proposed in [3] to guide the
aspect-oriented refactoring and implementation of
3 Horizontal Decomposition
complex software systems. We perceive that the
In this section, we explain the application of the
implementation of an aspect consists of both its
HD principles on the Prevayler system. Each sec-
functional implementation and its possible inter-
tion below is dedicated to one of the principles.
actions with every other aspect. HD promotes a
two dimensional architecture in which the vertical
architecture implements a minimum set of essen-
3.1 Relativity of Aspects
tial functionalities of the application as a core
According to the first principle of HD, the seman-
component, and the horizontal architecture cap-
tics of an aspect is determined by the primary
tures crosscutting concerns including both func-
functionality of the application. The definition of
tional and non-functional features [9], [10]. The
object prevalence found in [6] states: “In a preva-
horizontal features are decoupled from each other
lent system, everything is kept in RAM, as though
and each can be independently woven into the
you were just using a programming language.
vertical architecture. The core, also referred to as
Serializable command objects manage all the
primary functionality is determined by primary
necessary changes required for persistence. Que-
requirements and the horizontal architecture is
ries are run against pure Java language objects.”
determined by aspect requirements. We defer a
Thus, inspired from this definition, we define the
detailed presentation of each principle to Section
primary functionality of Prevayler to be an in-

3, where we successively apply them to the Pre-
memory database for business objects. Prevayler
vayler system.
aspects are then all the features that crosscut this
functionality in the code space.
2.3 Aspect Orientation
Aspects constitute crosscutting concerns [1]. As-
3.2 Defining the Prevayler Core
pect-oriented programming allows the developer
The second principle of HD states that, the basis
to cleanly encapsulate aspects in separate modules
of aspect-oriented decomposition is the estab-

[1]. Examples of common aspects include security,
lishment of a functionally coherent and vertically
access control, and error handling. Aspects are
decomposed core. Hence, based on the primary
modularized by aspect language, such as AspectJ
functionality defined above, the Prevayler core

[11], Hyper/J [12], AspectC++ [13], and CME
must support an in-memory database application

[14]. The primary decomposition of a system is
for business objects. The Prevayler business ob-
implemented with a component language, such as
ject is central to the entire system, and thus all
Java or C++. AspectJ, an aspect-oriented exten-
components that define and configure it must
sion to Java, is one of the most mature aspect lan-
form part of the core. Additionally, in Prevayler,
guages today. AspectJ defines a set of new
transactions are essential for making any updates
language constructs to support two kinds of cross-
to the business object. Since updating the business
4

---

Figure 2: Execution of a Transaction in Prevayler
object is central to the proper working of the in-
crosscutting features in Prevayler, we propose the
memory database, all components representing
following modifications to the HD principles:
transaction and query objects are included in the
1. Since Prevayler is a rather small application,
core. To realize transactions, the core only sup-
(i.e., 2418 lines of code and 60 classes), a
ports transient logging; i.e., maintains the sequence
feature is an aspect if it crosscuts through
of transaction logs in an in-memory data structure
more than one class. Additionally, we con-
only, without persisting them to disk.
sider a feature to be an aspect if its code is

A sequence diagram representing the execu-
scattered through more than one method of
tion of a transaction is shown in Figure 2. Prior to
the PrevaylerFactory class. This is
logging transactions, the system censors transac-
mainly due to the small size of Prevayler and
tions. As discussed in Section 2.1, Censorship en-
also because there is only one factory class
sures that a transaction execution works on a copy
which configures everything. For a larger
of the business object, before applying it to the
system, there would be more than one factory
original system. We consider this to be an op-
class to configure different features of the
tional feature and exclude it from the core. How-
system, which would cause more scattering.
ever, we include in the core, parts of
2. The HD principles, only consider crosscut-
TransactionPublisher and Transac-
ting in one system, and do not observe as-
tionSubscriber components that support
pects that transcendent system boundaries.
publishing, logging and receiving of transactions.
However, to also capture crosscutting for an

Other features supported by Prevayler include
end-to-end scenario involving the system,
replication between a server and multiple clients,
applications that are built on top of it, and the
support for time-sensitive business logic and execu-
underlying operating system, we capture
tion of multi-threaded applications. None of these
crosscutting in a system built on top of the
functionalities are essential for an in-memory
Prevayler application. For this purpose, we
database, and hence are excluded from the core.
consider the demo bank application, shipped
with the Prevayler code. It uses Prevayler to
persist bank transactions.
3.3 Defining Prevayler Aspects
3. We have defined various levels at which a
According to the third principle of HD, using the
concern crosscuts through the system func-
core as a reference, a functionality is considered
tionality. These levels are defined in Table 2.
orthogonal if both its semantics and its implemen-
The purpose of such a classification is to
tations are not local to a single component of the
know how scattered the concerns are across
core. Only the orthogonal functionality is treated
the code base. Note, from the crosscutting
in the aspect-oriented way. In order to define
definitions, one concern can exhibit more
than one crosscutting level.
5

---

Figure 3: Aspect Crosscutting in Prevayler

Crosscutting
Concern Code Scattering
Logical Independence: The core only supports
Intra-Method
>1 method of same class
in-memory storage of the business object.
Intra-Class
>1 class of same package
Crosscutting: Crosscuts through the Pre-
vaylerFactory class which configures the
Intra-Package
>1 package of same system
type of Snapshot Management. Support is also pro-
Intra-System
Main code base and in applica-
vided in the Prevayler and PrevaylerImpl
tion(s) built on top of code base
class for taking snapshots of the business object.
Table 2: Crosscutting Levels
In the bank application, the code crosscuts
We summarize below the Prevayler aspects with
through
the
Main,
MainReplica
and
their functionality, logical independence from the
MainXML classes for taking snapshots.
core and crosscutting natures. Figure 3 shows the

crosscutting of the Prevayler aspects. The various
Censoring (C): Supports approving of transac-
crosscutting levels inside Prevayler are summa-
tions before being applied to the system, so that
rized in Table 3.
transactions that cause failures are not applied to

the business object.
Snapshot Management (S): Supports storing the
Logical Independence: The core supports simple
entire object graph of the business object.
transactions with no prior checking.
6

---

Crosscutting: The PrevaylerFactory class
transactions. Local and remote publishing and
supports initialization and configuration of liberal
subscribing, and logger and censor classes support
or strict censoring. CentralPublisher has
time-sensitive transactions. It also crosscuts
functionality to censor a transaction before it is
through all classes of the bank application that
published.
support transactions on bank objects. Additionally,

the AccountEntry and BankFrame class also
Replication Support (R): Supports duplicating
support clock features.
contents between a server and multiple clients.

Logical Independence: The core supports only
Multi-Threading (M): Supports application of
local publishing and receiving of transactions.
transactions from multiple threads.
Crosscutting: In the Prevayler system, the repli-
Logical Independence: The core supports single-
cation concern is scattered through several meth-
threaded applications only.
ods in PrevaylerFactory only. In the bank
Crosscutting: Multi-threading is scattered in
application there is code to configure the replica-
form of synchronized methods, classes extending
tion client and server in MainReplica and
java.lang.Thread class, support for wait
MainReplicaServer.
and notification, and sequencing operations to be

performed in order by several threads in the log-
Persistent Logging (P): Supports logging of
ging and publishing layer, all the client/server
transactions to the file system. Logging in Pre-
classes that support replication, and the Pre-
vayler is different from the conventional logging
vaylerImpl,
StrictTransactionCen-
feature used for debugging and other purposes;
sor, BrokenClock, and DurableOutput-
instead logging is an important functionality of
Stream classes.
Prevayler to support transaction durability.

Logical Independence: The core supports tran-
Aspect
Intra-
Intra-
Intra-
Intra-
sient logging only.
Method
Class
Package
System
Crosscutting: The classes Durableoutput-
S
X
X
X
X
Stream, SimpleInputStream are used
C
X
-
X
-
solely for persistent logging purposes. The Pre-
R
X
-
-
X
vaylerFactory has variables to keep track of
P
X
-
X
X
a transaction log file’s age and size. It provides
Cl
X
X
X
X
APIs to configure Persistent Logging in the system.
M
X
X
X
-
By default the Prevayler system uses Persistent
Table 3: Aspect Crosscutting Levels in Prevayler
Logging. All sub-programs of the bank application
also use Persistent Logging by default, except for
3.4 Resolving Convolution
the MainTransient class, which demonstrates
Transient Logging.
According to the fourth principle of HD, crosscut-


ting concerns should be implemented class-
Clock Support (Cl): Supports time-sensitive
directional towards the core. The goal of aspect-
business logic, so that future executions of a
oriented treatment is to eliminate the convoluted
transaction will take the same time reference as
implementation in the original Prevayler code
the first execution2.
base. This is accomplished through the implemen-
Logical Independence: The core does not sup-
tation of orthogonal functionality as a set of core
port time-sensitive business logic.
aspects of Prevayler and the untangling of the
Crosscutting: Crosscuts through Prevayler-
code convolution among aspects themselves. We
Factory for clock configuration. Prevayler
present the details in the sections below.
and PrevaylerImpl support determining of
execution time of transactions and queries. Trans-
3.4.1 Implementing Prevayler Aspects
action and query classes support time-sensitive
The implementation of aspects generally consists
of two distinct parts: the implementation of aspect

2 Future executions of a transaction are necessary when
restoring a system, mainly after a failure.
7

---

Figure 4: Aspect Implementation of Snapshot Management Concern
functionality and the implementation of the inter-
and aspects, i.e., ReplicationAspect which
action between the aspect and the core. The
crosscuts through the refactored Prevayler-
classes which solely support the main functional-
Factory code and the ReplicationSnap-
ity of a crosscutting concern are moved into a new
shot aspect which crosscuts through the advices
aspects package. The crosscutting code is
inside SnapshotFactoryAspect. This is
then implemented as aspects inside a weave
shown in Figure 5.
package. Furthermore, the crosscutting code in the
Clock and Multi-Threading (Cl&M): We see
bank
applications
is
refactored
into
a
convolution between the clock and multi-
demo.weave package.
threading support in Prevayler. There are a lot of
Figure 4 shows the refactoring of the Snap-
APIs in Prevayler where both Cl&M parameters
shot concern. We have moved the core classes:
are present; as a result we need to define APIs for
SnapshotManager,
NullSnapshotMan-
4 possible configurations. An example is shown
ager and XmlSnapshotManager into the
for TransactionLogger’s log function in
aspects.snapshot package. We have intro-
Figure 6. This kind of convolution is also found in
duced a weave package to implement the cross-
Persistent Logger and Censorship aspects. Further-
cutting functionality in aspects. The bank
more, we see independent convolution with repli-
application’s crosscutting code is placed inside
cation and of just multithreading convoluted with
the demo.weave package.
Snapshot Manager.
Table 4 summarizes the aspect convolution.
3.4.2 Untangling Convoluted Aspects
The last row for Cl&M shows that we had to in-
troduce an additional weave package for support-
We observe the following two areas of convolu-
ing both clock and multi-threading together in the
tion among aspects:
core, which takes precedence over regular Cl&M
Replication with Snapshot Manager: We ob-
advices over the same join points. In this row,
serve that the same code for replication support in
where check marked, we had to add a clock-
the PrevaylerFactory will occur at different
multithreading package for the aspects as
join points in the case of just the core code vs. the
well. For instance from column 1, we have as-
case when the Snapshot aspect is introduced. As a
pects and weave packages to support censorship
result, we introduce two different weave packages
8

---

privileged aspect SnapshotFactoryAspect {
privileged aspect ReplicationSnapshot {
private TransactionPublisher
TransactionPublisher around (PrevaylerFactory f,

SnapshotManager sm) : publisherexec (f, sm) {
PrevaylerFactory.publisher( Snapshot
Intercepts
…
Manager snapshotManager) {
around
}
return new CentralPublisher(clock(), logger());
after() returning( TransactionPublisher publisher ):
}
cal (TransactionPublisher publisher(SnapshotManager))

{
Prevayler around(PrevaylerFactory f): createFactory(f)
Intercepts
…
{
after
}
SnapshotManager s = f.snapshotManager();
…
TransactionPublisher publisher = f.publisher(s);
return new PrevaylerImpl(s, publisher);
}
}
privileged aspect ReplicationAspect {
public class PrevaylerFactory {
after(PrevaylerFactory p) returning(TransactionPublisher publisher):
public Prevayler create() {
Intercepts target(p) && cal (TransactionPublisher publisher()) && withincode
TransactionPublisher p = publisher();
after
(Prevayler PrevaylerFactory.create( ))
return new PrevaylerImpl(p, prevalentSystem());
{
}
…

}
private TransactionPublisher publisher() {
TransactionPublisher around(PrevaylerFactory p) : target(p) &&
return new CentralPublisher (clock(), logger());
Intercepts
execution(TransactionPublisher publisher())
}
around
{

}
…
}
}


Figure 5: Replication Aspect Convolution

Figure 6: Cl&M Aspect Convolution


C
P
R
S
R
-
-
-
X
3.4.3 Aspect Dependencies
M
X
X
X
X
Cl
X
X
X
-
We discovered that not all our aspects are inde-
Cl&M
X
X
-
-
pendent, i.e., we cannot configure a version of
Table 4: Aspect Convolution in Prevayler
Prevayler with any one of them without support
from another aspect. More precisely, we made the
and
additionally
3
packages:
censor-
following observations:
clock.weave, censorthread.weave and
Transaction Censoring: is not fully independent
censorclockthread.weave.
as Censoring uses Snapshot Manager to get a copy
9

---

of the stored business object, and executes trans-
4 Evaluation and Metrics
action on it first to test if it actually works.
Prevalence Base: PrevaylerFactory de-
We perform an empirical evaluation of the Pre-
fines APIs and fields to configure the directory
vayler code before and after the refactoring, as
where snapshots and persistent logs are stored. We
this is important to draw quantitative conclusions
put
this
code
into
the
Prevalence-
about usefulness of the procedures applied. In the
Base.weave package. Snapshot Management
sections to follow we present a brief explanation
and Persistent Logging aspects both depend on it.
of these metrics, followed by the results and
Replication: Replication is difficult to support
analysis on Prevayler. We conclude this section
without multi-threading. There's one server and
by evaluating usefulness of AOP and HD princi-
many clients and any of those can publish a trans-
ples in the light of these metrics. A detailed defi-
action at any time. The server has one thread wait-
nition of the metrics can be found in [15].
ing for connections from the clients and upon
each connection it makes a new thread to handle
4.1 Metrics Suite
that connection. Thus, without threads it is diffi-
cult to handle the client connections.
We have categorized our analysis into the follow-

We also observe that the core can be com-
ing two metric suites:
piled independently without having any knowl-

edge of the aspects.
Separation of Concerns (SoC): We measure
SoC using Concern Diffusion over Components
3.5 Incremental Decomposition
(CDC) and Concern Diffusion over Operations
(CDO) [15], [16]. CDC counts the number of
The fifth principle of HD states that, decomposi-
classes and aspects whose main purpose is to con-
tion in the aspect dimension is assisted by incre-
tribute to the implementation of a concern and the
mental refactoring. Our experience shows that the
number of other classes and aspects that access
definition of the minimal core is adjusted and
them. CDO counts the number of methods and
refined gradually over time. Consequently, we
advices whose main purpose is to contribute to the
discover new aspects as the definition of our core
implementation of a concern and the number of
refines. We did three stages of incremental refac-
other methods and advices that access them.
toring to arrive at the six aspects mentioned. We

list the summary of the process in Table 5. For
Coupling, Cohesion and Size: Coupling counts
instance, our initial refactoring (Stage 1) starts
the number of other classes and aspects to which a
with aspects Snapshot Management(S), Censoring(C)
class or an aspect is coupled. This metric is useful
and Replication(R), listed under column A, with the
in evaluating the correlation between various
aspects in column B yet to be identified. In stage
components of the system and to measure de-
1 we found one convolution of R on S, shown in
pendencies between classes [15]. Cohesion meas-
column C. In Stage 2 discovery of the Persistent
ures the lack of cohesion of a class or an aspect. It
Logger(P) aspect, leads to removal of Preva-
measures the dissimilarity of methods in a class
lenceBase code from the core and as a result
by its attributes [17].
the Snapshot aspect needs modification. Finally, in
Stage 3, the Clock(Cl) and Multi-Threading(M) as-
We used various metrics mentioned in [15]
pects require modification of all other aspects
for calculating size. These include: Vocabulary
together with the core.
Size (VS), which counts the total number of com-

ponents, i.e., classes and aspects in a system;
Stage
A
B
C
Lines of Code (LOC) of the system; the Number
1
S,C,R
P,Cl,M
R
S
of Attributes (NOA) relating to a specific concern
2
P
Cl, M
P,S
PrevalenceBase
and Weighted Operations per Component (WOC),
3
Cl, M
-
C, P, R, S
which measures the complexity of a component in
terms of its operations.
Table 5: Incremental Decomposition Summary
10

---