Journal of Software Engineering and Applications, 2012, 5, 722-736
http://dx.doi.org/10.4236/jsea.2012.59085 Published Online September 2012 (http://www.SciRP.org/journal/jsea)
A Game Comparative Study: Object-Oriented Paradigm
and Notification-Oriented Paradigm
Jean M. Simão1,2, Danillo L. Belmonte1, Glauber Z. Valença2, Márcio V. Batista1,
Robson R. Linhares1,2, Roni F. Banaszewski1, João A. Fabro2, Cesar A. Tacla1,2,
Paulo C. Stadzisz1,2, Adriano F. Ronszcka1
1Graduate School in Electrical Engineering & Industrial Computer Science (CPGE I), Federal University of Technol ogy-Paraná, Cu-
ritiba, Brazil; 2Graduate School of Applied Computing (PPGCA), Federal University of Technology-Paraná, Curitiba, Brazil.
Email: jeansimao@utfpr.edu.br, linhares@utfpr.edu.br, fabro@utfpr.edu.br, tacla@utfpr.edu.br, stadzisz@utfpr.edu.br
Received July 13th, 2012; revised August 25th, 2012; accepted September 8th, 2012
ABSTRACT
This paper presents a new programming paradigm named Notification-Oriented Paradigm (NOP) and analyses the per-
formance aspects of NOP programs by means of an experiment. NOP provides a new manner to conceive, structure, and
execute software, which would allow better performance, causal-knowledge organization, and decoupling than standard
solutions based upon usual paradigms. These paradigms are essentially Imperative Paradigm (IP) and Declarative Para-
digm (DP). In short, DP solutions are considered easier to use than IP solutions due to the concept of high-level pro-
gramming. However, they are considered slower in execution and less flexible in development. Anyway, both para-
digms present similar drawbacks su ch as redundant causal-evaluation an d strongly coupled entities, which decrease the
software performance and the processing distribution feasibility. These problems exist due to an orientation to a mono-
lithic inference mechanism based upon sequential ev aluation by searching on passive computational entities. NOP pro-
poses another way to structure software and make its inferences, which is based upon small, collab orative, and decoup-
led computational entities who se interaction happens through precise notifications . In this context, this pap er presents a
quantitative comparison between two equivalent implementations of a computer game simulator (Pacman simulator),
one developed according to the principles of Object-Oriented Paradigm (OOP/IP) in C++ and other developed accord-
ing to the principles of NOP. The results obtained from the experiments demonstrate, however, a quite lower perform-
ance of NOP implementation. This happened because NOP applications are still developed using a framework based on
C++. Besides, the paper shows that optimizations in the NOP framework improve NOP program performance, thereby
evidencing the necessity of developing a NOP language/compiler.
Keywords: Notification Oriented Paradigm; Notification Oriented Inference; NOP and OOP Comparison
1. Introduction
This section mentions the drawbacks of the main usual
programming paradigms, introduces a new paradigm,
and presents the paper objectives.
1.1. Review Stage
The computational processing power has grown each
year and the tendency is that technology evolution con-
tributes to the creation of still faster processing techno lo-
gies [1,2]. Even if this scenario is positive in terms of
pure technology evolution, in general it does not moti-
vate information-technology professionals to optimize
the processing resource use when they develop software
[1,3].
This behavior has been tolerated in standard software
development where generally there is no need of inten-
sive processing or processing constraints. However, it is
not acceptable to certain software classes, such as soft-
ware for embedded systems [1,4]. Such systems normally
employ less-powerful processors due to factors such as
constraints on power use and system price to a given
market [1,5].
Besides, misuse of computational power in software
can also cause overuse of a given standard processor,
implying in execution delays [1,4,6]. Still, in complex
software, this can even exhaust a processor capacity,
demanding faster processor or even some sort of distri-
butions (e.g. dual-core) [1,4,7]. Indeed, an optimization-
oriented programming could avoid such drawbacks and
related costs [1,4,8].
Thus, suitable engineering tools for software devel-
Copyright © 2012 SciRes. JSEA
A Game Comparative Study: Object-Oriented Paradigm and Notification-Oriented Paradigm 723
opment, namely programming languages and environ-
ments, should facilitate development of optimized and
correct code [1,9-12]. Otherwise, the engineering costs to
produce optimized-code could exceed those of upgrading
the processing capacity [1,4,9-11].
Still, suitable tools should also make the development
of distributable code easy, once even with optimized
code, distribution may be actually demanded in some
cases [1,4,13-16]. However, distribution is itself a prob-
lem once, under different conditions, it could entail a set
of (related) problems, such as complex load balancing,
communication excess, and hard fine-grained distribution
[1,4,13,14,17].
In this context, a problem arises from the fact that
usual programming languages (e.g. Pascal, C/C++, and
Java) present no real easiness to develop optimized and
really distributable code, particularly in terms of fine-
grained decoupling of code [1,3,4,17,18]. This happens
due to the structure and execution nature imposed by
their para d i g m [1,7,9,10].
1.2. Imperative and Declarative Programming
Usual programming languages are based on the Impera-
tive Paradigm, which cover sub-paradigms such as Pro-
cedural and Object Oriented ones [1,10,19,20]. Besides,
the latter is normally considered better than the former
due to its richer abstraction means. Anyway, both pre-
sent drawbacks due to their imperative nature [1,10,
19,21].
Essentially, Imperative Paradigm imposes loop-ori-
ented searches over passive elements related to data (e.g.
variables, vectors, and trees) and causal expressions (i.e.
if-then statements or similar ones) that cause execution
redundancies. This leads to the creation of programs as
monolithic entities comprising prolix and coupled code,
thereby generating non-optimized and interdependent
code execution [1 ,8,9,21,22].
The Declarative Paradigm is the alternative to the Im-
perative Paradigm. It enables a higher level of abstraction
and easier programming [1,20,21]. Also, some declara-
tive solutions avoid many execution redundancies in or-
der to optimize execution, such as Rule Based System
(RBS) based on Rete or Hal algorithms [1,23-26]. How-
ever, programs constructed using usual languages from
Declarative Paradigm (e.g. LISP, PROLOG, and RBS in
general) or even using optimized solution (e.g. Rete-
driven RBS) also present drawbacks [1, 8, 9] .
Declarative Paradigm solutions use computationally
expensive high-level data structures causing considerable
processing overheads. Thus, even with redundant code,
Imperative Paradigm solutions are normally better in
performance than Declarative Paradigm solutions [1,10,
27]. Furthermore, similarly to the Imperative Paradigm
programming, the Declarative one also generates code
coupling due to the similar search-based inference proc-
ess [1,4,8,21]. Still, other approaches such as event-
driven and functional programming do not solve these
problems even if they may reduce some problems, like
redundancies [1,22,27] .
1.3. Development Issues & Solution Perspective
As a matter of fact, there are software development is-
sues in terms of ease composition of optimized and dis-
tributable code. Thus, this prompts for new solutions to
make simpler the task of build ing better software. In this
context, a new programming paradigm, called Notifica-
tion Oriented Paradigm (NOP), was proposed regarding
some of the highlighted problems [1,4,8,9].
The NOP basis was initially proposed by J. M. Simão
as a manufacturing discrete-control solution [28,29]. This
solution was evolved as general discrete-control solution
and then as a new inference-engine so lution [4], attaining
finally the form of a new programming paradigm [1,
8-10]. Since then, efforts have been produced to the es-
tablishment of this paradigm [1,30-36].
The essence of NOP is its inference process based on
small, smart, and decoupled collaborative entities that
interact by means of precise notifications [1,4]. This
solves redundancies and centralization problems of the
current causal-logical processing, thereby solving proc-
essing misuse and coupling issues of usual paradigms
[1,4,8,10].
1.4. Paper Context and Objective
This paper discusses NOP as a solution to certain defi-
ciencies present in usual paradigms. Particularly, the pa-
per presents a performance study, using a single-proces-
sor architecture computer.
The study is related to a game simulator implementa-
tion based on principles of NOP compared against an
equivalent one based on principles of Imperative/Object-
Oriented Pa radigm.
The NOP program is elaborated in the current NOP
Framework over C++, whereas the OOP program is
elaborated in C++. Thus, an objective of this paper is to
evaluate the current NOP materialization in terms of
performance.
Furthermore, this paper presents the results from two
implementations of the NOP Framework. The first is the
original one, designed and presented in [10]. The second
is an optimized version considered in [34].
Thus, another objective is to demonstrate how relevant
and appropriated are some refactoring and optimizations
in the NOP Framework, thereby realizing whether it is or
not necessary to build a NOP compiler.
Copyright © 2012 SciRes. JSEA
A Game Comparative Study: Object-Oriented Paradigm and Notification-Oriented Paradigm
724
2. Background
This section explores programming paradigm drawbacks.
2.1. Imperative Programming (IP) Issues
The main drawbacks of Imperative Programming are
concerned to the related code redundancy and coupling.
The first mainly affects processing time and the second
processing distribution, as detailed in the next subsec-
tions [1,4].
2.1.1. Imperative Programming (IP) Redundancy
In Imperative Programming, like procedural or object
oriented programming, a number of code redundancies
and interdependences comes from the manner the causal
expressions are evaluated. This is exemplified in the
pseudo-code in Figure 1 that represents a usual code
elaborated without strong technical and intellectual ef-
forts. This means that the pseudo-code was elaborated in
a non-complicated manner, as software elaboration shou ld
ideally be [1,8,1 0].
In the example, each causal expression has three logi-
cal premises and a loop that forces the sequential evalua-
tion of all causal expressions. However, most evaluations
are unnecessary because usually just few attributes of
objects (variables) have their values changed at each it-
eration. This type of code causes a problem called, in the
computer science, temporal and structural redundancy
[1,4,25].
The temporal redundancy is the repetitive, unnecessary
evaluation of causal expressions in the presence of ele-
ment states (e.g. attribute or variable states) already
evaluated and unchanged. For instance, this occurs in the
considered loop-oriented code example. The structural
redundancy, in turn, is the recurrence of a given logical
expression evaluation in two or more causal expressions
[1,4]. For instance, the logical expression (object_1.at-
tribute_1 = 1) is replicated in several causal expressions
(i.e. if-then statements) [1,4,8].
Figure 1. Example of imperative code [1].
These redundancies can be seen unimportant in this
didactic code example, mainly if the number (n) of
causal expressions is small. However, even with better
code, if more complex examples were considered inte-
grating many (remaining) redundancies, there would be a
tendency to performance degradation and consecutively
an increasing of development complexity in order to im-
prove the performance [1,8,10].
The code redundancies may result, for example, in the
need of a more powerful processor than it is really re-
quired [1,4,7]. Also, they may result in the need for code
distribution to processors, thereby implying in other
problems such as module splitting and synchronization.
These problems, ev en if solvable, are additional issues in
the software development whose complexity increases as
much as the fine-grained code distribution is demanded,
particularly in terms of logical-causal (i.e.if-th en”) cal-
culation [1,4,7].
2.1.2. Imperative Programming (IP) Coupling
Besides the usual repetitive and unnecessary evaluations
in the imperative code, the evaluated elements and causal
expressions are passive in the program decisional execu-
tion, although they are essential in this process. For in-
stance, a given if-then statement (i.e. a causal expression)
and concerned variables (i.e. evaluated elements) do not
take part in the decision with respect to the moment in
time they must be evaluated [1,4].
The passivity of causal expressions and concerned
elements is due to the way they are evaluated in the time.
An execution line in each program (or at least in each
program thread) carries out this evaluation, usually
guided by means of a set of loops. As these causal ex-
pressions and concerned elements do not actively con-
duct their own execution (i.e. they are passive), their in-
terdependency is not explicit in each program execution
[1,4].
Thus, at first, causal expressions or evaluated elements
depend on results or states of others. This means they are
somehow coupled and should be placed together, at least
in the context of each module. This coupling increases
code complexity, which complicates, for instance, an
eventual distribution of each single code part in fine-
grained way. This makes each program module, or even
the whole program, a monolithic computational unit [1,
4].
2.1.3. IP Distribution Hardness
When distribution is intended (e.g. process, processor,
and cluster distribution), code analysis cou ld identify less
dependent code arrangements to facilitate their splitting.
However, this is normally a complex activity due to the
code coupling and complexity caused by the imperative
programming [1,18,35].
Copyright © 2012 SciRes. JSEA
A Game Comparative Study: Object-Oriented Paradigm and Notification-Oriented Paradigm 725
In this sense, well-designed software composed of
modules as decoupled as possible, using advanced and
quite complicated software engineering concepts such as
aspects [13] and axiomatic design [37], can help distri-
bution. Still, middleware such as CORBA and RMI
would be helpful in terms of infrastructure to so me types
of module distribution, if there is enough module de-
coupling [1,13,38 ,3 9 ] .
In spite of those advances, distribution of single code
elements or even code modules is still a complex activity
demanding research efforts [13,14,17,35,40]. It would be
necessary additional efforts to achieve easiness in distri-
bution (e.g. automatic, fast, and real-time distribution), as
well as correctness in distribution (e.g. fine-grained, bal-
anced, and minimal inter-dependent distribution) [1,4].
Indeed, distribution hardness is an issue because there
are contexts where distribution is actually necessary [1,7,
15,16]. For example, a given optimized program exceed-
ing the capacity of an available processor would demand
processing splitting [6]. Other examples are programs
that must guarantee error isolation or even robustness by
distributed module redundancy [28]. These features can
be found in application of nuclear-plant control [41],
intelligent manufacturing [28,29,42,43], and cooperative
controls [ 4 4] .
Besides, there are other applications that are inherently
distributed and need flexible distribution, such as those
of ubiquitous computing. More precise examples are
sensor networks and some intellig ent manufacturing co n-
trol [1,43,45]. Also, the easy and correct distribution is
an expectation due to the reduction of processor prices
and advances in network communication as well [1,10,
46].
2.1.4. IP Devel opmen t Hardness
In addition to optimization and distribution issues, the
program development with Imperative Programming can
be seen as hard due to complicated syntax and a diversity
of concepts to be learned, such as pointers, control vari-
ables, and nested loops [1,47]. The development process
would be error-prone once a lot of code still comes from
a manual elaboration using those concepts. In this con-
text, the exemplified imperative algorithm (Figure 1)
could be certainly optimized, however without signify-
cant easiness in this activity and true fine-grained code
decoupling [1].
It would be necessary to investigate better solutions
than those provided by Imperative Paradigm. A solution
to solve some of its problems may be the use of pro-
gramming languages from another paradigm, such as
Declarative Programming that automates the evaluation
process of causal expressions and concerned elements
[1,19,48].
2.2. Declarative Programming Issues
A well-known instance of Declarative Programming and
its nature is Rule Based System (RBS) [1,4,47]. A RBS
provides a high-level language in the form of causal-
rules, that prevents developers from algorithm particu-
larities [1,47]. RBS is composed of three general modu-
lar entities (Fact Base, Rule Base, and Inference Engine)
with distinguished responsib ilities, as usual in declarative
language (e.g. LISP, PROLOG, and CLIPS) [1,48].
In Declarative Programming, the variable states are
dealt in a Fact Base and the causal knowledge in a Causal
Base (Rule Base in RBS), which are automatically
matched by means of an Inference Engine (IE) [1,24,47].
Moreover, some IE algorithms (e.g. RETE [23-25],
TREAT [49,50], LEAPS [51], and HAL [26] algorithms)
avoid most of temporal and structural redundancies
[1,10]. However, the data structures us ed to solve redun-
dancies in those IEs implies in too much consuming of
processing capacity [1,25].
Actually, the use of Declarative Programming only
compensates when the software under development pre-
sents many redundancies and few data variation. Also, in
general, an IE related to a given declarative language
limits the inventiveness, makes difficult some algorithm
optimizations, and obscures hardware access, which can
be inappropr iate in certain contexts [1,10,22,27,52].
A solution to these problems can be the symbiotic use
of Declarative and Imperative Programming [19,52].
Indeed, such approach has been presented, like CLIPS++,
ILOG Rules, and R++. However, they would not be
popular due to factors like syntax and paradigms mixing
or technical cultural reasons [10]. Anyway, even De-
clarative Programming being relevant, it does not solve
some issues [1].
Indeed, beyond processing-overhead, Declarative Pro-
gramming also presents code coupling. Each declarative
program has also an execution or inference policy whose
essence is a monolithic entity (e.g. Inference Engine)
responsible for analyzing ev ery passive data-entity (Fact-
Base) and causal expression (Causal-Base). Thus, the
inference based on a search technique (i.e. matching)
implies a strong dependency between facts and causal
rules once they together constitute the search space [1].
2.3. Other Approach Drawbacks
Enhancements in the context of Imperative and Declara-
tive Paradigm have been provided to reduce effects of
recurrent loops or searches, such as event-driven pro-
gramming and functional programming [10,48,53]. Event
programming and functional programming have been
used to different software like discrete control, graphical
Copyright © 2012 SciRes. JSEA
A Game Comparative Study: Object-Oriented Paradigm and Notification-Oriented Paradigm
726
interfaces, and multi-agent systems [1,10,48,53].
Essentially, each event (button pressing, hardware in-
terruption or received message) triggers a given execu-
tion (process, procedure or method execution), usually in
a given sort of module (block, object or even agent), in-
stead of repeated analysis of th e conditions for its execu-
tion. The same principle applies to the called functional
programming whos e difference would be function callin g
via other function in place of events. Still, function
would mean procedure, method or similar unity. Besid es,
functional and event programming used together would
be usual [1].
However, algorithms in each module process or pro-
cedure are built using Declarative or Imperative pro-
gramming. This implies in the highlighted deficiencies,
namely code redundancy and coupling, even if they are
diminished by events or function calls. Indeed, if each
module has extensible or even considerable causal-logi-
cal calculation, they can be a problem together in terms
of processing misuse and distribution. This may demand
special design effort to achieve optimization and module
decoupling [1].
An alternative programming approach is the Data
Flow Programming [14] that supposedly should allow
program execution oriented by data instead of an execu-
tion line based on search over data. Thus, this would al-
low decoupling and distribution [14]. The distribution in
Data Flow Programming is achieved in arithmetical
processing, however it is not really achieved in logical-
causal calculation [14,17]. This calculation is carried out
by means of current advanced inference engines, namely
Rete [1,17,54].
The fact is usual inference engines attempt to achieve
a data-driven approach. However, the inference process
is still based on searches even if they use data from
(some sort of) object-oriented tree to speed up the infer-
ence cycle or searches. Thus, the highlighted problems
remain [1].
2.4. Enhancement in Programming
In short, as explained in terms of Imperative and De-
clarative Paradigms, usual paradigms do not make easy
to achieve the following qu alities together [1]:
Effective (causal) code optimization to be sure about
the eventual need of a faster processor and/or multi-
processing.
Easy way to compose correct code (i.e. without er-
rors).
Easy code splitting and distribution to processing
nodes.
This is a problem mainly when the increasing market
demand by software is considered, where development
easiness, code optimization, and processing distribution
are current requirements [1,55-57]. This software devel-
opment “crisis” impels new researches and solutions to
make simpler the task of building better software [1].
In this context, a new programming paradigm called
Notification Oriented Paradigm (NOP) was proposed to
solve some of the highlighted problems. NOP keeps the
main advantages of Declarative Programming/Rule Ba sed
Systems (e.g. higher causal abstraction and organization
by means of fact base and causal base) and Impera-
tive/Object Oriented Programming (e.g. reusability, fle-
xibility, and suitable structural abstraction via classes and
objects). Moreover, NOP would evolve some of their
concepts and solve some of their deficiencies [1,4,8].
3. Comparative Study
NOP concepts were firstly used to discrete control appli-
cations for quite diversified and complex simulated
manufacturing systems. The simulator used was ANA-
LYTICE II, developed at CPGEI/UTFPR. Specifically,
concepts of the nowadays called NOP were used to build
a control meta-model, which allows instantiating control
applications, particularly to ANALYTICE II [28]. Those
concepts revealed to be suitable to control applications
[28,29].
In a given period of time, the solution was called
Holonic Control Meta-Model due to its holistic features
and its applicability to the so called Holonic Manufac-
turing Systems [29]. Nowadays, this Holonic Control
Meta-model is also called Notification Oriented Control
(NOC). Besides, NOC is considered the genesis of the
now called Notification Oriented Inference (NOI). In
turn, NOI is considered the genesis of NOP. Thus, dis-
crete control applications of NOC could be interpreted as
a NOP application [1,4,8].
Anyway, each control application over ANALYTICE
II is actually complex to be used in a comparison study
between NOP and Object-Oriented Paradigm (OOP).
Indeed, the understanding of this complex application
could undermine NOP and experiment understanding as
well.
In this context, a simpler application called Marks-
manship Game was proposed in a previous work in order
to evaluate the paradigm. This toy application has al-
lowed implementation exp eriments showing good results
in favor of NOP [10].
However, other tests on more realistic applications are
needed to effectively demonstrate the efficiency and ef-
fectiveness of NOP in relation to usual programming
paradigms. Thus, another application is here proposed,
being called Pacman Game Simulator. This application
was firstly described (in Portuguese) in [33] and was
there first used to some previous experiments.
Copyright © 2012 SciRes. JSEA
A Game Comparative Study: Object-Oriented Paradigm and Notification-Oriented Paradigm 727
3.1. Pacman Game Simulator
Concisely, this new application refers to an implementa-
tion of a simulator with features of the classic game
knows as Pacman1. Resembling the game of its inspira-
tion [58], the environment has corridors that form a maze
and limit the movement actions of the characters in the
scenario, namely the Pacman and his enemies, the ghosts.
Moreover, all the characters present autonomous behav-
ior (i.e. they are not controlled by a user). Figure 2 illus-
trates the environment produced by the simulator [33].
At the beginning of the simulation, the Pacman is
placed at (9, 15) position in the grid, whose origin is lo-
cated at the upper-left corner at (0, 0) position. In turn,
the four ghosts are placed in a prison at the center of the
grid and may leave after a given period of time [33].
During the simulation, the Pacman is free to absorb
dots that are in the corridors in order to accumulate
points. More precisely, there are 146 normal dots and
four large flashing dots called energizers. Each normal
dot that is absorbed is worth 10 points, whilst the ener-
gizers are worth 50 points each. This yields a total of
1660 points for clearing the maze of dots. When the
Pacman is accumulating points, it should avoid contact
with the ghosts who m try to collide against him [33].
Still, when the Pacman absorbs an energizer, for a
short period of time, the “tables are turned” and the
ghosts assume the role of prey whilst the Pacman as-
sumes the role of predator. During this period, the
Pacman can accumulate points colliding against each of
the four ghosts. Colliding with a frightened ghost yields
Figure 2. Environment produced by the simulator [33].
200 points to the Pacman. Each additional collision
against a ghost from the same energizer will score the
double of the previous collision—400, 800, and 1600
points, re spectivel y [33].
The maximum possible score achieved by the Pacman
is 13,660. The Pacman has a certain period of time to
accumulate as many points as possible, featuring three
lives to do so. Each collision between the Pacman and a
ghost out of the energizer’s period results in loss of life
and a repositioning of the characters in their initial posi-
tion s [33].
Specially, in this simulator, the characters have a vis-
ual field that repr esents the depth with which they see all
the way through the corridors of the maze. Figure 3 il-
lustrates an example of the visual field with depth 5. The
scope of the characters’ vision is represented by circles,
which is limited when faced with the end of the corridor
[33].
3.2. Features of Implementation
The simulator has some special features that benefit the
implementation of causal rules for the movement of the
characters in the corridors of the maze. Among these
peculiarities, the maze has been divided into categories
of corners. Each corner represents the meeting or inter-
section of two or more corridors that compose the maze
[33].
The maze consists of 9 different formats of corners in
order to minimize the amount of causal rules, since the
treatment of characters' actions is based on this classifi-
cation and not in all parts of the maze. As shown in Fig-
ure 4, each particular shape of the corner is represented
by a value, present on a scale of 1 to 9 [33].
Figure 3. Visual Field with depth of 5 [33].
1The copyrights belong to the individual that produced it or the com-
p
any that published it. The use in this paper refers only to academic
study.
Figure 4. Maze divided into 9 different shapes of corners
[33].
Copyright © 2012 SciRes. JSEA
A Game Comparative Study: Object-Oriented Paradigm and Notification-Oriented Paradigm
728
As shown in Figure 3, characters have a certain vision
capability that allows them to perceive elements that
compose the maze. For example, the Pacman sees dots,
walls, ghosts, and empty corridors. As well as, the ghosts
see walls, corridors, the Pacman, and other ghosts. Thus,
based on his view, the characters must make consistent
decisions to move through the corridors of the maze in
search of achieving their goals [33].
The decisions of the characters with respect to their
movement’s actions are dependent on their perception of
elements in their visual fields. For each character, events
are fired as they detect elements in their visual fields.
Usually more than one element is detected every time a
character is in a corner. In order to avoid conflicts, only
one event can be active at any instant, being necessary to
define a scale of priorities for such events [33].
The events instigate the movement actions of the
Pacman have the following order of priority [33]:
Ghost detected in normal state.
Ghost in the scared state detected.
Dot detected.
Empty corridor.
On the other hand, events that instigate movement ac-
tions of the ghosts have the following pri o ri t y order [ 33] :
Pacman detected whilst the ghost in scared state.
Pacman detected whilst the ghost in normal state.
Another ghost detec t e d.
Empty corridor.
The characters only change their direction when they
are on a corner, with the possibility of return to the path
by which they came or choose another corridor to follow.
Figure 5 illustrates an example of a causal rule that
moves the character Pacman [33].
The causal rules that move the characters in each par-
ticular situation are predefined by the s imulator user (i.e.
developers) or with the help of learning algorithms (e.g.
genetic algorithms), which would generate causal rules
for each of the characters that compose the environment
[33].
In this paper, a set of causal rules was elaborated by
developers. These causal rules were respected in both
implementations (i.e. implementations in NOP and OOP)
followed the given causal rules. Moreover, characters
have the same initialization in all implementatio ns.
- Perceptions of the character:
- Current corner: 1
- Detected events (order by priority):
- 1 - Ghost in norma l s t at e (Right)
- 2 - Dot (Right)
- Actions of movement:
- Move downward
Figure 5. Example of a causal rule that moves the Pacman
[33].
These aspects together result, in terms of characters
actions, in a specific and equal execution in every run of
the simulator, both in NOP and OOP implementations.
4. Notification Oriented Paradigm (NOP)
The Notification Oriented Paradigm (NOP) introduces a
new concept to conceive, construct, and execute software
applications [1]. NOP is based upon the concep t of small,
smart, and decoupled entities that collaborate by means
of precise notifications to carry out the software infer-
ence [1,4,8]. This would allow enhancing software ap-
plications performance and potentially makes easier to
compose software, both non-distributed and distributed
ones [1,10].
4.1. NOP Structural View
NOP causal expressions are represented by common
causal rules, which are naturally understood by pro-
grammers of usual paradigms. However, each causal rule
is technically enclosed in a special computational-entity
called “Rule” [1]. An example of Rule Entity content is
illustrated in Figure 6. This Rule structures represent the
causal knowledge related to the case in which the
Pacman should avoid collision with ghost by moving
downwards.
Structurally, a Rule has two parts, namely a “Condi-
tion” and an “Action”, as shown by means of the UML
class diagram in Figure 7. Both are entities that work
together to handle th e causal knowledge of the Rule com-
putational entity. The Condition is the decisional part,
whereas the Action is the execution part of the Rule.
Both make reference to factual elements of the system,
such as “Creature” and “Dot”.
NOP factual elements are represented via a special
type of entity called “Fact_Base_Element” (FBE). A
FBE includes a set of attributes [1]. Each attribute is rep-
resented by another special type of entity called “Attrib-
ute”, such as “CurrentCorner” and “ElementDir” Attrib-
utes of the Creature FBE.
Attributes states are evaluated in the Conditions of
Rules by associated entities called “Premises” [1]. In the
example, the Condition of the Rule is associated to three
Premises, which verify the state of FBE Attributes as
follow: 1) Is the Pacman in the current corner 1? 2) Is the
detected element a Ghost? 3) Is the element direction in
the Right?
When each Premise of a Rule Condition is in tru e state,
which is concluded by means of a given inference proc-
ess, the Rule becomes true and can activate its Action
that is composed of special-entities called “Instigations”
[1]. In the considered Ru le, the Action contains only one
Instigation that makes the Pacman moves down.
In fact, Instigations are lied to and instigate the nk
Copyright © 2012 SciRes. JSEA
A Game Comparative Study: Object-Oriented Paradigm and Notification-Oriented Paradigm
Copyright © 2012 SciRes. JSEA
729
Figure 6. Rule entity.
Figure 7. Rule and Fact_Base_Element class diagram [33].
execution of “Methods”, which are anoth er special-entity
of FBE. Each Method allows executing services of its
FBE. Generally, the call of FBE Method changes one or
more FBE Attribute states, feeding the inference process
[1].
4.2. NOP Inference Process
The NOP inference process is innovative once the Rules
have their inference carried out by active collaboration of
its notifier entities. In sh ort, the collaboration happens as
follow: for each change in an Attribute state of a FBE,
the state evaluation occurs only in the related Premises
and then only in related and pertinent Conditions of
Rules by punctual notifications between th e collaborators
[1,4].
In order to detail this Notification Oriented Inference,
it is firstly necessary to explain the Premise composition .
Each Premise represents a Boolean value about one or
even two Attribute state, which justify its composition: 1)
a reference to a discrete value of an Attribute discrete
value, called Refere n ce, which is received by notification;
2) a logical operator, called Operator, useful to make
comparisons; and 3) another value called Value that can
be a constant or even a discrete value of other referenced
Attribute [1,4].
A Premise makes a logical calculation when it receives
notification of one or even two Attributes (i.e. Reference
and even Value). This calculation is carried out by com-
paring the Reference with the Value, using the Operator.
In a similar way, a Premise collaborates with the causal
evaluation of a Condition . If the Boolean value of a noti-
fied Premise is changed, then it notifies the related Con-
dition set [1,4].
Thus, each notified Condition calculates their Boo lean
value by the conjunction of Premises values. When all
Premises of a Condition are satisfied, a Condition is also
satisfied and notifies the respective Rule to execute [1,4].
The collaboration between NOP entities by notifica-
tions can be observed at the schema illustrated in Figure
8. In this schema, the flow of notifications is represented
by arrows linked to rectangles hat symbolize NOP entities t
A Game Comparative Study: Object-Oriented Paradigm and Notification-Oriented Paradigm
730
Figure 8. Notification chain of Rules and collaborators [1,4,8].
[1,4].
An important point to clarify about NOP collabo rative
entities is that each entity (e.g. Attributes) registers the
entities interested in its state (e.g. Premises) in the mo-
ment that they are created. For example, when a Premise
is created and makes reference to an Attribute, the latter
automatically includes the former in its internal set of
entities to be notified when its state changes [1,4].
4.3. NOP Performance
In NOP, an Attribute state is evaluated by means of a set
of logical expression (i.e. Premise) and causal expression
(i.e. Condition) in the chang ing of its state. Thanks to the
cooperation by means of precise notifications, NOP
avoids the two types of aforementioned redundancies
[1,4].
The temporal redundancy is solved in NOP by elimi-
nating searches over passive elements, once some data-
entities (e.g. Attributes) are reactive in relation to their
state updating and can punctually notify only the parts of
a causal expression that are interested in the updated state
(e.g. Premises), avoiding that other parts and even other
causal expressions be unnecessarily (re-)evaluated [1,4].
Indeed, each Attribute notifies just the strictly con-
cerned Premise due to state change and each Premise
notifies just the strictly concerned Condition due to state
change, therefore implicitly avoiding temporal redun-
dancy. Besides, the structural redundancy is also solved
in NOP when Premise collaboration is shared with two or
more causal expressions (i.e. Conditions). Thus, the Pre-
mise carries out logic calculation only once and shares
the logic result with the related Conditions, thereby
avoiding re-e v a l uati ons [1,4].
4.4. NOP—Decoupling and Distribution
Actually, besides the solving of redundancy and then
performance problems, NOP also is potentially applica-
ble to develop parallel/distributed applications because of
the “decoupling” (or minimal coupling to be precise) of
entities. In inference terms, there is no great difference if
an entity is notified in the same memory region, in the
same computer memory or in the same sub-network
[1,4].
For instance, a notifier entity (e.g. an Attribute) can
execute in one machine or processor whereas a “client”
entity (e.g. a Premise) can execute in another. For the
notifier, it is “only” necessary to know the address of the
client entity. However, these issues also should be con-
sidered in more technical and experimental details in
future publications once there are current works in this
context [1,4].
4.5. NOP Originality
NOP entities (Rules and FBEs) may be confused as just
an advance of Rule Based, Object Oriented, and Event-
Driven Systems, including then Data-Flow-like Pro-
gramming and Inference Engines. However, NOP is far
than a simple evolution of them. It is a new approach that
proposes Rule and FBE smart-entities composed of other
collaborative punctual-notifier smart-entities, which pro-
vide new type of logical-causal calculation or inference
process [1].
This inference solution, in turn, is not just an applica-
Copyright © 2012 SciRes. JSEA
A Game Comparative Study: Object-Oriented Paradigm and Notification-Oriented Paradigm 731
tion of known software notifier patterns, u seful to Event-
Driven Systems, like observer-pattern. It is the extrapo-
lation of that once the execution of the NOP logi-
cal-causal calculation via punctual notifications has not
been conceived before. At least, this is the honest au-
thors’ perception after more than one decade of literature
reviewing [1].
Indeed, this inference innovation changes all the soft-
ware essence with respect to logical-causal reasoning
(one of its essential parts) and then makes the solution a
new programming paradigm. Moreover, as NOP changes
the form that software is structured and executed, it also
determines a change in the form that software is con-
ceived [1,10,30].
4.6. NOP Implementation
In order to provide the use of NOP, its entities were ma-
terialized in C++ language in the form of a framework
[10]. Indeed, it is usual to emergent paradigms be mate-
rialized by means of programming languages of usual
paradigms, already changing them somehow, before the
conception of a particular language and compiler [10].
Anyway, the development of NOP applications have
been made just by instantiating the framework [10,
30-34,36]. Moreover, to make easier this process, a pro-
totypal wizard tool was implemented to automate this
process. This tool generates NOP smart-entities from
causal rules elaborated in a graphical interface.
In this case, developers “only” need to implement
FBEs with Attributes and Methods (with already some
help from the NOP wizard tool), once other NOP spe-
cial-entities will be actually composed and linked by the
tool. Thus, the programmer can make use of the time to
construct the causal base (i.e. composition of NOP Rules)
without concerns to instantiatio ns of the NOP Rules.
Nevertheless, current applications developed in NOP
actually run over some extra layers due to the NOP
Framework materialization over the C++ programming
language. Thus, this framework has been constantly op-
timized to improve the performance of NOP applications.
Among all optimizations performed on the Framework,
the part of the inference process was most impacted. In
its original artifact designed by Banaszewski [10], the
Original NOP Framework was composed of data struc-
tures that hold and iterate over elements. These structures
are vector and list of the C++ Standard Template Libr ary
(STL).
Such structures are considered high level and affect
the performance of the inference process. Thus, particu-
lar (i.e. “in-house”) data structures were implemented in
order to improve the execution of the NOP inference
process, as discussed in [34], thereby generating the
so-called Optimized NOP Framework.
5. A Performance Study
NOP proposes to solve some deficiencies of the usual
programming paradigms, highlighting here some defi-
ciencies of the Object Oriented Paradigm (OOP). This
promise happens by the proposition of an alternative
manner to create and execute software based on an in-
ference solution composed of collaborative notified ob-
jects [1,4,8 ,9].
The cooperation between NOP entities (a sort of
smart-objects in the current framework materialization)
via notifications happens efficiently and in a decoupled
way. This would allow enhancing application perform-
ance (in terms of causal calculation) in single-processor
architectures and presumably also in parallel/distributed
ones [1,4,8].
This paper emphasizes single-processor architectures,
presenting NOP as a solution that avoids temporal and
structural redundancies, thereby supposedly saving re-
sources and speeding up the application performance
with respect to imperative programming in terms of
causal calculation [1,4].
In order to clarify the NOP efficiency, this section
presents a performance comparative study via imple-
mentations of the Pacman game simulator under the
principles of the OOP and under the two different im-
plementations of the NOP Framework, namely the origi-
nal NOP framework [10] and the optimized NOP frame-
work [34].
5.1. Paper New Experiment
This paper presents new experiments with respect to pre-
vious publications. Particularly, there are differences
concerning the experiment developed in [33] (and pre-
sented in Portuguese) and this here developed (and pre-
sented in English).
A first difference is that in [33] the optimized NOP
framework was in a prototypal release, whereas in this
current paper the framework was in a more advanced
release. In the prototypal release, the notification process
in each notifier entity (e.g. each Attribute, each Premise
etc) was based on “in house” linked list. Nowadays, in
the current release, the notification process in each noti-
fier entity is based on quite optimized dynamically allo-
cated vector, which presents better results.
Also, the experiment concerning the prototypal release
of the optimized NOP framework and the original NOP
framework did not use the Premise sharing (in both
frameworks). Thus, the NOP code therein presented
structural redundancies. In turn, the current experiment
shares Premises (in both frameworks), thereby prevent-
ing structural redundancies.
Still, there are some minor differences in the Rules of
the NOP code elaborated in the previous experiment with
Copyright © 2012 SciRes. JSEA
A Game Comparative Study: Object-Oriented Paradigm and Notification-Oriented Paradigm
732
respect to the current one. Moreover, the previous paper
presents fewer details about the experiment implementa-
tion than this current paper.
Moreover, the experiment concerning the prototypal
release of the optimized NOP framework was done under
Linux Ubuntu operating system without real concerns
with respect to preemption. In turn, the experiment con-
cerning the current release was done under Linux Debian
operating (a “lean” Linux version) with minimum of
preemption.
Besides, implementations of the Pacman simulator in
both paper were done by using C++ language and NOP
C++ Frameworks, which were compiled with the GCC
compiler (in standard compilation mode). Still, in both
papers, the used computer was a notebook containing
AMD Turion X2 processor with 3 Gigabytes of RAM
memory and 2.0 GHz of clock.
5.2. Structural Modeling—Class Diagram
Due to the dimensions of the original diagram, the class
diagram shown in Figure 9 abstracts the complexity of
the simulator, expressing its essence by means of the
core classes. The class Game contains the functional
structure of the simulator, consisting of classes Maze,
Score, and Timer. The class Maze represents the struc-
ture of the labyrinth formed by walls (Wall), corners
(Corner), dots (Dot) and characters (Character) [33].
The core of the simulator, in turn, consists of causal
rules that move the characters in the corridors of the
maze, concentrated in the Character subclasses. In short,
each Ghost has inside its causal rues, as well as has the
Pacman.
Still, in general, the simulator is developed under the
principles of OOP. For the NOP version of the Pacman
simulator, only the part responsible for the decision-
making of the characters is implemented following the
principles of the NOP programming [33].
5.3. Computational Experiments
Computational experiments were undertaken in order to
Figure 9. Class diagram of the simulator [33].
verify the performance difference between the different
implementations of the simulator. For these, tests were
performed with the implementation developed in OOP
and with the implementation developed in NOP under
the two different stable versions of the NOP Framework
namely the original NOP framework and the optimized
NOP framework (this in a current stable release).
The implementation structure adopted for the OOP
version of the simulator is composed of decision-making
structures (i.e. ifs) that represent the characters’ percep-
tions on the environment (i.e. movement policy). In order
to explore some deficiencies of the usual programming
languages, such as structural redundancy, causal rules of
movement were developed in OOP with some usual re-
petitive and unnecessary evaluations. The Pseudocode 1
represents this sort of OOP code for Pacman as example.
In turn, in NOP, the implementation adopted for the
simulator consists of a set of Rules and its sub-entities. In
each Rule, the Condition represents the set of character’s
perceptions at a given time, with the premises represent-
ing the current corner, detected element, and the location
of such element. In turn, the respective Action is com-
posed of an Instigation that activ ated determined Method,
resulting in the suitab le character’s movement.
Pseudocode 2 expresses in the form of causal rules the
essence of the program composed in NOP with Rules and
their collaborative entities. As previously mentioned, the
If ( (Corner = 1) and (Visual Field = Ghost in normal state) and
(Detected Element Direction = Right) )
then moveDownwards()
endif
if ( (Corner = 1) and (Visual Field = Ghost in scared state) and
(Detected Element Direction = Right) )
then moveRight()
endif
. . .
if ((Corner = 9) and (Visual Field = No element detected)) then
moveLeft()
Endif
Pseudocode 1. Pacman’s rules of movement developed in
OOP.
Rule 01: Premise – Corner = 1
Premise – Visual Field = Ghost in normal state
Premise – Detected element direction = Right
Instigation–Instigates Method moveDownwards()
Rule 02: Premise – Corner = 1
Premise – Visual Field = Ghost in scared state
Premise – Detected element direction = Right
Instigation – Instigates Method moveRight()
. . .
Rule 80: Premise – Corner = 9
Premise – Visual Field = No element detected
Instigation – Instigates Method moveLeft()
Pseudocode 2. Pacman’s rules of movement developed in
NOP.
Copyright © 2012 SciRes. JSEA
A Game Comparative Study: Object-Oriented Paradigm and Notification-Oriented Paradigm 733
instance of a specific Character subclass (i.e. Pacman or
Ghost) is responsible for its own movement in the corri-
dors of the maze. Thus, all conditional structures in OOP
and NOP Rules are in each Pacman or Ghost instance.
The two versions of the simulator were implemented
in an equivalent manner based on the principles of OOP
and NOP. The tests were executed 1, 10, 100 and 1000
iterations over the simulator. Each iteration consists of a
complete run of a Pacman game simulation, according to
the causal rules defined in the beginning of the execu-
tion.
In order to provide reliable performance tests, the pre-
defined causal rules are the same for all the experiments.
In order to ensure the accuracy of the data, the same ex-
periments were performed with 100 repetitions each.
Thus, the data shown in Table 1 represents the average
time of the experiments in microseconds. The results are
discussed in the subsequent subsection.
5.4. Computational Experiments and Results
Table 1 presents results of the implementation s based on
the causal rules expressed in the Pseudocodes 1 and 2.
Besides, the Table 2 presents results of quite similar im-
plementations comparing the original NOP framework
and the optimized NOP framework in a prototypal re-
lease. This implementations and results were previously
published in [33], as aforementioned.
It is possible to observe that the runtime difference
between the implementations shows that OOP presents
better results compared to NOP, in the two framework
versions, namely the original NOP framework and the
optimized NOP framework both in prototypal and stable
release.
Table 1. Current experiment results—OOP × NOP in De-
bian OS.
Iterations OOP NOP
(Original) NOP (Optimized—
Stable Release)
1 2312 19,395 3935
10 23,123 195,123 38,978
100 234,527 1,945,285 389,913
1000 2,384,329 19,756,192 3,902,992
Table 2. Previous results—OOP × NOP in Ubuntu OS [33].
Iterations OOP NOP
(Original) NOP (Optimized—
Prototypal Release)
1 269 4233 1418
10 2703 42,598 14,212
100 26914 4.24429 1.42199
1000 2.69858 42.41222 14.31158
The current stable optimized NOP framework release
seems better than the prototypal release. However, even
been the experiments somehow similar in functional
terms, the experiment in [33] has differences from the
current one, inclusively in terms of Operating System
(OS) as detailed in subsection 5.1. Thus, the data in Ta-
ble 2 are not accurate to clearly establish the real differ-
ence between prototypal and stable releases of the opti-
mized NOP framework.
Nevertheless, there is a considerable difference be-
tween the original NOP framework and the optimized
NOP framework in both experiments (i.e. of the current
paper and the previous one). Such difference demon-
strates that the actual implementation over this abstrac-
tion layer implemented in C++ causes an overhead in its
execution.
In the current materialization of the NOP Framework,
in terms of assembly language instructions, causal ex-
pressions are certainly more complex and composed of a
greater number of instructions to be processed than
if-then expressions of the OOP. Thus further NOP
framework optimizations or new NOP materialization
(e.g. NOP compiler and language) would be necessary to
achieve NOP potentiality.
6. Conclusions and Future Works
This section discusses NOP features and future works.
6.1. NOP Essence
NOP would be an instrument to improve applications’
performance in terms of causal calculation, especially of
complex ones such as those that execute permanently and
need excellent resource use and response time. This
would be possible thanks to the notification mechanism,
which allows an innovative causal-evaluation process
with respect to those of usual programming paradigms
[1,8-10,29].
The notification mechanism is composed of entities
that collaboratively carry out the inference process by
means of notifications, providing solutions to deficien-
cies of usual paradigms [1,8,9]. In this context, this paper
addressed the performance subject making some com-
parisons of NOP and Imperative/Object Oriented Para-
digm instances.
6.2. NOP Performance
In all the experiments generated over the two implemen-
tations of the simulator, the results of OOP were better
than those of NOP. However, previous asymptotic cal-
culations [10] and other experiments [1] suggest that the
efficiency of NOP would be better than OOP, as dis-
cussed in [1,10]. Taking into account the current materi-
Copyright © 2012 SciRes. JSEA
A Game Comparative Study: Object-Oriented Paradigm and Notification-Oriented Paradigm
734
alization, this would be particularly true to software with
large number of causal evaluation and concerned vari-
ables with discrete and quite low frequency of changes.
In this paper, a particular fact that negatively impacted
in the results was that the simulator be not fully imple-
mented over the NOP principles in the so-called NOP
version of Pacman-Simulat or. Thi s implementation of the
simulator consists of a hybrid version in which only the
characters’ decisions follow the NOP implementation
principles.
Future works should include a more complete version
of the simulator based on the NOP principles. However,
perhaps even a full NOP version of the Pacmam simula-
tor could produce results without real significant gain
with respect to C++ OOP version of the Pacmam simu-
lator, since the current NOP materializa tion still have the
“weight” of a framework over C++. Indeed, NOP should
have a language and a compiler to build NOP native
code.
Nevertheless, the results of Pacman-Simulator per-
formance in the Optimized NOP Framework (in the cur-
rent stable release) with respect to Pacman-Simulator in
the Original NOP Framework performance were consid-
erable improved. Actually, these results were quite near
of the Pacman-Simulator in OOP, as shown in Table 1.
Still, the gain of performance between the Optimized
NOP Framework and the Original NOP Framework was
approximately of 490% over, according to the Table 1 as
well. This fact reinforces that the C++ implementation of
the NOP framework strictly impacts in the performance
of the applications developed in this manner. Probably,
further optimizations of the NOP Framework may pro-
vide better results than th e current obtained ones, namely
in terms of performance.
Besides, actual optimizations are certainly related to
the development of a particular compiler and language.
Anyway, it would solve some drawbacks of the actual
implementation of NOP, such as the overhead of the
NOP Framework by using computationally expensive
data-structure over an intermediary language (C++).
These advances are under consideration in other works.
6.3. NOP Features
In the actual materialization, beyond the so-called Opti-
mized NOP Framework, there is also the so-called NOP
Wizard tool to build FBEs, Rules, and other collaborators
in high level. Thus, the use of NOP Wizard tends to
make easier development of NOP software and save con-
siderable development time with respect to NOP Frame-
work and particularly to OOP. Indeed, the developer
would not have to deal directly with the complicated
syntax of the OOP and especially with interdependences
between causal expressions produced by the imperative
approach.
Still, besides NOP supposedly solve redundancy/per-
formance and development problems, it is also poten-
tially applicable to develop parallel/distributed applica-
tions because of the decoupling (or minimal coupling, to
be precise) of entities. In inference terms, there is no
great difference if an entity is notified in the same mem-
or y regio n, in th e same compu ter me mory o r in th e same
sub-network.
For instance, a notifier entity (e.g. an Attribute) can
execute in one machine or processor whereas a “client”
entity (e.g. a Premise) can execute in another. For the
notifier, it is “only” necessary to know the address of the
client entity. However, these issues also should be con-
sidered in more technical and experimental details in
future publications once there are current works in this
context.
7. Acknowledgements
R. F. Banaszewski’s M.Sc. thesis [10] was supported by
CAPES Foundation (Brazil), as well as R. F. Banas-
zewski’s Ph. D. thesis and A. F. Ronszcka’s M.Sc. thesis
are under CAPES support.
REFERENCES
[1] J. M. Simão, J. M. Simão, R. F. Banasze wski, C. A. Tacla
and P. C. Stadzisz, “Notification Oriented Paradigm
(NOP) and Imperative Paradigm: A Comparative Study,”
Journal of Software Engineering and Applications, Vol. 5
No. 6, 2012, pp. 402-416. doi:10.4236/jsea.2012.56047
[2] R. W. Keyes, “The Technical Impact of Moore’s Law,”
IEEE Solid-State Circuits Society Newsletter, Vol. 20, No.
3, 2006, pp. 25-27.
[3] E. S. Raymond, “The Art of UNIX Programming,” Ad-
dison-Wesley, Boston, 2003.
[4] J. M. Simão and P. C. Stadzisz, “Inference Based on No-
tifications: A Holonic Meta-Model Applied to Control
Issues,” IEEE Transaction on System, Man, and Cyber-
netics, Part A, Vol. 9, No. 1, 2009, pp. 238-250.
[5] W. Wolf, “High-Performance Embedded Computing:
Architectures, Applications, and Methodologies,” Morgan
Kaufmann, Burlington, 2007.
[6] S. Oliveira and D. Stewart, “Writing Scientific Software:
A Guided to Good Style,” Cambridge University Press,
Cambridge, 2006. doi:10.1017/CBO9780511617973
[7] C. Hughes and T. Hughes, “Parallel and Distributed Pro-
gramming Using C++,” Addison-Wesley, Boston, 2003.
[8] J. M. Simão and P. C. Stadzisz, “Notification Oriented
Paradigm (NOP)—A Notification Oriented Technique to
Software Composition and Execution,” Patent Pending
Submitted to INPI/Brazil in 2008 and UTFPR Innovation
Agency 2007.
[9] R. F. Banaszewski, P. C. Stadzisz, C. A. Tacla and J. M
Simão, “Notification Oriented Paradigm (NOP): A Soft-
Copyright © 2012 SciRes. JSEA
A Game Comparative Study: Object-Oriented Paradigm and Notification-Oriented Paradigm 735
ware Development Approach Based on Artificial Intelli-
gence Concepts,” VI Congress of Logic Applied to the
Technology—LAPTEC, Santos, November 21-23, 2007, p.
216.
[10] R. F. Banaszewski, “Notification Oriented Paradigm: Ad-
vances and Comparisons,” Master’s Thesis, Graduate
School in Electrical Engineering and Industrial Computer
Science (CPGEI) at the Federal University of Technol-
ogy—Paraná (UTFPR), Curitiba, 2009.
http://arquivos.cpgei.ct.utfpr.edu.br/Ano_2009/dissertaco
es/Dissertacao_500_2009.pdf
[11] M. Herlihy and N. Shavit, “The Art of Multiprocessor
Programming,” Morgan Kaufmann, Burlington, 2008.
[12] D. Harel, H. Lacover, A. Naamad, A. Pnueli, M. Politi, R.
Sherman, A. Shtulltrauting and M. Trakhtenbrot, “State-
mate: A Working Environment for the Development of
Complex Reactive Systems,” IEEE Transactions on Soft-
ware Engineering, Vol. 16, No. 4, 1990, pp. 403-416.
doi:10.1109/32.54292
[13] D. Sevilla, J. M. Garcia and A. Gómez. “Using AOP to
Automatically Provide Distribution, Fault Tolerance, and
Load Balancing to the CORBA-LC Component Model,”
Advances in Parallel Computing, Vol. 15, 2008, pp. 347-
354.
[14] W. M. Johnston, J. R. P. Hanna and R. J. Millar, “Ad-
vance in Dataflow Programming Languages,” Journal
ACM Computing Surveys, Vol. 36, No. 1, 2004, pp. 1-34.
doi:10.1145/1013208.1013209
[15] G. Coulouris, J. Dollimore and T. Kindberg, “Distributed
Systems—Concepts and Designs,” Addison-Wesley, Bos-
ton, 2001.
[16] W. A. Gruver, “Distributed Intelligence Systems: A New
Paradigm for System Integration,” Proceedings of the
IEEE International Conference on Information Reuse and
Integration, Las Vegas,13-15 August 2007, pp. 14-15.
doi:10.1109/IRI.2007.4296581
[17] J.-L. Gaudiot and A. Sohn, “Data-Driven Parallel Produc-
tion Systems,” IEEE Transactions on Software Engi-
neering, Vol. 16. No. 3, 1990, pp. 281-293.
doi:10.1109/32.48936
[18] P. Banerjee, J. A. Chandy, M. Gupta, E. W. Hodges IV, J.
G. Holm and A. Lain, “The Paradigm Compiler for Dis-
tributed Memory Multicomputer,” IEEE Computer, Vol.
28, No. 10, 1995, pp. 37-47. doi:10.1109/2.467577
[19] P. V. Roy and S. Haridi, “Concepts, Techniques, and
Models of Computer Programming,” MIT Press, Cam-
bridge, Massachusetts, 2004.
[20] S. Kaisler, “Software Paradigm, Wiley-Interscience,” 1st
Edition, John Wiley & Sons, New York, 2005.
[21] M. Gabbrielli and S. Martini, “Programming Languages:
Principles and Paradigms. Series: Undergraduate Topics
in Computer Science,” 1st Edition, Springer/Dordrecht
Heidelberg, London/New York, 2010.
[22] J. G. Brookshear, “Computer Science: An Overview,”
Addison-Wesley, Boston, 2006.
[23] A. M. K. Cheng and J.-R. Chen, “Response Time Analy-
sis of OPS5 Production Systems,” IEEE Transactions on
Knowledge and Data Engineering, Vol. 12, No. 3, 2000,
pp. 391-409. doi:10.1109/69.846292
[24] J. A. Kang and A. M. K. Cheng, “Shortening Matching
Time in OPS5 Production Systems,” IEEE Transaction
on Software Engineering, Vol. 30, No. 7, 2004, pp. 448-
457. doi:10.1109/TSE.2004.32
[25] C. L. Forgy, “RETE: A Fast Algorithm for the Many
Pattern/Many Object Pattern Match Problem,” Artificial
Intelligence, Vol. 19, No. 1, 1982, pp. 17-37.
doi:10.1016/0004-3702(82)90020-0
[26] P.-Y. Lee and A. M. Cheng, “HAL: A Faster Match Al-
gorithm,” IEEE Transaction on Knowledge and Data En-
gineering, Vol. 14, No. 5, 2002, pp. 1047-1058.
doi:10.1109/TKDE.2002.1033773
[27] M. L. Scott, “Programming Language Pragmatics,” 2nd
Edition, Morgan Kaufmann Publishers Inc., San Fran-
cisco, 2000.
[28] J. M. Simão, “A Contribution to the Development of a
HMS Simulation Tool and Proposition of a Meta-Model
for Holonic Control,” Ph.D. Thesis, Federal University of
Technology, Paraná; Henri Poincaré University, Nancy,
2005.
http://tel.archives-ouvertes.fr/docs/00/08/30/42/PDF/Thes
isJeanMSimaoBrazil.pdf
[29] J. M. Simão, C. A. Tacla and P. C. Stadzisz, “Holonic
Control Meta-Model,” IEEE Transaction on System, Man
& Cybernetics, Part A, Vol. 39, No. 5, 2009, pp. 1126-
1139.
[30] L. V. B. Wiecheteck, “Software Design Method Using
Notification Oriented Paradigm—NOP,” Master’s Thesis,
Graduate School in Electrical Engineering and Industrial
Computer Science (CPGEI) at the Federal University of
Technology—Paraná (UTFPR), Curitiba, 2011.
[31] R. R. Linhares, A. F. Ronszcka, G. Z. Valença, M. V.
Batista, C. R. Erig Lima, F. A. Witt, P. C. Stadzisz and J.
M. Simão, “Comparison between Object Oriented Para-
digm and Notification Oriented Paradigm under the Con-
text of Telephonic System Simulator,” Internacional
Congress of Computation and Telecomunications, Lima,
October 2011.
[32] M. V. Batista, R. F. Banaszewski, A. F. Ronszcka, G. Z.
Valença, R. R. Linhares, P. C. Stadzisz, C. A. Tacla and J.
M. Simão, “A Comparison between Notification Oriented
Paradigm (NOP) and Object Oriented Paradigm (OOP)
Carried out by Means of the Implementation of a Sale
System,” Internacional Congress of Computation and
Telecomunications, Lima, October 2011.
[33] A. F. Ronszcka, D. L. Belmonte, G. Z. Valença, M. V.
Batista, R. R. Linhares, C. A. Tacla, P. C. Stadzisz and J.
M. Simão, “Qualitative and Quantitative Comparisons
between Object Oriented Paradigm and Notification Ori-
ented Paradigm Based on Play Simulator,” Internacional
Congress of Computationm and Telecomunications, Lima,
October 2011.
[34] G. Z. Valença, R. F. Banaszewski, A. F. Ronszcka, M. V.
Batista, R. R. Linhares, J. A. Fabro, P. C. Stadzisz and J.
M. Simão, “NOP Framework, Advances and Compari-
sons,” Symposium of Applied Computing, Passo Fundo,
2011.
[35] B. D. Wachter, T. Massart and C. Meuter, “dSL: An En-
Copyright © 2012 SciRes. JSEA
A Game Comparative Study: Object-Oriented Paradigm and Notification-Oriented Paradigm
Copyright © 2012 SciRes. JSEA
736
vironment with Automatic Code Distribution for Indus-
trial Control Systems,” Proceedings of the 7th Interna-
tional Conference on Principles of Distributed Systems,
La Martinique, France, 10-13 December 2003, pp. 132-
145.
[36] L. V. B. Wiecheteck, P. C. Stadzisz and J. M. Simão, “A
UML Profile to the Notification Oriented Paradigm
(NOP),” Internacional Congress of Computation and
Telecomunications, Lima, October 2011.
[37] A. R. Pimentel and P. C. Stadzisz, “Application of the
Independence Axiom on the Design of Object-Oriented
Software Using the Axiomatic Design Theory,” Journal
of Integrated Design & Process Science, Vol. 10, No. 1,
2006, pp. 57-69.
[38] S. Ahmed, “CORBA Programming Unleashed,” Sams
Publisher, Indianapolis, 1998.
[39] D. Reilly and M. Reilly, “Java Network Programming
and Distributed Computing,” Addison-Wesley, Boston,
2002.
[40] E. Tilevich and Y. Smaragdakis, “J-Orchestra: Automatic
Java Application Partitioning,” ECOOP’2002 Proceeding
of the 16th European Conference on Object-Oriented
Programming, Springer-Verlag, London, 2002. pp. 178-
204.
[41] M. Díaz, D. Garrido, S. Romero, B. Rubio, E. Soler and J.
M. Troya, “A Component-Based Nuclear Power Plant
Simulator Kernel: Research Articles,” Concurrency and
Computation: Practice and Experience, Vol. 19, No. 5,
2007, pp. 593-607. doi:10.1002/cpe.1075
[42] S. M. Deen, “Agent-Based Manufacturing: Advances in
the Holonic Approach,” Springer, Berlin, 2003.
[43] H. Tianfield, “A New Framework of Holonic Self-Or-
ganization for Multi-Agent Systems,” IEEE International
Conference on Systems, Man and Cybernetics, Montreal,
7-10 October 2007.
[44] V. Kumar, N. Leonard and A. S. Morse, “Cooperative
Control,” Springer-Verlag, New York, 2005.
[45] S. Loke, “Context-Aware Pervasive Systems: Architec-
tures for a New Breed of Applications,” 1st Edition, Au-
erbach Publications, Boca Raton, 2006.
[46] A. S. Tanenbaum and M. van Steen, “Distributed Systems:
Principles and Paradigms,” Prentice Hall, Upper Saddle
River, 2002.
[47] J. Giarratano and G. Riley, “Expert Systems: Principles
and Practice,” PWS Publishing, Boston, 1993.
[48] S. Russel and P. Norvig, “Artificial Intelligence: A mod-
ern Approach,” Prentice-Hall, Englewood Cliffs, 2003.
[49] D. P. Miranker, “TREAT: A Better Match Algorithm for
AI Production System,” 6th National Conference on Arti-
ficial IntelligenceAAAI’87, Seattle, 13-17 July 1987, pp.
42-47.
[50] D. P. Miranker and B. Lofaso, “The Organization and
Performance of a Treat-Based Production System Com-
piler,” IEEE Transactions on Knowledge and Data Engi-
neering, Vol. 3, No. 1, 1991, pp. 3-10.
doi:10.1109/69.75882
[51] D. P. Miranker, D. A. Brant, B. Lofaso and D. Gadbois,
“On the Performance of Lazy Matching in Production
System,” 8th National Conference on Artificial Intelli-
gence AAAI, Boston, 29 July-3 August 1990, pp. 685-692.
[52] D. Watt, “Programming Language Design Concepts,” J.
W. & Sons, Baltimore, 2004.
[53] T. Faison, “Event-Based Programming: Taking Events to
the Limit,” Apress, New York, 2006.
[54] S. M. Tuttle and C. F. Eick, “Suggesting Causes of Faults
in Data-Driven Rule-Based Systems,” Proceedings of the
IEEE 4th International Conference on Tools with Artifi-
cial Intelligence, Arlington, 10-13 November 1992, pp.
413-416. doi:10.1109/TAI.1992.246438
[55] C. E. Barros Paes and C. M. Hirata, “RUP Extension for
the Software Performance,” 32nd Annual IEEE Interna-
tional Computer Software and Applications, Turku, 28
July 2008, pp. 732-738.
[56] G. R Watson, C. E. Rasmussen and B. R. Tibbitts, “An
Integrated Approach to Improving the Parallel Applica-
tion Development Process,” IEEE International Sympo-
sium on Parallel & Distributed Processing, Rome, 23-29
May 2009, pp. 1-8.
[57] I. Sommerville, “Software Engineering,” 8th Edition,
Addison-Wesley, Boston, 2004.
[58] J. Pittman, “The Pac-Man Dossier,” 2011.
http://home.comcast.net/~jpittman2/pacman/pacmandossi
er.html