Interactive Filtering Algorithm - George Jenkins 2014
1. Interactive Filtering Algorithm
Parameterisation.
A report
submitted in fulfillment
of the requirements for the degree
of
Bachelor of Computing and Mathematical Sciences with
Honours
at
The University of Waikato
by
George Maurice Jenkins
Department of Computer Science
Hamilton, New Zealand
October 21, 2014
c 2014 George Maurice Jenkins
2.
3. Abstract
Alerting systems are pieces of software that match user defined requirements
to events as they occur. Users (human or otherwise) may specify their data re-
quirements in profiles. The alerting system notifies all users subscribed to that
profile when a to match a profile is found. Alerting systems may also allow ad-
ministrators to make modifications to the underlying filtering algorithm that
defines how matches are made through the specification of filtering algorithm
parameters. However, it remains a difficult task to specify said parameters
in contemporary alerting systems, even for experienced administrators. This
project utilised previous research in this area in conjunction with the findings
of an investigation into a predefined event algebra in order to implement a
functional digital prototype of a system for specifying filtering algorithm pa-
rameters. A usability analysis of the solution was then completed through the
means of a user study.
4.
5. Acknowledgements
I offer my gratitude to my supervisor, Dr Doris Jung. Doris, thank you for
your patience, guidance and lighthearted council throughout the term of this
project. You helped turn what was once a daunting, confusing task into an
opportunity for growth, both personally and academically. I could not have
asked for a more supportive nor approachable mentor.
13. List of Figures xiii
7.1 Correct and incomplete model answer for task 1A . . . . . . . . . 65
7.2 Correct and complete model answer for task 1A . . . . . . . . . . 66
7.3 Complete concurrency . . . . . . . . . . . . . . . . . . . . . . . . 66
7.4 Incomplete concurrency . . . . . . . . . . . . . . . . . . . . . . . 66
7.5 Matches enabled by a correct and complete model answer for task 6 68
7.6 Matches enabled by a correct and complete model answer for task 6 68
7.7 The ‘Select existing data type’ pane within the prototype . . . . . 71
14.
15. List of Tables
2.1 Plausibility matrix for filtering parameter combinations . . . . . . 25
4.1 Modified terminologies. . . . . . . . . . . . . . . . . . . . . . . . . 48
6.1 Participant groups . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.2 Result summary for participants in the non-software group. . . . . 55
6.3 Result summary for participants in the software group. . . . . . . . 57
6.4 Result summary for participants in both groups. . . . . . . . . . . 58
6.5 Result summary for the ease of understanding survey with partici-
pants in the non-software group. . . . . . . . . . . . . . . . . . . . 60
6.6 Result summary for the ease of understanding survey with partici-
pants in the software group. . . . . . . . . . . . . . . . . . . . . . . 61
6.7 Software usability survey results . . . . . . . . . . . . . . . . . . . 63
16.
17. Chapter 1
Introduction
This thesis encompasses the implementation of an application that allows for
the specification of filtering algorithm parameters within an alerting system.
It is supported by an investigation into the functionality that underpins the
application.
A framework of functionality for the filtering algorithm parameters and their
combinations has been derived from existing work and modified for the do-
main of alerting systems. An algorithm to perform the filtering and enable
the functionality of the filtering algorithm parameters has been designed and
created. A functional prototype system has been implemented in C#, and
the usability associated with it has been examined through user testing. Con-
clusions as to the overall usability of the paper prototype and understanding
of the underlying framework are made, and opportunities for future work are
presented.
1.1 Introduction to Alerting Systems
Alerting systems, sometimes referred to as event notification or publish-subscribe
systems, are pieces of software that allow users to define specific data require-
ments. The alerting system then uses the data requirements, or user profiles,
to find matches to patterns within a transient sequence of data. A match is
found when the requirements of a specified user profile are satisfied by the
items within the incoming sequence of data. An example of a user profile is a
profile for an alerting system within a weather station that requires an increase
in rainfall and a decrease in temperature. When these two events occur in the
sequence of data, a match is found.
18. 2 Chapter 1 Introduction
The items within the sequence of data are known as events, and are the pieces of
information that relay a change in state of the monitored data. An example of
this may be an event relaying a change in temperature, where the temperature
has increased by five degrees Celsius. The sequence of data, known as an
event instance sequence (EIS), is provided by publishers. Publishers provide
periodic updates to the alerting system, and are most often sensor nodes.
Publishers can be varied in nature, and different publishers can be combined
and used for specific applications. Because of this, alerting systems exist in
multiple contexts, such as medical alert systems [14] or intrusion detectors [9].
When the alerting system is enabled to find a match to a set user profile, the
system alerts the subscriber(s). These subscribers may be a group of one or
more humans, machines, or a combination of both. A diagram showing this
functionality is shown in Figure 1.1.
User profiles are created by defining specific events. For example, one may
imagine an alerting system within a weather station, in which a user can define
a profile to consist of a change in state (event) of the humidity. User profiles
defined within an alerting system have multiple aspects other than the event
data itself. Users are enabled to specify logical relationships that dictate how
the events within a user profile relate, such as time, date and frequency. For
example, a user may define that the two events that form a specific user profile
must occur within five minutes of each other. More complex user profiles are
able to be created within an alerting system by combining multiple events (or
profiles) through the use of an event algebra [8] [15].
An alerting system may also be modified to filter events in different ways in
order to suit different types of requirements on an event stream level. This
involves specifying a set of criteria that defines which events within an EIS
are eligible for profile matching. This operates independently from the pro-
file matching itself. This is achieved through the use of filtering algorithm
parameters.
Filtering algorithm parameters are defined within a event algebra. Different
event algebras define different filtering algorithm parameters. Within this in-
vestigation, the event algebra defined by Unland and Zimmer was used [15].
Unland and Zimmer present a super-set of filtering algorithm parameters de-
fined by other authors. This investigation is concerned with the following
filtering algorithm parameters: concurrency, coupling, consumption and pa-
19. 1.2 Related Work 3
rameter selection.
The concurrency, coupling and consumption parameters may all be modified
to suit certain distinct patterns in data [8] [15] [16]. Revisiting the weather
station example, a user profile could conceivably be defined for a severe weather
warning. This profile would require a high level of rain and high wind speeds
to happen at the same time. This can be achieved within the user profile
definition, where a specification can be made that the two events must occur
within a specified (short) period of time. A similar effect can also be achieved
through the use of the filtering algorithm parameters. The coupling mode,
requiring events to happen in sequence without interruption from other events
not related to the user profile, could be specified to limit the profile matching
in a different fashion. That is the user profile definition is concerned with
the change in state of the monitored data held within the events, whereas the
filtering algorithm parameter modes are concerned with how the events occur
within the EIS and in relation to other events.
1.2 Related Work
There have been a number of related projects in the field of alerting systems,
producing concepts and implementations for both industry and research [13].
Related work has focused on several different areas of optimisation, from rout-
ing and infrastructure, to concepts purpose-built for specific circumstances.
Miller and Stutman [14] introduced a system for monitoring medical and geode-
tic information pertaining to the state of a patient. Carzaniga, Rosenblum and
Figure 1.1: A logical view of an alerting system. The system accepts events provided
to it by one or more publishers. It matches the incoming data against
pre-defined criteria. On finding a match, the alerting system dispatches
notifications to all subscribers.
20. 4 Chapter 1 Introduction
Wolf [6] describe SIENA, a wide-area event notification service focused on in-
frastructure scalability and expressiveness. Similarly, Herald, as presented by
Cabrera, Jones and Theimer [4], defined a global event notification service cen-
tered around large publish-subscribe systems and multiple components. Ba-
navar et al. [2] provide routing optimisation through ‘link matching’, reducing
the computation required for multicast event publishing. Jayaram, Jayalath
and Eugster [9] introduce parametric subscriptions to aid in subscription adap-
tions. This research is concerned with efficiency and time reduction in regards
to profile specification and management. Moreover, it provides a user-centric
interface which many other systems lack [10] [16]. No related work has defini-
tively produced or tested a user-centric system for the paramaterisation of the
filtering algorithm.
In relation to enabling user modification of the filtering algorithm parameters,
current systems remain difficult to use competently, even for experienced users
[10] [16]. Research completed by Van Waveren [16] proposed a paper prototype
to attempt to resolve the issue of specification of filtering algorithm parameters
within an alerting system. However, this prototype remained just that, a static
design. The extent of the planned underlying functionality relied on a basic
investigation into parameters defined in existing literature [15]. Although an
investigation into compatible parameters was given, the research did not define
the complete set of interactions between parameters. No algorithm was defined
to underpin the functionality of the event filter.
1.3 Motivation
Although the filtering algorithm parameters enable users with fine grained
control over the data matching within the filtering algorithm, without an ef-
fective method to modify these parameters they often remain unmodified and
hence underutilised. A system that enables users to easily modify the filtering
algorithm parameters and provides feedback as to the effect of the filtering
algorithm parameters and their associated interactions is desired to facilitate
such control.
21. 1.4 Approach 5
1.4 Approach
In order to utilise the previous research to realise a functional prototype, three
main components first had to be created: the finalised interaction design, the
functionality of the filtering algorithm parameters, and the filtering algorithm
itself.
Although a prototype existed [16], the lack of functionality left far more to
be desired. Dr Doris Jung undertook a revision of this prototype. The two
prototypes were similar in that the intended purpose remained the same, but
differed in terms of visual presentation and interaction design. Because design
of this nature is an iterative process, the revised version addressed a number
of issues related to usability discovered in the evaluation of the original proto-
type. The revised prototype is further explored in Chapter 4. Both the paper
prototype and the implemented software are presented, including information
regarding the drawbacks and modifications required.
Previous research [16] defined the parameter set to be used within the proto-
type. However, the researched parameter semantics were intended for active
database management systems, not alerting systems. Because of this, certain
parameters specified in the previous research were incompatible with the re-
quirements of the domain of alerting systems. As alerting systems work with
transient sets of data with an EIS (not a database), the function of certain
parameters would not work in a manner that may be desired by the user. An
example of this is the parameter selection mode of First. Within the original
definition, this mode would only provide a single match, regardless of how
many potential matches that existed. This can already be achieved within
the profile definition stage, and would not be a desired feature within the fil-
tering algorithm paramters. The effects of several of the parameter selection
modes were modified according to the requirements of the new domain. The
full definitions of the filtering algorithm parameters used and the logical inter-
actions between different combinations of parameters are explored in detail in
Chapter 2.
The investigation into the filtering algorithm parameter semantics provided
feedback that actively steered the development of the graphical interface and
related interaction design. For example, the discovery of an incompatibility
between two specific parameter modes meant that the user could place the
software into a state that would return no matches, regardless of the EIS and
22. 6 Chapter 1 Introduction
user profile settings. This was not a situation that had been previously identi-
fied by Jung. The interaction design was modified to prevent this combination
from being set.
After creating a framework for the filtering algorithm parameter combinations,
a filtering algorithm was required in order to provide the user profile matching
capability of the software. The filtering algorithm parameters were required to
be able to be implemented within the filtering algorithm itself. Several existing
algorithms were investigated, including Binary Decision Diagrams and Tree
Matching. However, due to the unique structure of the data, a custom filtering
algorithm was defined and used. This investigation is detailed in Chapter 3.
The implementation paired the interface design prototype with the results of an
investigation into the theoretical parameter dependency analysis through the
use of the custom event filtering algorithm. The realised system is presented
in Chapter 4.
To evaluate the success of the prototype software in terms of both function
and usability, a user study was designed and executed. This user study utilised
a between groups design and proposed the hypothesis that participants would
show greater comprehension in tasks that required users to give the outcomes
of combinations of filtering algorithm parameters when provided with the soft-
ware than those that were not provided with the software. Chapter 5 presents
the study itself, including the design, participants, and motivation. The tasks
and surveys presented to participants are summarised and supported with the
methodology used.
Chapter 6 outlines the results of the user study and surveys. Conclusions are
drawn from the task results. Tasks are itemised, and the participant sentiments
are given in table form.
Chapter 7 provides a discussion into the results gained in Chapter 6. Re-
sults are analysed in context of the participant groups. Areas of interest are
investigated thoroughly with reference to the software and the task results.
Chapter 8 summarises the research and user testing. It also provides future
work topics.
23. Chapter 2
Background and Definitions
A major component for the implementation of Jung’s proposed interface proto-
type is the definition of the framework that underpins the logical relationships
between filtering algorithm parameters. This framework was developed as part
of this honours project, and was a prerequisite to the software implementation.
Filtering algorithm parameters not only need to be defined, but the interac-
tions between them require investigation also. That is, the filtering algorithm
parameters define different functions, and can be modified individually.
Combinations of filtering algorithm parameters are used to enable different
effects. Without both of these aspects, the semantics of filtering algorithm
parameters are impossible to implement uniformly. Due to the lack of definitive
explanations of combinations and interactions of filtering algorithm parameters
within the literature [15], a framework had to be compiled. Many current
systems do indeed allow combinations of filtering algorithm parameters, yet the
lack of a usable interface means they often operate with ‘default’ parameters
[16]. The framework defined within the following chapter may also function as a
potential reference/foundation for verification of any further models produced,
such as the implemented software solution.
2.1 Introduction to Event Filtering
There are multiple different components within an alerting system, includ-
ing functions for receiving data from event publishers, filters for matching
events against specified profiles, and brokers for dispensing notifications to
subscribers. This project will focus on only one of these modules, the event
filter. This section describes several concepts essential to event filtering algo-
24. 8 Chapter 2 Background and Definitions
rithms and their associated parameters in regards to how they will operate
within the completed software system.
The function of the event filter within an alerting system is to compare and cor-
relate incoming event data against registered user profiles, discovering matches
within the data stream [11]. To underpin the function of the event filter, an
event algebra is required. An event algebra specifies such things as how the
user data requirements (user profiles) are to be specified within an alerting
system (including what operands are available, and what notation should be
used), and how the matching actually operates within the system.
Within this investigation, focus will be centered around the event algebra pro-
vided by Unland and Zimmer [15]. This is because a previous investigation
revealed it would provide a simpler method for users to operate in comparison
to the alternatives [16]. Unland and Zimmer’s event algebra will be supple-
mented with additional concepts in order to ensure suitability in this project.
As the project is focused on the parameterisation of a filtering algorithm,
the filtering algorithm parameters defined within Unland and Zimmer’s event
algebra [15] will be explored in depth. There are multiple different filtering
algorithm parameters that an event filter requires to operate. When combined,
these filtering algorithm parameters describe how the event instances within an
incoming sequence of events are to be matched to user profiles. Although the
researched documents that present the event algebra aptly describe the filtering
algorithm parameters, they neglect to define all combinations between the
filtering algorithm parameters themselves. To show how the filtering algorithm
parameters will work individually and when combined with each other within
the software solution, a framework of definitive combinations and effects had
to be created. To represent this framework, a visualisation method defined
by Jung is used [11]. This method involved the combination of shapes and
numerical labels to represent event instances, and uses lines and colours to
represent profile matches as outlined in Section 2.1.1.
In defining each of the different combinations of filtering algorithm parameters,
one must pay special attention to the effect of combinations between said
parameters. In certain situations, the selectivity (ability to find matches)
of the event filter may be either increased or decreased. In some cases the
filter may suffer underlying incompatibilities between the filtering algorithm
parameters that results in no matches at all. To sufficiently investigate each of
25. 2.1 Introduction to Event Filtering 9
the filtering algorithm parameters and the effect of the combinations between
them, an example EIS and user profiles must be used. These are given in
Sections 2.1.1 and 2.1.2 respectively. Each filtering algorithm parameter is
described, and visual representations of the matches found when applied to
the example user profiles and EIS are given within Section 2.2. Once the
foundational information in regards to the parameters has been covered, the
interactions and incompatibilities will be investigated and categorised.
It is advantageous to note that the completed software prototype will require
a complete set of filtering algorithm parameters to operate, so the examples
given to explain the function of each filtering algorithm parameter require a
complete set of parameters also. That is, each filtering algorithm parameter
example will require a setting for the coupling, concurrency, consumption and
parameter selection mode. Because of the requirement to specify a complete
set of filtering algorithm parameters for each example, examples will use fil-
tering algorithm parameters that are most suited to exhibiting the effect of
the parameter being investigated. For example, to fully convey the effect of
a certain filtering algorithm parameter, it is best to remove the function of
other filtering algorithm parameters as much as possible. Using a uniform set
of filtering algorithm parameters for all examples also aids in removing any
complication in regards to explanations.
There are multiple different types of user profile that may be constructed
within the filtering algorithm parameter specification software.
• Simple Profile
Single event instances may be used to form a simple profile, requiring
only the event to occur within the EIS in order to find a match.
• Binary Complex Profile
Two or more event instances my be combined to form a complex profile.
The sequence operator defined in the event algebra [15] is used to combine
two simple profiles into a binary complex profile1
.
• Nested Binary Complex Profile
Two or more profiles may be combined in a similar manner to the binary
1
Other operators exist, both unary and binary. These operators are: repetition, negation,
disjunction and conjunction. However, the sequence operator proved sufficiently complex
for the requirement of showing the effect of filtering algorithm parameters. Other systems
for profile specification provide these operators [10].
26. 10 Chapter 2 Background and Definitions
complex profile in order to form a nested binary complex profile. Nested
binary complex profiles also utilise the sequence operator, and can be
comprised of a range of binary complex profiles and simple profiles.
Profiles of these types are defined in Section 2.1.2. Profiles are specified using
the notation used by Unland and Zimmer [15]. This notation is shown in
Figure 2.1. The profile name takes the form of P#, where # is the number of
the profile. The events (or profiles) required to form a match to the profile are
illustrated within the parentheses. The operator ‘;’ defines that the events (or
sub-profiles) must occur in sequence. For example, if profile P3 is defined as
P3: =; (P1, P2), then the sub-profile P1 must occur before sub-profile P2 in
order to find a match to the complex nested profile P3.
2.1.1 Model Event Instance Sequence
An event instance sequence (EIS) [15] is a sequence of event instances that are
presented in order of occurrence to an alerting system. The event instances
within an EIS are usually provided by publishers, but to effectively commu-
nicate the functions of the filtering algorithm parameters in this situation, a
model EIS is required. This is because an EIS is required to find profile matches
within. To explain the function of the filtering algorithm parameters, matches
must be able to be found. Such a model EIS that will satisfy the requirements
of providing at least one match for each example is given in Figure 2.2. The
model EIS is visualised using geometric shapes and textual labels. Different
shapes represent different event types [15], while the labels provide event in-
stance information [15]. The subscript value within each shape indicates the
event occurrence, whereas the superscript value (if present) indicates the event
type. To represent profile matches found by the event filters, both colour and
arrows will be used. Colours are used to show which profile the match refers
to, and arrows are used to show the combination of event instances within
Figure 2.1: The notation that will be used to define user profiles.
27. 2.1 Introduction to Event Filtering 11
each profile match. Crosses displayed underneath events signify the event has
been deleted as an effect of the consumption mode. For an example of this,
see Figure 2.15.
2.1.2 Profile Definition
The data requirements of a user are specified within a user profile. Specified
here is a group of user profiles that are suitable for displaying the relationships
between each filtering mode. We will use a simple profile, a complex profile
(built from two different events), and a combination of the two to form a nested
complex profile. These profiles are specified using the notation used by Unland
and Zimmer [15].
These profiles only utilise one of the several available operators, the sequence
operator ‘;’. Other operators, such as the conjunction, disjunction, repetition
and negation operators exist and are specified within literature [15], but are un-
necessary for the requirements of showing the effects of the filtering algorithm
parameters. The sequence operator was chosen as it is sufficiently complex to
Figure 2.2: The event instance sequence (EIS) that will be used to visualise the filter
effects on data. The event on the far left has occured first, whereas the
event on the far right has occurred last.
Figure 2.3: This profile, entitled P1, specifies a simple sequence of a event e1 (a circle)
followed by an event e2 (a square).
Figure 2.4: This profile, entitled P2, specifies a single instance of a event e4 (a triangle).
Figure 2.5: This profile, entitled P3, specifies a sequence of two profiles. Both P2 and
P1 need to be found in that order in order to find a match to P3.
28. 12 Chapter 2 Background and Definitions
show all types of effects of the filtering algorithm parameters. Further opera-
tors are available within the profile specification prototype developed by Jung
[10].
2.2 Filtering Algorithm Parameter Investigation
This section encompasses the investigation into the function of the filtering
algorithm parameters as defined by Unland and Zimmer [15].
2.2.1 Parameter Selection
Parameter selection (or event instance selection [17]) is used to define which
event in a series of duplicate events is eligible to be used within a profile match.
Parameter selection options as defined by Unland and Zimmer are usually im-
plemented as minimum-oriented selection strategies, meaning they select the
very minimum of instances [17]. This means that the capabilities of the filter
are restricted to finding at most a single match for each profile. However,
this type of parameter selection is intended for use in active databases and
is incompatible with the requirements of the event filter in this circumstance.
This is due to the fact that the application of the prototype system [10] differs
from the use with active database systems intended by Unland and Zimmer
[17]. For this mode to be useful within an alerting system, it is required to
not be restricted to only a single match. This is because alerting systems are
designed to handle a constant stream of data. Finding only a single match
is a function that is more suited to active databases than alerting systems.
Current profile definition software also allows the functionality to limit match
discovery to only a single match [10], so simply defining the function in an-
other method is unnecessary. In modifying the parameter selection mode to
select parameters in terms of instance occurrence in sequences, not in terms of
global occurrence, we alleviate the problem. That is, we modify the operation
provided to select the nth occurrence of an event instance in a sequence of
duplicate event instances, not the nth event instance in the entire EIS.
Note that the function of other filtering algorithm parameters (such as con-
sumption, coupling and concurrency modes) will be directly modified by the
parameter selection setting. In the filtering algorithm, several different pa-
rameter selection options will be implemented. There are only two parameter
29. 2.2 Filtering Algorithm Parameter Investigation 13
selection modes defined by Unland and Zimmer, First and Last. However,
according to the filter paper prototype, the parameter selection modes of All
and Nth are also to be implemented. Hinze and Voisard’s parameter selection
paradigms [11] are used to supplement the definitions given.
All
The parameter selection of all represents the promiscuous mode of the event
filter. It provides no restrictiveness based on parameter selection in regard to
event instance duplicates, and hence does not restrict the ability of the filtering
algorithm to find matches. This is an option given by Hinze and Voisard [11].
This mode is shown in Figure 2.6.
First
According to Unland and Zimmer’s definition, the parameter selection mode
of first means the filter chooses those viable event instances with the oldest
timestamps [17], or the instances that were the first to occur. Since the event
instance sequences are in occurrence order, the implied direction of traversal is
from left to right [17]. This means the occurrence of an event used in a match
to a complex profile will be the first event detected from left-to-right.
Because of the incompatibility of Unland and Zimmer’s definition for the pur-
poses of use within an event filter, this mode has been modified to choose the
first occurrence of duplicate events. The implications of this means that in the
event that several instances of the same event type occur in direct succession,
Figure 2.6: The visual representation of the parameter selection mode of All. It can
be assumed the consumption mode is set to all (as investigated in Sec-
tion 2.2.5), the coupling mode is set to non-continuous (Section 2.2.3) and
the concurrency is set to overlapping (Section 2.2.4). The profiles attempt-
ing to be matched are shown in Figures 2.3, 2.4 and 2.5.
30. 14 Chapter 2 Background and Definitions
only the first occurrence will be taken. If a single event type occurs and is fol-
lowed immediately by an event of a different type, the first event will qualify
for selection by the filter. This is because a single event is still considered the
first duplicate event, even though there has not been a sequence of duplicates
to follow it. This mode is shown in Figure 2.7.
Last
Similar to first, the parameter selection mode of last means the filter will
choose the instances with the newest timestamps. These are the events with
occurrence times considered from right-to-left. That is, an event will be chosen
over a duplicate of that event if it has occurred earlier than the alternative (is
further to the right than the other event). The modified version of this filter
again applies to duplicates. That is, in the event of a sequence of duplicate
event types, the last event instance to occur will be chosen. If a single event
type occurs and is followed immediately by an event of a different type, the
first event will qualify for selection by the filter. Similar to the case of First,
a single event instance can be considered the last in a sequence of duplicates,
although no other successive duplicates have occurred. This mode is shown in
Figure 2.8.
Nth
In an alerting system, sometimes it is advantageous to select the nth occurrence
of an event. The parameter selection mode ‘nth’ allows the user to specify the
number of occurrences (n - 1) that must occur in sequence before an event
Figure 2.7: The visual representation of the parameter selection mode of First. It can
be assumed the consumption mode is set to all, the coupling mode is set
to non-continuous and the concurrency is set to overlapping. The profiles
attempting to be matched are shown in Figures 2.3, 2.4 and 2.5.
31. 2.2 Filtering Algorithm Parameter Investigation 15
Figure 2.8: The visual representation of the parameter selection mode of Last. It can
be assumed the consumption mode is set to all, the coupling mode is set
to non-continuous and the concurrency is set to overlapping. The profiles
attempting to be matched are shown in Figures 2.3, 2.4 and 2.5.
instance qualifies for selection. As an example, by specifying the parameter
selection mode as ‘2nd’, the filter will only consider the second duplicate event
instance of an event type for each set of duplicates that occur in direct suc-
cession. This mode of parameter selection is a supplemental option given by
Hinze and Voisard [8], and is also described by Jung [10]. This mode is shown
in Figure 2.9.
2.2.2 Traversal Mode
The traversal mode, as outlined by Unland and Zimmer [17], defines the di-
rection in which the event instance sequence is evaluated. Event instance
sequences can be evaluated in two directions, either forward (left-to-right) or
backwards (right-to-left) in time [17]. An example of the forward traversal
mode is given in Figure 2.10, whereas an example of backward traversal is
given in Figure 2.11. The traversal mode does not modify the event instance
occurrence time, but simply how they are interpreted. In an EIS, occurrence
Figure 2.9: The visual representation of the parameter selection mode of 2nd (nth where
n is two). It can be assumed the consumption mode is set to all, the coupling
mode is set to non-continuous and the concurrency is set to overlapping.
The profiles attempting to be matched are shown in Figures 2.3, 2.4 and
2.5.
32. 16 Chapter 2 Background and Definitions
times flow from left to right, with event instances that have occurred first
(have the oldest time stamps) on the left, and those that have occurred more
recently (have more recent time stamps) on the right.
This has direct implications on the results we are able to obtain by applying the
filtering algorithm over a given EIS. The traversal mode is able to modify what
the parameter selection option considers to be matches. The traversal mode
direction effects what event instances the filter considers to have occurred first
[10]. For example, if the algorithm is attempting to match a single event in
an EIS where there are multiple occurrences in direct succession, the traversal
mode will determine where to start the evaluation from. If the traversal mode
is evaluating forward in time, the first event encountered from left-to-right is
taken as the match. If the traversal mode is evaluating backwards, the first
event taken from right-to-left is taken.
However, for the application of filtering events, the traversal mode is extra-
neous for the event filter as events are to be filtered in chronological order
[11]. The traversal mode finds application in the context of active databases,
but fails to be of use here. Because of this, the traversal mode parameter will
not be implemented, and the filter will implicitly evaluate all instances from
left-to-right.
Figure 2.10: Traversing the event instance sequence from left to right (forward in time).
Figure 2.11: Traversing the event instance sequence from right to left (backwards in
time).
33. 2.2 Filtering Algorithm Parameter Investigation 17
2.2.3 Coupling Mode
The coupling mode, also referred to as the continuity mode [17], refers specif-
ically to the interruption of profile matches. This mode specifies whether
matches to specified profiles can be interrupted by events that are not related
to the specific profile currently being matched. A continuous coupling mode
enforces this restriction (no interruptions), whereas a non-continuous mode
allows matches to be interrupted [15].
2.2.4 Concurrency Mode
The concurrency mode determines whether or not the time intervals related to
complex matches are allowed to overlap each other. This mode defines whether
profile matches (also referred to component event instances) can overlap in
terms of occurrence time. Examples of time intervals that overlap can be
found in two different circumstances.
Circumstance one: This circumstance is outlined in Figure 2.13. This occurs
when an event (in this example, e3) matching a profile (P1) falls between the
initiator (the event instance that initiates/begins a match) and terminator
(the event instance that terminates/ends a match) (in this example, e1 and
e2 respectively) of another profile match (P2). If a complex profile (dubbed
P3) was defined as P3: =; (P1, P2), we discover that a match is able to
be made if the concurrency mode is set to overlapping. This is because the
event occurrence time of P1 occurs before the terminating event of P2. The
two profile matches are interleaved (one occurs during the occurrence of the
other). If the concurrency mode is set to non-overlapping, the match to P3
cannot be made.
Circumstance two: This example will use the same examples of user defined
profiles as was described in circumstance one. If the match to P1 occurs
Figure 2.12: The first situation in which concurrency occurs.
34. 18 Chapter 2 Background and Definitions
immediately before the initiator for P2 and the concurrency mode is set to
overlapping, a match to P3 can be found. This is because P3 requires the
time intervals of the two different profiles to overlap. Once again, the match
to P3 cannot be made if the concurrency mode is set to non-overlapping.
This is because although the events in each of the sub-profiles themselves do
not overlap, the time intervals associated with them do. This requires the
concurrency mode to allow such a match.
2.2.5 Consumption Mode
The consumption mode defines what happens to events after they have been
found to form a match to a profile. According to the consumption mode, the
event instances will either be recycled (to be used in another match) or deleted.
In the deletion of the event instances, there are two different cases. The first,
Exclusive Parameter, simply deletes the event instances used in matches. The
second mode, Exclusive, deletes both the event instances used in matches and
the ephemeral events that fall between the initiator and terminator of the
match. To reiterate the effects of these consumption modes, the definitions
are provided below.
Shared If the shared mode is chosen, no event instance is consumed in the
event of a match and all events may be reused.
Exclusive Parameter If the exclusive parameter mode is selected, the filter will
remove event instances as they are used in matches to user profiles.
Exclusive If the exclusive mode is selected, the initiator, terminator, and all
event instances in between are deleted after use.
2.3 Filter Combinations and Effects
To effectively communicate the possible combinations of the coupling, con-
currency and consumption modes, they will be separated into categories. The
Figure 2.13: The second situation in which concurrency occurs.
35. 2.3 Filter Combinations and Effects 19
duplicate selection mode is excluded in the following combinations as the inter-
actions it introduces are less complex than other filtering algorithm parameters.
However, it is included within the full plausibility table (Figure 2.24). Each
category will address the effects of a certain combination of settings for the
concurrency and coupling modes and how the consumption mode acts upon
them. Each mode will be provided alongside a graphical demonstration of the
filtering effect. Incompatibilities between filtering parameters are presented in
greater detail in Section 2.1.
Colored lines will specify groupings of events into profile matches. Each line
will run from the initiating event to the terminating event of the match. The
arrow head will point to the terminating event or event instance. The color
of the line will represent the profile matched. The profiles for the EIS to be
matched against are shown in Section 2.1.1. Single event instances that match
profiles will also be shown with a colored arrow pointing to the event instance,
but the arrow will not originate from another event instance. Crosses under-
neath events will represent the consumption of an instance. For simplicity
of understanding and to effectively express the functions of the modes being
investigated, the parameter selection mode of All will be used. These visual
aides are all shown in practice in Figure 2.18.
2.3.1 Continuous Coupling and Non-Overlapping
Concurrency
This configuration states that profile matches cannot occur concurrently and
that they may not be interrupted by other irrelevant event instances. Only
event instances that occur in the same sequence that is found in the profile are
to be considered valid matches.
Note that the configuration here means that the exclusive parameter consump-
tion mode found in Figure 2.15 and the exclusive consumption mode found in
Figure 2.16 provide the same function. This is because matches to user profiles
are restricted to being highly coupled (the events they require must occur in se-
quence without interruption). Because there are no interrupting events, there
is no extra functionality gained from using the exclusive consumption mode
over the exclusive parameter consumption mode. As the shared consumption
mode does not consume event instances, the function it provides differs from
the other two consumption modes, removing no events. This difference is
36. 20 Chapter 2 Background and Definitions
illustrated in Figure 2.14
2.3.2 Continuous Coupling and Overlapping Concurrency
This configuration states that matches cannot be interrupted by irrelevant
events, but they can occur concurrently. That is, a profile match may only be
interrupted by events related to event detection. The effect of this parameter
combination is shown in Figures 2.17 and 2.18.
The filter can not operate with this configuration in exclusive consumption
mode. This is because the consumption mode consumes matches and their
associated events, meaning they are no longer available for other matches. This
effect negates the overlapping concurrency mode, and hence this configuration
should not be available for the user to set. This fact is documented by Jung
and Hinze, “...an exclusive consumption mode is only logical in combination
with a non-overlapping concurrency” [12].
Figure 2.14: Shared consumption mode applied to continuous coupling, non-
overlapping concurrency and the parameter selection mode all. The pro-
files attempting to be matched are shown in Figures 2.3, 2.4 and 2.5.
Figure 2.15: Exclusive parameter consumption mode applied to continuous coupling,
non-overlapping concurrency and the parameter selection mode all. The
profiles attempting to be matched are shown in Figures 2.3, 2.4 and 2.5.
Figure 2.16: Exclusive consumption mode applied to continuous coupling, non-
overlapping concurrency and the parameter selection mode all. The pro-
files attempting to be matched are shown in Figures 2.3, 2.4 and 2.5.
37. 2.3 Filter Combinations and Effects 21
Figure 2.17: Shared consumption mode applied to continuous coupling, overlapping
concurrency and the parameter selection mode all. The profiles attempting
to be matched are shown in Figures 2.3, 2.4 and 2.5.
Figure 2.18: Exclusive parameter consumption mode applied to continuous coupling,
overlapping concurrency and the parameter selection mode all. The pro-
files attempting to be matched are shown in Figures 2.3, 2.4 and 2.5.
2.3.3 Non-Continuous Coupling and Non-Overlapping
Concurrency
This configuration states that matches can be interrupted by events unrelated
to event detection, but matches cannot occur concurrently. That is, the time
intervals associated with the event instances of different profiles may not over-
lap. The effect of this parameter combination is shown in Figures 2.19, 2.20
and 2.21.
Figure 2.19: Shared consumption mode applied to non-continuous coupling, non-
overlapping concurrency and the parameter selection mode all. The pro-
files attempting to be matched are shown in Figures 2.3, 2.4 and 2.5.
38. 22 Chapter 2 Background and Definitions
Figure 2.20: Exclusive parameter consumption mode applied to non-continuous cou-
pling, non-overlapping concurrency and the parameter selection mode all.
The profiles attempting to be matched are shown in Figures 2.3, 2.4 and
2.5.
Figure 2.21: Exclusive consumption mode applied to non-continuous coupling, non-
overlapping concurrency and the parameter selection mode all. The pro-
files attempting to be matched are shown in Figures 2.3, 2.4 and 2.5.
2.3.4 Non-Continuous Coupling and Overlapping
Concurrency
This configuration states that matches can be interrupted by events unre-
lated to event detection, and that matches can occur concurrently. That is,
a profile match may be interrupted by both irrelevant events and interleaved
complex match events. The effect of this parameter combination is shown in
Figures 2.22 and 2.23. Note that the exclusive parameter mode has precedency
over concurrency, preventing certain matches due to event removal.
This mode is the least restrictive mode in terms of coupling and concurrency
modes, and will provide the largest set of matches in terms of the restrictions
enforced by these parameters.
Once again, we notice the filter can not operate with this configuration in
exclusive consumption mode, as found in Section 2.3.2. The issue of the con-
sumption mode removing event instances that could be used to find matches
to profiles that occur concurrently means that this filter cannot be used in
exclusive consumption mode.
39. 2.4 Plausability Matrix 23
Figure 2.22: Shared consumption mode applied to non-continuous coupling, overlap-
ping concurrency and the parameter selection mode all. The profiles at-
tempting to be matched are shown in Figures 2.3, 2.4 and 2.5.
Figure 2.23: Exclusive parameter consumption mode applied to non-continuous cou-
pling, overlapping concurrency and the parameter selection mode all. The
profiles attempting to be matched are shown in Figures 2.3, 2.4 and 2.5.
2.4 Plausability Matrix
Table 2.1 is provided to aggregate and outline the plausibility of combinations
of the coupling, concurrency and consumption modes. A full table including
the parameter selection mode is available in Figure 2.24.
2.5 Review of the Interaction Between Parameter
Selection Modes and Coupling Modes
In addition to the parameter combinations presented in Table 2.1, there are
some parameter selection modes that are fundamentally incompatible with cer-
tain filtering algorithm parameter configurations. These incompatibilities are
apparent in Figure 2.24. To investigate these incompatibilities, the parameter
selection mode will be stated, then an explanation of which configurations fail
to work and the reasons why will be investigated. Explanations of the effects of
parameter selection and coupling configurations are explained in Sections 2.2.1
and 2.2.3 sections respectively.
40. 24 Chapter 2 Background and Definitions
Figure 2.24: Feasible table for all filtering algorithm parameters.
41. 2.5 Review of the Interaction Between Parameter Selection Modes and Coupling
Modes
25
Table 2.1: Plausibility matrix for filtering parameter combinations
Coupling Concurrency Consumption Plausibility Figure
Continuous Non-overlapping Shared Yes 2.14
Continuous Non-overlapping Parameter Yes 2.15
Continuous Non-overlapping Exclusive Yes 2.16
Continuous Overlapping Shared Yes 2.17
Continuous Overlapping Parameter Yes 2.18
Continuous Overlapping Exclusive No N/A
Non-continuous Non-overlapping Shared Yes 2.19
Non-continuous Non-overlapping Parameter Yes 2.20
Non-continuous Non-overlapping Exclusive Yes 2.21
Non-continuous Overlapping Shared Yes 2.22
Non-continuous Overlapping Parameter Yes 2.23
Non-continuous Overlapping Exclusive No N/A
A table of possible combinations of the coupling, concurrency and consumption filtering
parameters, whether they are plausible or not, and which figure they are represented in.
2.5.1 All
There are no specific incompatibilities stemming from the interaction of this
selection mode and other filtering parameters.
2.5.2 First
There are no specific incompatibilities from the use of this parameter selection
mode and the filtering parameters, though in some situations the continuous
coupling parameter can be rendered useless. This is because this mode restricts
the filter to only the first duplicate in a series of duplicates. The coupling mode
will work as desired when there is only one occurrence of an event followed by
an occurrence of a different event, and both are required for a profile match.
However, it will not work when there are duplicates of the first event.
2.5.3 Nth
The filter configuration of continuous coupling faces incompatibilities with the
parameter selection mode of ‘nth’ (assuming n>1). This is because the filter is
restricted to using only the specified duplicate of an event, which means there
needs to be n - 1 occurrences of the same event instance in sequence before
the event instance n can be used. Since this is true for both the initiator and
terminator, matches will include irrelevant events. This is a direct contradic-
42. 26 Chapter 2 Background and Definitions
tion to the continuous coupling mode, which states that matches are not to
be interrupted by irrelevant events. Therefore, if n>1, this configuration does
not work.
2.5.4 Last
This parameter selection mode faces the same sort of contradiction paradigm
as the previous example, but not in all cases. If two different events occur in
sequence, they are both considered the last of their sequence, so this parameter
selection mode does indeed work with continuous coupling.
2.6 Review of Incompatibilities Between the
Concurrency, Coupling and Consumption
Modes
The combination of non-continuous/continuous coupling and overlapping con-
currency is not compatible with the exclusive consumption mode, irregardless
of the parameter selection mode. As the overlapping concurrency mode is used
to enable matches to complex nested profiles, the exclusive consumption mode
introduces an incompatibility meaning a match will never be found. This is
because the sub-profiles of a complex nested profile are required to be matched
before a match to the complex nested profile is found. As the sub-profiles are
removed on a match due to the consumption mode, the complex nested profile
will never be successfully matched.
Other profile types, complex and simple, are able to operate with the incom-
patible set of filtering algorithm modes. However, in both of these cases, the
overlapping concurrency mode is not required. The filter will provide the same
functionality for both sets, regardless of the concurrency mode setting.
2.7 Default Settings
Unland and Zimmer specify their intended default settings for all filtering
parameters [17]. These settings must be identified in order to provide default
filtering algorithm parameter settings within the prototype application. This
43. 2.8 Specification of Implementation Restrictions 27
2.7.1 Coupling Mode
The default setting for the coupling (continuity) mode is non-continuous (matches
may be interrupted by irrelevant events).
2.7.2 Concurrency Mode
The default setting for the concurrency mode is overlapping (profile matches
may be interleaved by matches to other complex events).
2.7.3 Consumption Mode
The shared parameter should be set as the default option for the consumption
mode (event instances will not be deleted after use, and can be reused in
different matches).
2.7.4 Parameter Selection Mode
The parameter selection should default to ‘First’ (only the first duplicate of an
event will be chosen when a group of event instances of the same type occur
in succession).
2.8 Specification of Implementation Restrictions
During the investigation into how each of the different filtering parameters is
to operate within the completed filtering system, several restrictions have been
discovered. In order to provide the user with a functional system, incompatible
settings must be removed from the set of permissible parameter configurations.
According to the paper prototype outlining the user interface, users are able
to select the parameters for the event filter by modifying fields on a form,
for example either checking or un-checking a check-box, or selecting one of
multiple radio buttons. Each parameter for the filter has its own interface,
allowing each parameter to be changed individually.
To provide the functional system, the user must not be able to select parameter
configurations that create incompatibilities. The set of incompatibilities are
outlined in Section 2.1 and further explored in Section 2.6. Whenever the
exclusive consumption mode is set, the concurrency mode should be set to non-
overlapping. The user must not be able to select an overlapping concurrency
44. 28 Chapter 2 Background and Definitions
mode in this instance as exclusive consumption consumes the instances that
would be used to create overlapping matches.
If the shared or exclusive parameter modes are chosen, there should be no
restrictions placed on the combinations of coupling, parameter selection and
concurrency modes. However, if the exclusive consumption mode is chosen
in conjunction with the Nth parameter selection mode (assuming n >1) the
coupling mode should be set to non-continuous and the concurrency mode
should be set to non-overlapping. Likewise, the Nth parameter selection mode
should not be able to be chosen if the consumption mode is set to exclusive,
and coupling and concurrency modes differ from those given here.
All filtering parameters should be set to their default modes when the window
is opened for the first time. If the modes have been previously specified, the
form should remember and display the user specified configuration.
45. Chapter 3
Filtering Algorithm
To implement a system for setting the filtering algorithm parameters, a filtering
algorithm must first be developed. The filtering algorithm itself lies distinct
from the filtering algorithm parameters. This is because the filtering algo-
rithm parameters function as a configurable subset of the filtering algorithm
itself. Most filtering algorithm designs operate alone and are unparameteris-
able, using hard coded sets of parameters. However, the filtering algorithm
to be chosen for implementation within the software is required to be able to
facilitate the addition of the filtering algorithm parameters.
Several different existing filtering algorithms are investigated in this chapter.
Each algorithm is presented and analysed for suitability for implementation
within the software. A conclusion as to the chosen algorithm is given, with an
explanation for the motivation behind the decision.
3.1 Algorithm Research
Several key areas of concern have been outlined in Chapter 2.3 in order to fully
understand where the visual and functional constrictions of the algorithm lie.
Certain filtering parameters (such as the concurrency and coupling modes)
function in a more complex manner than others, and attention to detail in
these areas should be paid.
As interaction design is an iterative process, the event filter to be constructed
is for evaluation and testing purposes only. Testing in this case relates to the
usability of the application and the understanding of the underlying filtering
algorithm parameters. The stipulation of the implemented system is that it
46. 30 Chapter 3 Filtering Algorithm
is required to provide the correct set of matches, given the profiles and filter-
ing parameters. This requires a filtering algorithm to provide the matching
and filtering functionality of both the user profiles and the filtering algorithm
parameters.
For an algorithm to be acceptable for use in the system, it must allow for
the filtering parameters chosen to be evaluated against a given event instance
sequence (or be modifiable so that this may be achieved). Since the prototype
provides on demand modification to the filter parameters, the algorithm must
also not require a lot of time to operate. That is, users are to be able to modify
the filtering algorithm parameters with ease, and the modifications are applied
and displayed to the user instantaneously. However, since the filter will work
on a much smaller scale than what is possible in larger systems, this does not
pose a significant restriction.
As the proposed event filter operates with abstract data (in regards to the
highly granulated data able to be specified within commercial alerting sys-
tems), the filtering algorithm requires less extensive event checking than tra-
ditional implementations. For example, Jung’s software [10] allows users to
specify extremely specific data requirements within user profiles. This is not
a requirement of the prototype this investigation is concerned with. Instead,
users are able to specify abstract data requirements that require less process-
ing (checking for shape and color matches instead of textual data matching of
attribute/operation/value expressions).
Multiple different approaches to event filtering schemes exist that may be
appropriate for implementation in the system, such as Matching Trees as pre-
sented by Aguilera et al. [1] [7] and Binary Decision Diagrams as presented
by Campailla et al. [5]. Bittner and Hinze outline methods for non-canonical
filtering of events in publish/subscribe systems [3].
Concerns over time and space complexity for the event filter prove less im-
portant in this case, as the filter will deal with an extremely small number of
profiles in contrast to developed systems. That is, minimising intensive pro-
cessing in terms of time taken and memory used are not the main concerns
due to the nature of the data.
47. 3.1 Algorithm Research 31
3.1.1 Tree Matching
The tree matching algorithm is presented in depth by Aguilera et. al [1]. Al-
though presented in the context of content-based subscription systems, tree
matching finds application in matching events to a number of profiles [1].
Content-based subscription systems are a subset of alerting systems based on
the way filtering criteria can be specified across multiple dimensions. That
is, the content of each event is matched against the specification of each sub-
scriber. Because of these facts, tree matching is a suitable method for event
filtering in terms of the data required by the software.
Tree matching operates by pre-processing profiles into a matching tree. Profiles
are broken into logical test nodes (branching nodes) and result nodes (leaf
nodes). Branching nodes are logical actions that produce answers, and are
able to function as composite events [1]. Once profiles are processed, matching
can begin. The matching algorithm operates by walking the matching tree and
comparing the tests and results needed to satisfy profile matches against the
events in the event instance sequence [1]. A match to a composite event is found
if the filter reaches a terminal root node [7]. In the example given in Figure 3.1,
two profiles are specified. The branching node that begins the profile matching
examines the rainfall attribute. If the rainfall matches condition one (rainfall
< 50mm/h), matching continues down the left half of the tree by examining
the line of sight and temperature data. If the branching nodes are satisfied, a
match to profile one may be found. Likewise, if the rainfall matches condition
two (rainfall > 50mm/h), matching continues down the right half of the tree.
Again, if the branching nodes are satisfied, a match to profile two may be
found. To summarise, the two profiles held within the figure are:
• Rainfall < 50mm/h, Sight < 100m and Temp < 10 C.
• Rainfall > 50mm/h, Sight < 50m and Temp < 5 C.
The Tree Matching algorithm is suitable for implementation in the event filter
as it allows matching of events against specified profiles. Although it does not
natively work with the filtering paradigm specified, it can be modified to in-
corporate all filtering algorithm parameters specified. However, the Matching
Tree algorithm thrives in large sets of profiles, a situation that will not be
found within the prototype. This is because only one profile is designed to be
matched against at any one time. As only one profile is to be matched, there
48. 32 Chapter 3 Filtering Algorithm
Figure 3.1: A visual representation of a matching tree for use in the Tree Matching
algorithm.
will never be an event in which the matching tree will be used for matching
more than one branch at a time. For this reason, it may be less suitable than
other algorithms.
3.1.2 Binary Decision Diagrams
Binary Decision Diagrams (BDDs) are data structures that are especially useful
for representing boolean functions. The use of BDDs in terms of publish/sub-
scribe systems is presented by Campailla et al. [5], where they are described
as being used to match incoming messages against subscribers interests. This
is exactly the type of filtering that the prototype system logically requires. As
the EISs will be specified by the user, the prototype will not be receiving any
data but instead simulating the matches that would be found in the EIS had
occurred.
BDDs are built from terminal and non-terminal nodes, the former defining
whether a sequence matches a profile or not, and the latter managing the
sequence and flow of the diagram. Larger query BDDs can be built from
many smaller queries, allowing a single BBD to be used to find matches for
49. 3.1 Algorithm Research 33
all profiles [5]. This is shown in Figure 3.2. In this example, two profiles
are specified within the decision diagram. To find a match to a profile, one
would need either an event showing the wind speed to be over 80 kilometers
an hour, or an event showing the rainfall to be over 50 millimeters an hour.
These two events known as initiators, and are circled twice within the diagram.
The profile match would then also require the line of sight to be less than 100
meters, and the temperature to be under 10 degrees Centigrade. If an event
does not satisfy this requirement, there will be no match. Building the BDD
in this manner allows the formation of two different profiles while maximising
the re-use of nodes within the data structure. To summarise, the two profiles
held within the figure are:
• Wind > 80km/h, Temp < 10 C and Sight < 100m.
• Rain > 50mm/h, Temp < 10 C and Sight < 100m.
Although BDDs are intended to work with only boolean data (i.e. each query
can only have one of two outcomes, true or false) [5], this does not limit their
capabilities for event processing. BBDs are able to be expanded to handle
many different profiles in a single BBD. Although the example given by Cam-
pailla et al. evaluates strictly sterile data (only handles the event matching and
Figure 3.2: A binary decision diagram example. This binary decision diagram will return
a matching result if certain conditions that match moderate bad weather
are met.
50. 34 Chapter 3 Filtering Algorithm
does not feature filtering algorithm parameters), BBDs can be implemented
alongside other techniques to achieve the range of functions needed.
3.1.3 General Boolean Filtering Approach
Bittner and Hinze propose a filtering algorithm that avoids the need to convert
event profiles into their disjunctive normal forms (DNFs) [3]. The approach
they propose utilises Boolean expressions including variables and operators.
The operators they propose are limited to AND, OR and NOT. This filter
requires multiple different data types to work effectively. The range of data
types, from trees to arrays, is given in Figure 3.3. As the filter uses an ab-
stracted version of the complete set of specifiable events (Boolean operators
are provided within the wider prototype system, not in the filter), subscription
trees can be reduced to simpler sequences of event instances. Filtering events
follows several steps. The first step, known as predicate matching, determines
all predicates that match an event. This step produces a list of predicate iden-
tities (event instances within the EIS) that have returned matches. The second
step determines profiles (subscriptions) that contain at least one of the match-
ing predicates through the use of a predicate association table. The third step
evaluates those profiles and determines the matches that require subscribers to
be notified about. The subscription trees are accessed through a subscription
location table, which associates ids with profiles.
The main benefit of this algorithm is that the predicates are only evaluated
in the first stage. Because of the nature of the filter being implemented and
the associated requirements, this is a relatively superfluous measure. That is,
as the data used within the prototype system is limited to an abstract schema
of shapes and colours, predicate evaluation is simple. The software also does
not match any more than one profile at a time, removing BDDs benefit of the
ability to make matches to multiple user profiles concurrently. Modifications
to the BDD algorithm would be required to not only enable multiple matches
to a single profile to be found, but also to incorporate the filtering algorithm
parameters.
51. 3.2 Algorithm Discussion 35
Figure 3.3: A binary decision diagram example. This binary decision diagram will return
a matching result if certain conditions that match moderate bad weather
are met.
3.2 Algorithm Discussion
Any of the three investigated algorithms could have been modified in order to
satisfy the constraints of the proposed event filter. In terms of the requirements
for the project, it was necessary to judge whether it would be useful to utilise
one of the researched algorithms for use in the event filter, or if they fall out
of scope of the prototype.
Because of the abstract data requirement (geometric shapes and colours in-
stead of granular, textual data available in other systems [10]), there was a
lack of requirement for intensive processing. This meant that the algorithms
would be reduced to basic comparisons instead of contextual matching, negat-
ing one of the most important features of the given algorithms. Furthermore,
the researched algorithms were designed for matching multiple profiles at once,
a situation that will not be apparent in the prototype. None of the algorithms
presented a method for inclusion of filtering algorithm parameters. Because of
these reasons, a custom algorithm was chosen. In a similar manner to the algo-
52. 36 Chapter 3 Filtering Algorithm
rithm proposed by Bittner and Hinze [3], the custom algorithm is designed to
undergo preprocessing before intensive matching by gathering event instances
found within the given profile before matching the event specifics to the profile
itself.
3.3 Custom, Parameterised Event Filtering
Algorithm
I designed this custom algorithm to allow for parameterisation of the event
filter. The custom algorithm operates using one single profile. Multiple pro-
files may be specified and stored within the system at any given time, but
the algorithm operates on only a single specified profile. This is unlike the
researched algorithms that provide the ability to analyse multiple profiles at
once. The reason for this behavior is that the implementation is focused around
the ramifications of the filtering algorithm parameters; granular data require-
ment specification is unnecessary. The basic ability to specify custom profiles
satisfies all cases of filtering algorithm parameter interactions.
On execution, the algorithm begins by compiling a list of all events within the
current EIS that occur within the specified profile. If the profile has more than
one data item (it is not a simple profile), the algorithm compares all events
within their individual lists to all events found within other lists. If the events
fall within the temporal bounds of the profile (they do not occur out of order
within the EIS), they are added to a separate list of possible matches. This is
the extent of the preprocessing stage of the algorithm. If the profile consists
of a single data item, the matching is complete.
The matching stage of the algorithm for complex profiles accepts the prepro-
cessed list(s) of events. In the event of a complex nested profile, two lists are
generated (one for each sub-profile). The algorithm then performs another
sorting style matching step in a similar manner to the preprocessing stage.
However, in this stage the algorithm also takes into account the filtering al-
Figure 3.4: A user profile to explain the custom, parameterised event filtering algorithm
with.
53. 3.3 Custom, Parameterised Event Filtering Algorithm 37
Figure 3.5: The custom, parameterised event filtering algorithm developed for the soft-
ware prototype.
gorithm parameters as set by the user. These parameters are implemented as
logical rules defining whether or not the given combination is acceptable. If
the combination of events forming the current potential match violates any
of the specified logical rules as specified within the parameters the match is
instantly discarded. If the match does not violate the specified logical rules,
it is added to a list of acceptable matches. Once all cases have been analysed,
the matching is complete. The entire process is displayed in Figure 3.5, using
the profile given in Figure 3.4.
54.
55. Chapter 4
Software Implementation
4.1 Previous Research and Prototype
Previous research [16] in this domain had yielded an early prototype as seen
in Figure 4.1. However, this prototype lacked several key aspects. First and
foremost, the prototype was in no way functional; it existed simply as a static
Windows C# form application meant only for visualising the interface compo-
nents and general layout. The accompanying report also lacked any substantial
documentation as to the intended function of the completed application. In
this state, the prototype was inappropriate for implementation.
4.2 New Prototype
During the research phase, several issues with the prototype were discovered.
For example, the incompatibility between the consumption mode and the adja-
cency mode as investigated in Section 2.6 was not previously identified. These
discoveries, which were a pat of this project, were incorporated into a new
interaction design prototype which was developed by Dr. Doris Jung as seen
in Figures 4.2, 4.3 and 4.4.
This new version expanded upon the functionality of the early prototype [16].
New modules were designed to enable the user to specify custom event instance
sequences and user profiles, functions that were not apparent in the early
prototype. This added the flexibility required in order for users to explore
multiple combinations and filtering algorithm parameter effects. Other new
features included optional event numbering to aid in identification of event
instances.
56. 40 Chapter 4 Software Implementation
Figure 4.1: An early prototype of the proposed application [16].
Figure 4.2: The new prototype main screen.
57. 4.2 New Prototype 41
Figure 4.3: The new prototype filter specification screen.
58. 42 Chapter 4 Software Implementation
Figure 4.4: The new prototype data specification screen.
During preliminary conversations about the function of the profile specification
module, it was decided that the user would be able to nest many sub-profiles
into a much larger composite profile. This was one of the main reasons for
selecting a tree structure for representation of the profiles. However, during
the implementation, it became obvious that this was unnecessary; the ability
to create a single nested complex profile satisfied the requirement of displaying
the function of the affected algorithm parameters. Unfortunately, this realisa-
tion came late in the implementation phase and many functions were already
configured to use a tree structure. This complicated the internal workings
of the algorithm somewhat; an inheritance based data structure could have
simplified the process.
59. 4.2 New Prototype 43
4.2.1 Intended Function
The filtering algorithm parameters module within the new prototype gained
its intended functionality from the investigation in Section 2.3. The outcome
of the filtering algorithm parameter research not only defined the interactions
between the parameters themselves, but also played a significant part in how
the functionality underpinning the software was designed. This included guide-
lines for functionality in terms of user feedback, such as disabling controls that
would lead to incompatible combinations. By disabling certain controls in
given circumstances, the software prevents users from combining the exclu-
sive consumption mode with the concurrency mode. Such a combination has
underlying incompatibilities between the definitions of the filtering algorithm
parameters, and would result in no matches regardless of the inputs.
The function of the parameters also played a part in the match visualisation
scheme. Parameters such as the duplicate selection mode and concurrency
mode can provide a large number of matches (given the right conditions).
Several iterations of design were undertaken as prompted by both the author
and Dr Jung. Each iteration was evaluated as a team, and modifications were
agreed upon.
Expert review undertaken by Dr Jung included the input of the author, in
which the function of several features within the prototype were discussed.
As no strict function outline was provided to accompany the prototype, this
was helpful for both parties concerned. For example, the function of the ‘add’
button within the data creation window was discussed. This pertained to
whether the data item was prepended or appended to the data list. The
interaction design in this case was not definitively specified by Jung. During
the ensuing conversation, it was resolved that the new data event should be
appended to the list. This was because of the implied traversal mode within
the software. Other interactive functions defined during the expert review
include, but are not limited to:
• How data was to be provided to users within the filter specification win-
dow, and to what limit the user may be able to specify nested profiles.
• Whether or not there was a limit on the number of profiles in the software,
or whether there was a limit on the number of data items that could be
created.
60. 44 Chapter 4 Software Implementation
• How the windows should scroll when filled with content, and whether it
should scroll to show new additions that would otherwise be obscured
from view.
• What the ‘Advanced Profile Editor’ button represented (A link to an-
other piece of software more suited for granular profile definition [10]).
• What happened to data events when they were removed from the EIS
list.
• What functions the default data, filter and parameter buttons should
provide to the user (Default functionality for the filtering algorithm pa-
rameters is defined in Section 2.7).
4.3 Implemented Prototype
The implemented prototype combined the theoretical interactions and incom-
patibilities between filtering algorithm parameters defined and discovered in
Section 2.3 with both the interaction design investigated in Section 4.2 and
the algorithm presented in Section 3.3. This synthesis yielded a functional
prototype suitable for user testing.
Similar to the original prototype [16], the functional implementation was cre-
ated in Microsoft C#. This was a requirement in the event that further work
would link it to the profile specification application created by Jung [10].
4.3.1 Drawbacks
As mentioned in Section 4.2, the tree data structure proved to be a restrictive
choice, especially later in the implementation phase. Correctly managing com-
plex filtering was complicated further when faced with the differing structure
of the tree. During the implementation process, features previously unmen-
tioned in the paper prototype and associated design documents were raised and
implemented. Due to this, the code base required adaption and modification
in many areas. However, the software operated as intended, and without any
significant burden. A replacement data structure was designed but due to the
time limitations was not implemented. This is further discussed in Section 8.3.
61. 4.3 Implemented Prototype 45
Figure 4.5: The implemented program data specification screen
4.3.2 Modifications
One of the most striking modifications made to the prototype was the imple-
mentation of lines showing how each match is constructed from the individual
components within the data stream. Both the original paper prototype and
the new paper prototype lacked a mechanism to provide such feedback to the
user. Early implementations also lacked such a feature. However, in the test-
ing phase of the application the author identified the lack of such a feature to
be misleading, especially in the cases where multiple different matches were
made from the same subset of data from the same event instance sequence.
For example, two resultant EISs could show the same set of data as being used
within a match, but with no lines defining how the events were used in each
case, the matches were not easily identified. This happened with frequency in
cases that featured concurrency, and is shown in practice in Figure 4.8.
Different methods of showing the hierarchy were experimented with, including
using colors and different types of lines. However, the method shown in Fig-
ure 4.5 was chosen as it was the least visually cluttered and did not provide any
misleading information (which the colors were recognised to do). By drawing
62. 46 Chapter 4 Software Implementation
Figure 4.6: The implemented program filter specification screen
lines between each sub-profile and then linking the two, the issue of displaying
concurrent matches was resolved.
The filtering algorithm parameter terminology used within the software was
also modified from their original definitions. This was because the original
terminology was found to be confusing and misleading. Multiple discussions
were held between Dr Doris Jung and the author to resolve these names to
more appropriate terms. The modified terms are shown in Table 4.1.
63. 4.3 Implemented Prototype 47
Figure 4.7: The implemented program data specification screen
Figure 4.8: Showing the issue inherent in matching cases that feature concurrency.
64. 48 Chapter 4 Software Implementation
Table 4.1: Modified terminologies.
Original Name Software Name
Term
Parameter Selection Duplicates
Shared Consumption Share Data
Exclusive Parameter Consumption Remove Matched Data
Exclusive Consumption Remove Enclosed Data Too
Concurrency Concurrency
Coupling Adjacency
A table showing the terminology modified for use within the software.
65. Chapter 5
User Study Design
For the purposes of evaluation of the prototype, a user study was undertaken.
The study had two motivations and was designed with these in mind. Not
only was the usability of the implementation of interest, but measuring the
understanding of the underlying theoretical concepts was intriguing also. To
elicit results in these two areas, a combination of a set of tasks and several
surveys was produced.
In accordance with the University of Waikato guidelines for studies that in-
volve human participants, an application was lodged with the Human Re-
search Ethics Committee within the Faculty of Computing and Mathematical
Sciences. The application was approved by the Human Research Ethics Com-
mittee. The documents that were approved are shown in Appendix A.1, A.2,
A.3, A.4, A.5, A.6 and A.7.
5.1 Participant Groups
Participants within the study were divided into two main groups: those that
received the software as a supplementary tool for answering the tasks, and
those who did not. This allowed analysis into whether the software enabled
users to operate the filtering algorithm parameters more correctly than those
without the software. Within these two distinct groups, two other groupings
were made: those participants with formal logic experience, and those without.
This allowed analysis into whether formal logic experience affected task scores.
66. 50 Chapter 5 User Study Design
5.2 Tasks
Whilst in development, the tasks required several redesigns. This was because
the tasks were required to both enable the gathering of valuable information
but also be solvable by participants. Early designs proved too difficult in trial
tests, requiring questions to be rephrased and simplified and requirements for
each questions to be reduced. The final design for the tasks required the user
to practice manipulating a single filtering algorithm parameter while allowing
others to remain constant. In this way, the user was able to display how they
understood each mode to operate independent of others. Additional questions
required users to develop the most restrictive and least restrictive filtering sets
for a given EIS and data requirement. One question required the user to iden-
tify the incompatibility between the concurrency and exclusive consumption
modes. The task sheet is shown in Appendix A.4.
In order to assess the correctness of the answers given, an assessment guideline
had to be produced for each question. The difficulty in this came from the fact
that the answers given had the possibility of being correct but not complete.
5.3 Software Usability Survey
This survey required participants of the study to provide a retrospective ac-
count of their experience with the software. Early questions each focused on a
single aspect of the software, with later questions focusing on the experience
as a whole. This enabled further analysis into which areas of the software need
further development. This survey is shown in Appendix A.6.
5.4 Ease of Understanding Survey
This survey was created in order for participants to relay their perceived un-
derstanding of the theoretical concepts that underpinned the tasks. This was
important information as it enabled later analysis into not only the partici-
pant’s retrospective views on the information, but it also allowed analysis into
areas that participants had been mislead or simply failed to grasp the concept
in the intended manner. This survey is shown in Appendix A.5
67. 5.5 Participant Demographics Survey 51
5.5 Participant Demographics Survey
The participant demographics survey requested participants provide informa-
tion on their persons, such as age, experience with computers and formal logic,
and highest qualification achieved. This was gathered in order to form further
conclusions on the task results. This survey is shown in Appendix A.7
5.6 User Study Method
Participants of the study were provided with an information and consent form
that explained the research and their rights should they choose to participate.
Prior, informed and expressed consent was obtained from the participants
in every circumstance before any information was taken. Once consent was
gained, the participants were verbally introduced to alerting systems, profile
specification and event filtering algorithm parameters. All participants were
given a sheet of paper explaining filtering algorithm parameters and profiles,
while half of the participants were also provided with the software. The soft-
ware was installed on a University of Waikato computer within the Usability
Laboratory.
The participants were then given the test sheet, and were observed whilst they
completed it. On the completion of the test, the participants were provided
with the survey forms. The ease of understanding survey and a participant
demographics survey were given to all participants while the software usability
survey was given to only those that were provided with the software.
68.
69. Chapter 6
User Study Results
6.1 Participants
A total of ten participants were recruited for the user study, in which the
average participant was a current University of Waikato student, male, 20 years
old, and held NCEA Level 3. The participants were separated into two groups,
those that were provided with the software, and those that were not. Half of
the participants within the study also had a reasonable level of formal logic
experience (rated themselves moderately experienced or more). Likert scales
were provided within the participant demographics survey in order to gather
this data. Due to the fact that the software and non-software groups were
uneven, the distribution of participants with formal logic experience within
each group was also uneven.
Table 6.1: Participant groups
Participant ID Software group? Formal logic experience?
1 Yes Yes
2 Yes No
3 No No
4 No No
5 No Yes
6 Yes Yes
7 Yes No
8 No Yes
9 Yes Yes
10 No No
The distribution of participants with or without formal logic experience in each of the
software and non-software groups.
70. 54 Chapter 6 User Study Results
6.2 Task Results
Because of the nature of the questions being asked, it was possible that many
of the questions posed to participants within the tasks could be answered
correctly, but not completely. That is, it is possible that a response could be
correct in that it provides a true answer (such as a match to a profile), but
can also be incomplete in that there are other parts to the answer that have
not been stated or have been stated incorrectly (such when not all matches
to a profile are included). Because of this, it was decided that a question is
only to be accepted if the answer given was both correct and complete. One
can effectively describe this concept by using the EIS and profile as shown in
Figures 6.1 and 6.2.
• Correct and Complete Answer
By taking these two components with the duplicate selection mode of
first, the shared consumption mode, non-enforced adjacency and allowed
concurrency, a total of five matches can be found. A model example of
a correct and complete model for this task is shown in Figure 6.3.
• Correct but Incomplete Answer
A model that includes a subset of the possible answers is shown in Fig-
ure 6.4. This model can be considered correct but not complete as the
matches that are specified are correct, but not all matches are shown.
6.2.1 Results for the Non-Software Group Participants
In general, the participants within the non-software group made errors in sim-
ilar questions. For example, all participants in the non-software group demon-
strated an incomplete understanding of use of the duplicate mode parameter,
Figure 6.1: The event instance sequence (EIS) that will be used to visualise the filter
effects on data.
Figure 6.2: This profile, entitled P1, specifies a simple sequence of a event e1 (a circle)
followed by an event e2 (a square).
71. 6.2 Task Results 55
Figure 6.3: A correct and complete model using the duplicate selection mode of first,
the shared consumption mode, non-enforced adjacency and allowed concur-
rency.
Figure 6.4: A correct and complete model using the duplicate selection mode of first,
the shared consumption mode, non-enforced adjacency and allowed concur-
rency.
resulting in no participants providing a correct and complete answer for ques-
tions 1A and 1B, shown in the task sheet in Appendix A.4. The results for
each participant are shown in Table 6.2. The average score in the non-software
group was 5.4 out of a possible 12. Participants scored a combined total of 27
correct and complete answers out of a possible total of 60, 45% of the total
possible score. This is shown in Figure 6.5.
Table 6.2: Result summary for participants in the non-software group.
Tasks
1A 1B 1C 2A 2B 2C 3 4A 4B 4C 5 6
ID Number
3 N N Y Y Y N N Y N Y N Y
4 N N Y Y Y N N Y N Y Y Y
5 N N Y Y Y N N Y N Y Y Y
8 N N N N Y N N Y N N N N
10 N N Y Y N N N Y Y Y N N
A table showing the task results for individual participants from within the user study
task.These participants were in the non-software group. A ‘Y’ signifies a question was
answered correctly and completely.
