\documentclass{article}[11pt]
\setlength{\topmargin}{-2cm}
\setlength{\textheight}{24cm}
\setlength{\oddsidemargin}{10mm}
\setlength{\evensidemargin}{10mm}
\setlength{\textwidth}{15cm}
\setlength{\parskip}{3mm}
\setlength{\parindent}{0mm}

\usepackage{epsfig}
\usepackage{comment}
\usepackage{graphics}
\usepackage{graphicx}
\usepackage{hyperref}
\usepackage{times}
\usepackage[authoryear,round]{natbib}
\usepackage{subfigure}

\newcommand{\Rfunction}[1]{{\textsf{#1}}}
\newcommand{\Robject}[1]{{\texttt{#1}}}
\newcommand{\Rpackage}[1]{{\textit{#1}}}
\newcommand{\Rslot}[1]{\textsl{#1}}
\newcommand{\Rclass}[1]{\texttt{#1}}
\renewcommand{\baselinestretch}{1.5}

\begin{document}

\bibliographystyle{amsplain}

\author{Elizabeth Whalen\\Harvard School of Public Health}
\title{Generalizing the Model View Controller Paradigm}

\maketitle

\begin{abstract} 
  In this paper we consider a generalization of the model
  view controller (MVC) paradigm to allow for more flexible handling
  of submodels.  Instead of using a single MVC we develop a tree
  structure of related MVCs, where each MVC has a single parent, but a
  parent can spawn many different child MVCs.  Communication between
  parent and child MVCs allows for very flexible linking of the
  MVCs.  We provide an implementation of our work in the R package
  \Rpackage{MVCClass} available at \url{http://www.bioconductor.org}. 
\end{abstract}


\section{Introduction}\label{Sec:Intro}

\subsection{Background}\label{Ssec:Backg}

There are many ways to visualize multivariate data where more than
two or three dimensions are needed to view the data.  Several of these ideas
were discussed in previous work \cite{EW05}, so the focus in this paper
is on one specific method of visualizing multivariate data that is
particularly useful for exploratory data analysis; creating linked,
interactive views of linked data sets.  

First definitions of linked views, interactive views and linked data
sets are given in the following paragraphs.  Linked views mean that if a
component that represents data (such as a point on a plot or a row in a
spreadsheet) changes its appearance on one view, then the corresponding
component on a second view also changes its appearance.  For components on
different views to be corresponding, the data displayed in those components
must come from the same entity in a model.  As an example, suppose that the
model consists of the gene expression levels from four samples.  If the same
one hundred genes are studied in the four samples, then the model could be
represented as a matrix of four columns by one hundred rows with four columns
for the four samples and one hundred rows for the one hundred genes.  In this
model, the entities are the genes.  If two scatter plots are created as views
of this model, where the first plot displays sample one versus sample two and
the second plot displays sample three versus sample four, then the points on
each plot that referred to the same gene are corresponding components.  Linked
views, which have a long history in statistics, are now considered a standard
feature of interactive data visualization software \cite{GGobi}.  Linked views
have been implemented in several pieces of statistical software, such as
XLisp-Stat \cite{Lisp} and GGobi \cite{GGobiMan}.  Implementing linked views
is based on the model-view-controller (MVC) design \cite{DesignPatterns},
which is a widely used and well understood paradigm.  The MVC design is
discussed in more detail in Section \ref{Ssec:Design}.

Interactivity is an idea that is familiar from using an Internet browser.
Clicking on a hyperlink on a web page results in a new web page
opening.  Another example is clicking on the login button after entering a
user name and password to view one's email.  Interactivity means that there is
a response to some user action.  It is a powerful paradigm and allows users to
quickly navigate and explore complex documents or complex data sets.  As an
example, suppose that a user has two views: one view is a graph representing
the molecular function of genes and the other view is a heatmap of gene
expression data.  If the user clicks on a node that represents a particular
molecular function, then the response to this action could be to highlight all
genes in the heatmap view that correspond to this molecular function.  This
interactivity allows the user to quickly see if genes with the same molecular
function have similar expression levels. 

One particular model for creating interactive applications involves three
components: some user action or input, which is referred to as an event;
a response to that action, which is executed by a function that is called
a callback function; and a method that connects the event to the callback
function, which is referred to as the signal handler.  The events can
range from the user moving the cursor over a plot, to pressing a button on a
graphical user interface (GUI), to pressing certain keys.  Events are
interpreted based on which window has focus.  For example, in the XWindows
system, if a user types C on the keyboard and the window that has focus is a
text editor, then the letter C is printed on the text editor's screen.
Any other open windows that do not have focus do not respond to this event.
The callback function is a unique function because its signature is determined
by the event that the callback function is linked to.  The parameters passed
to the callback function may include information about the event, such as the
on screen location of the event, and information about the object that had
focus when the event occurred, such as a button on the GUI.  The signal
handler is the piece that must look to see if an event has occurred and then
when the event has occurred, the signal handler calls the appropriate callback
function. 

The strengths of this model of interactivity are that programmers can decide
which events to react to by deciding which signal handlers to implement,
programmers can change the response to an event by changing the callback
function that is linked to an event, and the system's event loop can continue
working on other things until a signal is emitted when an event occurs.  A
system's event loop controls how work is processed.  The event loop checks for
work to do and handles that work.  In the model of interactivity described
above when a signal handler is implemented by the programmer, this results in
the event loop periodically checking to see if an event has occurred.  Thus,
the event loop can perform other work and then check back to see if an event
has occurred.

These three pieces in this model of interactivity are ordered as follows:
an event occurs, the event causes a signal to be emitted that is caught by the
signal handler, and then the signal handler calls the callback function, which
results in the response to the user action.  A flowchart of these steps is
shown below in Figure \ref{Fig:Event}.  In the example of clicking on a
hyperlink mentioned above, the event is the user clicking on the
hyperlink and the callback function causes a new web page to open.
The signal handler, which is the method that connects the event to the
callback function, is handled by the system's event loop when a signal is
emitted. 

\begin{figure}[!h]
  \begin{center}    
    \scalebox{0.55}{\includegraphics{Event.jpg}}
    \caption{ Flow Chart of the Response to an Event. }
    \label{Fig:Event}
  \end{center}
\end{figure}

Linked data sets mean that the data have more than one conceptual grouping,
but there is a relationship between these different conceptual groupings.
Linked data sets are an idea that is familiar to users of relational
databases.  Data in a relational database are typically stored in many
linked tables with rows in different tables linked to each other through a
unique identifier called a key.  In this example, each table is
considered a data set and they are linked through the keys.  Another situation
where linked data sets occur is when there is experimental or study data that
are linked to meta-data.  An example of this situation is given in Section
\ref{Ssec:Limit} where the experimental data are microarray data, which looks
at gene expression levels, and the meta-data are a Gene Ontology graph that
gives the molecular functions of the genes studied in the microarray
experiment.  

Creating linked, interactive views of data is flexible for exploring
multivariate data because many different views can be created, such as
scatter plots, spreadsheets, and heatmaps, and these views are linked because
they are based on the same underlying data.  Thus, users can decide which
views best visually represent their data.  Also, since the views are
interactive, users can change the views while looking at them to make the
views more informative about the underlying structure in the data.  This
flexibility in linked, interactive views gives users a powerful tool for
visually exploring their data.  However, linked views can not solve all
problems.  Clearly, only a few linked views can be viewed simultaneously by
the user because only a certain number of views can be shown on a computer
screen.  Thus, there is a limit to the number of dimensions that can be
represented by linked views. 

As a motivating example of linked views based on linked data sets, consider
Figure \ref{Fig:firstMP}.  In this figure, there are two views, one view of
data set 1 and one view of data set 2.  Data set 1 and data set 2 are linked.
When a user initially interacts with the scatter plot view of data set 2, the
response to this interaction is to tell data set 2 to update itself (this is
indicated on the figure as a circled 1).  Then in Step 2, data set 2 tells the
scatter plot view that is should update itself in response to the change in the
data.  Next, in Step 3, because data set 2 has changed and because it is
linked to data set 1, data set 2 sends information to data set 1 about the
change.  In Step 4, the information from data set 2 is converted into
information that data set 1 can understand.  In Step 5, this information is
received by data set 1 and data set 1 updates its data.  Finally, in Step 6,
data set 1 tells its view to update itself.  This example shows the components
and the communication between the components that are necessary to create
linked views of underlying linked data sets.  

In the design presented in this paper, the components consist of \Robject{MVC}
objects and communication within and between \Robject{MVC} objects is
performed by message objects.  This solution uses the power and simplicity of
the MVC design and expands it to the multiple data set problem.  Now we can
build on the original MVC design, which has been well tested, instead of
starting a new design from scratch.  The strength of this multiple linked MVC
design is that it uses MVC components, which can be individually created and
then linked.  Thus, these components are reusable.  These design decisions are
discussed further in Sections \ref{Sec:OneMVC} and \ref{Sec:MultMVC}. 

\begin{figure}[ht]
  \begin{center}
    \scalebox{0.55}{\includegraphics{firstMessagePassing.jpg}}
    \caption{ Linked views of linked Data Sets.  When a user interacts with
      the y versus x scatter plot, the first step, indicated by a circled one,
      is to tell data set 2 to update.  Then all views of data set 2 must be
      updated.  Next any data that are linked to data set 2 must be notified
      that data set 2 changed.  This information from data set 2 must be
      altered so that it can be understood by linked data sets, which is shown
      in the fourth step.  Finally, data set 1 is notified that it should
      update in response to the change in data set 2 and then all views of
      data set 1 are updated. }
    \label{Fig:firstMP}
  \end{center}
\end{figure}

In Section \ref{Ssec:Design}, the design of linked, interactive views based on
the MVC paradigm is discussed.  However, the limitation with this design is
that it expects one data set, which limits the type of data we can visualize.
There are many situations where multiple data sets occur, particularly any
time there are experimental or study data linked to meta-data.  Being able to
visualize data from multiple data sets is helpful to understand the
relationships between variables.  Thus, after discussing the limitations of
the MVC design in Section \ref{Ssec:Limit}, an extension of the MVC design is
discussed in Section \ref{Sec:Extend}.  This extension supports the creation of
linked \Robject{MVC} objects.  The design of individual \Robject{MVC} objects
is discussed in 
Section \ref{Sec:OneMVC} while the implementation of linked \Robject{MVC}
objects is discussed in Section \ref{Sec:MultMVC}.  The goals of the software
discussed in this paper are to create linked views of linked data sets, to
create interactive views where the response to an event can be changed, and to
create an extensible design that allows future users to make additions.

\subsection{Design and Implementation of Linked, Interactive
  Views}\label{Ssec:Design} 

Focusing on linked, interactive views as a powerful visualization tool, the
next step is to determine how to design a software package that can implement
this method.  A popular design for creating linked views of data is the
MVC paradigm.  This design consists of three types of objects: the controller,
which defines what actions occur in response to user input; the view, which
consists of displays of the data; and the model, which manages the data.  This
paradigm is powerful because it decouples the views from the model.  Thus,
only one copy of the data needs to be stored and then all views refer to this
data set.  With all views based on the same data, any changes to the data can
be propagated to all views, which creates linked views. 

To link the views to this one data set there is a subscribe/notify procedure
between the views and the model.  The views subscribe to a particular model
and the model must notify the views when a change occurs so that the views
are updated.  This design allows multiple views of the model that are
linked, but are not aware of each other, as shown in Figure \ref{Fig:ExMVC}.
Each view is responsible for visually representing some aspect of the model
and thus, it is not necessary for a view to be aware of other views.  By
keeping each view ignorant of other views, views can added and removed without
affecting each other. 

\begin{figure}[ht]
  \begin{center}
    \scalebox{0.5}{\includegraphics{ExMVC.jpg}}
    \caption{ A Model with its Views. }
    \label{Fig:ExMVC}
  \end{center}
\end{figure}

Notice that although the components (model, view, and controller) in the MVC
design are independent of one other, there needs to be communication
between them so that information can be shared.  Examples of this
communication between components include the model notifying views that the
data have changed, a view asking the controller how it should respond to user
interaction, and a view telling the model that the data should change in
response to user interaction with the view.  This message passing between
components in the MVC paradigm is discussed in detail in Section
\ref{Ssec:OneMess}.   

In \cite{EW05}, we discuss the creation of R software to fulfill three goals:
to create views that are linked, to create views that are interactive, and to
create a design that is extensible.  To satisfy the overall goals of the
design, two R packages, called \Rpackage{MVCClass} and \Rpackage{iSPlot},
were created.  The \Rpackage{MVCClass} package implements the class and
generic function definitions needed for the MVC design and the
\Rpackage{iSPlot} package creates the front end to let the user create linked,
interactive views of two-dimensional data, such as data frames and matrices,
through a GUI or through command line functions.  The reason for
separating the software into two packages was that it allowed the class
definitions in the \Rpackage{MVCClass} package to be used by any other R
package that wanted to create linked views. 

\subsection{Limitations of the MVC Design}\label{Ssec:Limit}

The MVC design assumes that there is one data set, which is called the model,
that all views reference.  But problems arise when the data consist of more
than one conceptual grouping.  For example, consider data stored in a
relational database, where there are multiple tables of data and rows in
different tables are linked through a unique identifier called a key.
Although these tables of data could be combined into one large table, there
are several reasons not to do this.  Keeping the data in separate tables
reduces redundancy, particularly when the rows are related by a one-to-many or
a many-to-many relationship.  Also separate data tables generally lead to more
maintainable data.  By storing only one copy of each piece of information (in
a row in one table), it is easier to ensure that the data are correctly
updated when a change occurs.  All other tables that are connected with this
information can then just reference this row that has been updated. 

Consider Figure \ref{Fig:DBTab} shown below.  Here the database consists of
three tables, State, City and StateCity.  The State table has three columns,
State (the key), Life Expectancy, and Income.  The City table has three
columns, City (the key), Precipitation, and Temperature.  The StateCity table
has two columns, State and City.  This last table relates which cities are in
which states.  In this example, each city can be in only one state, but each
state can have more than one city so there is a one-to-many relationship
between states and cities.

\begin{figure}[ht]
  \begin{center}
    \scalebox{0.5}{\includegraphics{newDatabaseTables.jpg}}
    \caption{ Example of Relational Database Tables. }
    \label{Fig:DBTab}
  \end{center}
\end{figure}

Clearly, this information could be combined into one large table, called
CombinedStateCity, as shown in Figure \ref{Fig:OneDBTab}.  The
CombinedStateCity table has the following columns: State, Life
Expectancy, Income, City, Precipitation, and Temperature.  Now if a state's
life expectancy changes, all instances of this state need to change
in the new large table.  For example, if the state had the information for
three cities recorded, then the state has three rows in the
CombinedStateCity table and each row needs to change the value for the
state's life expectancy.  If instead only one record was kept per state, as
shown in Figure \ref{Fig:DBTab} above, then this process is less error
prone and requires less memory to store the data.  Another consideration in
combining data sets is that it may give the appearance of a relationship
between variables that does not exist.  For example, it may not make sense to
compare the Income data stored in the State table to the Precipitation data
stored in the City table.  Combining the data tables assumes that there is a
relationship between the variables in all of the tables.  This example shows
that there are advantages to storing the data in separate structures.

\begin{figure}[ht]
  \begin{center}
    \scalebox{0.5}{\includegraphics{newOneDatabaseTable.jpg}}
    \caption{ Example of a Combined Table. }
    \label{Fig:OneDBTab}
  \end{center}
\end{figure}

In a relational database all of the data are stored in tables, but consider the
situation where there are multiple data sets that are of different data
structures.  For example, suppose that you have experimental microarray data,
which look at gene expression levels.  This experimental data can be
stored as a two dimensional data structure, such as a matrix, where rows are
genes and columns are samples.  Linked to this experimental data are meta-data
that give information about the genes studied in the microarray experiment.
For example, this meta-data may be terms from Gene Ontology, which form a
directed acyclic graph, describing the molecular functions carried out by
these genes.  These two data sets (the experimental data and the meta-data)
are linked through the genes.  Each gene can have more than one molecular
function and each molecular function can have more than one gene annotated at
that function so there is a many-to-many relationship between the genes and
the molecular functions.  Though these two data sets are linked, the
microarray data and the Gene Ontology data are different data structures.   

Now for the original MVC design, where one data set is expected, it is not
clear how to combine these two data sets into one data set.  The meta-data
graph could be stored as a matrix, but a graph is a data structure that can be
well represented as an object with slots for nodes and edges, especially if
the graph is sparse.  As with relational database tables, combining the data
sets complicates data storage, alteration, and retrieval.  For example, by
combining the data sets a structure may be forced on the data that may not fit
well, especially if the original data sets are instances of different classes.
In contrast, keeping the data sets stored separately in their original
structures simplifies the processes of storing, updating, and accessing the
data.   

\section{Extending the MVC Design}\label{Sec:Extend}

As discussed in Section \ref{Sec:Intro}, the MVC design typically uses a single
conceptual unit, such as a data frame or a matrix, for the model.  In Section
\ref{Ssec:Limit} we provided several examples where it is advantageous to link
multiple data sets.  These examples included linked tables in relational
databases and experimental data linked to meta-data.  Being able to visualize
variables simultaneously from different data sets that are linked is useful for
exploring relationships between these variables.  We next describe how the MVC
design can be revised and extended to accommodate multiple data sets. 

\subsection{One Large Data Set}\label{Ssec:OneDS}

One possibility for dealing with multiple data sets within the MVC design is to
combine the multiple data sets into one large data set.  With this new
combined data, the original MVC design can be used to create linked views.

Unfortunately, as discussed in Section \ref{Ssec:Limit}, combining
multiple data sets into one large data set can be problematic.  Even if the
multiple data sets have the same data structure, combining the data sets often
results in redundant data and makes updating and representing the
data more complicated.  In the situation where the data sets do not have the
same structure, it may be necessary to define a new class to appropriately
represent the combined data.  Also, combining the data into one data structure
may give the appearance that some variables have a relationship that does not
exist.  Just because two data sets are linked does not necessarily mean that
there is a meaningful relationship between their data.  Thus, another way
of linking views based on multiple data sets needs to be designed. 

\subsection{Multiple MVC Objects}\label{Ssec:MMVC}

A more straightforward approach may be to link \Robject{MVCs}.  Each
\Robject{MVC} is a coherent object and the interactions between \Robject{MVCs}
are encapsulated in a set of messages.  We use one \Robject{MVC} object to
handle each data set.  Thus, within a \Robject{MVC} object, one can create
linked views of that particular data set, using the standard MVC design.  But
between \Robject{MVC} objects we design a second messaging system so that a
change in one data set is sent to the other linked data sets. 

\small
\begin{tabular}[t]{ | l | r | r | }
  \hline
  State & Life Expectancy & Income \\ \hline
  Pennsylvania & 70.43 & 4449 \\ \hline
  California & 71.71 & 5114 \\ \hline
  Minnesota & 72.96 & 4675 \\ \hline
\end{tabular}
\hspace{10pt}
\begin{tabular}[t]{ | l | r | r | }
  \hline
  City & Precipitation & Temperature \\ \hline
  Philadelphia & 39.9 & 39 \\ \hline
  Pittsburgh & 36.2 & 37 \\ \hline
  Los Angeles & 14.0 & 68 \\ \hline
  San Francisco & 20.7 & 56 \\ \hline
  Sacramento & 17.2 & 55 \\ \hline
  Duluth & 30.2 & 18 \\ \hline
  Minneapolis St. Paul & 25.9 & 22 \\ \hline
\end{tabular}

\begin{table}[h]
  \begin{center}
    \begin{tabular}{ | r | r | }
      \hline
      State & City \\ \hline
      Pennsylvania & Philadelphia \\ \hline
      Pennsylvania & Pittsburgh \\ \hline
      California & Los Angeles \\ \hline
      California & San Francisco \\ \hline
      California & Sacramento \\ \hline
      Minnesota & Duluth \\ \hline
      Minnesota & Minneapolis St. Paul \\ \hline
    \end{tabular}
    \caption{State and City Values.}\label{Tab:CityState}
  \end{center}
\end{table}

\normalsize
As an example, suppose that one has two data sets: one with information at the
state level and one with information at the city level.  These tables are
shown in Table \ref{Tab:CityState}.  The State data include Life Expectancy
(in years from 1970) and Income (per capita from 1974) data
while the City data include Precipitation (in inches from 1975) and Average
High Temperature in January (in Fahrenheit from 2005)
data.  These two data sets are linked by the StateCity table that links cities
with the states they reside in.  Now for these two data sets there are
two \Robject{MVC} objects.  One \Robject{MVC} object for the State data and
its views and one \Robject{MVC} object for the City data and its views. 

\begin{figure}[ht]
  \begin{center}
    \scalebox{0.7}{\includegraphics{MultipleMVC.jpg}}
    \caption{ Example of Two \Robject{MVC} Objects.  These two \Robject{MVC}
      objects are linked by the StateCity table and the color of the points
    indicates the linking between the data.  The points referring to the state
    of Pennsylvania are red, the points referring to the state of California
    are blue, and the points referring to Minnesota are green. }
    \label{Fig:MultMVC}
  \end{center}
\end{figure}

Figure \ref{Fig:MultMVC} shows one view for the State data and one view
for the City data.  You can see how the State and City data are linked based
on the coloring of the points in the plots.  The points referring to the state
of Pennsylvania are red, the points referring to California are blue, and the
points referring to Minnesota are green.  Even though there are two
\Robject{MVC} objects here, with one \Robject{MVC} object for each data set,
it is still clear that the views are linked through the data sets and that is
shown in this example through the coloring.

Not only does this solution use the power and simplicity of the MVC design, but
this multiple MVC design is structured to fit the linking seen in the multiple
data sets.  Clearly, the design should be built around the problem and
multiple \Robject{MVC} objects with messaging between the \Robject{MVC}
objects fits the problem of creating linked views of multiple linked data
sets.  In designing an appropriate messaging system between \Robject{MVC}
objects, consideration is given to what information should pass between
\Robject{MVC} objects and to how messages propagate between \Robject{MVC}
objects.  As for the relationship between the \Robject{MVC} objects, it should
reflect the relationship between the data sets. 

Although two examples of linked data sets have been discussed thus far,
this paper focuses on experimental data that are linked to meta-data, as
the data we are most interested in visualizing.  In this situation, the
experimental data can be thought of as determining what meta-data are studied.
In the example of microarray experiment data linked to Gene Ontology
meta-data, only Gene Ontology data that refer to genes in the microarray
experiment are included in the meta-data.  Thus, there is a hierarchical
relationship between these data sets and the \Robject{MVC} objects that
contain them, where one \Robject{MVC} object creates another \Robject{MVC}
object.  The original \Robject{MVC} object is the parent \Robject{MVC} and the
new \Robject{MVC} object that is created from the parent \Robject{MVC} is the
child \Robject{MVC}.  These decisions are discussed in the following sections
as the design for multiple \Robject{MVC} objects is explained. 

\section{Design Details of One MVC Object}\label{Sec:OneMVC}

\subsection{Implementation Details}\label{SSec:OneOver}

Implementing linked, interactive views of linked data sets is done using an
object-oriented programming design for extensibility.  The \Rpackage{MVCClass}
package implements the design of the MVC classes and generic functions.  The
\Rpackage{MVCClass} package defines the individual model,
view, and controller classes as well as the \Rclass{MVC}
class that binds the individual model, view, and
controller classes together into one unit.  The package also defines
the message classes that allow the components to communicate with
each other.  Thus, the \Rpackage{MVCClass} package contains the classes
necessary for creating linked views.   The goal of placing these class and
generic function definitions into one package is that they are available for
other R packages that implement linked views of data, such as the
\Rpackage{iSPlot} and the \Rpackage{iSNetwork} packages. 

With the class definitions created in the \Rpackage{MVCClass} package, the
\Rpackage{iSNetwork} package can decide which classes from \Rpackage{MVCClass}
to use based on the overall goals of the combined software.  The
\Rpackage{iSNetwork} package also determines how instances of these classes
behave because the methods for the classes are defined in the
\Rpackage{iSNetwork} package.  In addition to implementing the behavior of
objects, the \Rpackage{iSNetwork} package also creates a graphical user
interface (GUI) so that users can load data, create views, and interact with
the views through menus on the user interface.  As an alternative to the GUI,
users also have access to the same functionality through command line
functions.  

To create the GUI, \Rpackage{iSNetwork} uses the R packages,
\Rpackage{RGtk} and \Rpackage{gtkDevice}.  \Rpackage{RGtk} is an R package
that allows one to interact with Gtk functions from the R interface.  Gtk is
an open-source X Window toolkit \cite{Gtk} for creating user interfaces.  The
\Rpackage{gtkDevice} package creates a Gtk device by turning a Gtk drawing
area into a device that acts like an R device, but still responds to events so
that the view can be interactive.  For more information about these packages,
see \cite{EW05}.  

The next subsections explain the class definitions and the methods that
pertain to a single \Robject{MVC} object.  Thus, the model classes,
the view classes, the controller, the \Rclass{MVC} class
(which binds the model, view and controller classes
together), and the message classes that pass information between the
three components in one \Robject{MVC} object are discussed in the following
subsections.  All of the class definitions are implemented in the
\Rpackage{MVCClass} package and all of the methods are defined in the
\Rpackage{iSNetwork} package.  Message class definitions that pertain
to communication between the \Robject{MVC} objects are discussed in Section
\ref{Sec:MultMVC}. 

\subsection{Model}\label{Ssec:OneModel}

In the MVC design, the model component is the place where data are stored and
updated.  Thus, the model is a storage location that can perform certain
operations.  Information can be sent to the model to add, update, and remove
data and the model can send out messages that changes have occurred to the
data that the model stores.  Thus, the object model for the model
classes represents both the slots that are needed to store data and the
methods that are needed to perform the operations of the model. 

Figure \ref{Fig:Model} shows the inheritance structure for the model
classes. Here the virtual class, \Rclass{gModel}, has the slots
\Rslot{modelData}, \Rslot{linkData}, \Rslot{virtualData}, and
\Rslot{modelName}.  These four slots are common information that all models
need to store.  The \Rslot{modelData} slot is the data set for this model, the
\Rslot{linkData} slot is a list of two functions, \Rfunction{toParent} and
\Rfunction{fromParent}, which let this model send information to its parent
model and receive information from its parent model, respectively (see
Sections \ref{Ssec:OneMVC} and \ref{Ssec:MultLink} for more information on how
parent and child models are linked), the \Rslot{virtualData} slot is data
pertaining to the views that needs to be stored with the model so that it can
be shown in all views of this model, and the \Rslot{modelName} slot is the
name of the model. 

\begin{figure}[ht]
  \begin{center}
    \scalebox{0.7}{\includegraphics{ModelClass.jpg}}
    \caption{ Inheritance for Model Objects. }
    \label{Fig:Model}
  \end{center}
\end{figure}

We encapsulate the particular data model in the class definition, which allows
for efficient dispatch, and accessor functions that are appropriate for the
underlying implementation.  The specific model classes used in the
\Rpackage{iSNetwork} package to represent data are \Rclass{dfModel},
\Rclass{graphModel}, and \Rclass{exprModel}.  The \Rclass{dfModel} class
represents a model where the \Rslot{modelData} slot has class data frame (or
matrix), the \Rclass{graphModel} class represents a model where the
\Rslot{modelData} slot has class graph, and the \Rclass{exprModel} class
represents a model where the \Rslot{modelData} slot has class ExpressionSet,
a class used to represent gene expression data \cite{BioC}.

As mentioned previously, the model classes must also perform certain
operations and these operations are reflected in the methods that are defined
for the classes.  All three model classes have an \Rfunction{updateModel}
method that is defined in the \Rpackage{iSNetwork} package.  This method is
called whenever the data need to be updated in response to a user interacting
with a view.  Thus, the \Rfunction{updateModel} method is actually updating the
\Rslot{virtualData} slot because it is this slot in the model classes
that ensures that all views are appropriately visually linked.  

Although only three model classes are currently implemented, future
users are welcome to make additions to the model classes for new data
structures they want to represent.  For example, a user may want to add a new
model class called \Rclass{tsModel} to represent time series data.
To make this addition, the user extends the \Rclass{gModel} class in his or
her own package. 

The model classes must also notify views when the data have changed
so that the views can be updated.  The communication between a model and its
views are discussed in Section \ref{Ssec:OneMess}. 

\subsection{Views}\label{Ssec:OneViews}

The view classes represent the visual depictions of the model.  All
views need to store some common information and respond to certain events
through methods.  This consideration leads to an object model where the
different view classes inherit from a view virtual class,
called \Rclass{genView}.  The object model for the view classes is
shown in Figure \ref{Fig:View}.

\begin{figure}[ht]
  \begin{center}
    \scalebox{0.7}{\includegraphics{newViewClass.jpg}}
    \caption{ Inheritance for View Objects. }
    \label{Fig:View}
  \end{center}
\end{figure}

The \Rclass{genView} class has three slots, \Rslot{dataName}, \Rslot{win},
and \Rslot{winNum}.  \Rslot{dataName} is the name of the model that the view
displays, \Rslot{win} is the Gtk window object that holds the view, and
\Rslot{winNum} is the number of the window so that the window can be
identified in the Window menu on the GUI (see Section \ref{Ssec:OneCont}).
All views need to know these three pieces of information so
\Rclass{genView} binds the view classes together. 

As for specific view classes, the \Rclass{spreadView} class
represents a spreadsheet view of the data.  This view only makes sense for
models that are a two dimensional data structure, such as a matrix or a data
frame.  The information needed for this view is stored in the slot,
\Rslot{clist}, which is the Gtk spreadsheet object.

When creating a plot of a data set, there is a general class, called
\Rclass{plotView}, that has the slots, \Rslot{plotDevice}, \Rslot{plotPar},
and \Rslot{drArea}, which store the device number of the plot, the plotting
parameters, and the Gtk drawing area object, respectively.  This class is a
virtual class as it represents a general plot.  The instantiable plot classes
are the specific plot classes, \Rclass{sPlotView}, \Rclass{graphView}, and
\Rclass{heatmapView}, which inherit from the \Rclass{plotView} class.  

The \Rclass{sPlotView} class represents a scatter plot view and it has the
extra slots, \Rslot{dfRows}, \Rslot{xvar}, and \Rslot{yvar}, where
\Rslot{dfRows} are the row names from the model that are shown in the plot,
\Rslot{xvar} is the variable name from the model that is shown as the x
variable in the plot, and \Rslot{yvar} is the variable name from the model
that is shown as the y variable in the plot.  The \Rclass{graphView} class
represents a graph plot view and it contains the slot, \Rslot{grLayout}, which
holds a \Robject{Ragraph} object that represents the layout of the graph plot.
The \Rclass{heatmapView} represents a heatmap
view of the data and it contains the slot, \Rslot{ordering}, which is a list
that is returned from the \Rfunction{heatmap} function to give information
about the ordering in the row and column dendrograms.  Note that some of these
views are only applicable for certain model types.  For example, the
\Rclass{graphView} class only makes sense for a view of a graph object,
which is stored in the \Rclass{graphModel} class. 

Since all views are expected to be interactive, all view classes have methods
that correspond to user interaction.  Interactive views mean a response
occurs when the view has focus and an event occurs.  The events we are most
interested in responding to include key press
events, where a certain configuration of keys are pressed; button click
events, where one of the mouse buttons is clicked over the view; and mouse
movement events, where the cursor moves over the view.  Recall from Section
\ref{Ssec:Backg} that when an event occurs Gtk emits a signal that is caught
by the signal handler.  The signal handler then calls the callback function
and it is in the callback function that the corresponding method is called.
For example, when the button click event occurs on a scatter plot view, the
callback function calls the scatter plot's \Rfunction{clickEvent} method.
Using the information that is passed to the \Rfunction{clickEvent} method in
the \Rslot{where} parameter, the method converts the Gtk pixel coordinates
that indicate where the event occurred into user coordinates and then into an
object from the plot, such as a point on the plot. 

For \Rclass{sPlotView}, the \Rfunction{clickEvent} method is called when Gtk
emits a signal that a mouse button has been pressed and the
\Rfunction{motionEvent} method is called when Gtk emits a signal that
the cursor has been moved over the view.  Both the \Rfunction{clickEvent} and
\Rfunction{motionEvent} methods for a \Robject{sPlotView} object
determine which point on the plot was clicked or under the cursor,
respectively, using the data in the \Rslot{where} parameter.  For
\Rclass{spreadView}, the \Rfunction{clickEvent} method is called when Gtk
emits a signal that a row in the spreadsheet has been selected or unselected
and the \Rfunction{clickEvent} method determines which row was changed.
For \Rclass{graphView}, the \Rfunction{clickEvent} method is called when Gtk
emits a signal that a mouse button has been pressed and the
\Rfunction{motionEvent} is called when Gtk emits a signal that the cursor has
been moved over the view.  Here, though, the \Rfunction{clickEvent} and
\Rfunction{motionEvent} methods determine which node was clicked or under
the cursor, respectively, using the data in the \Rslot{where} parameter.  

The \Rclass{heatmapView} class is different from the other views in that it
has neither a \Rfunction{clickEvent} or a \Rfunction{motionEvent} method.  The
current implementation of the \Rfunction{heatmap} function does not return
information about where plot objects are placed on the device.  As a result,
it is not possible to convert the user coordinates of where the event occurred
into an object (such as the row and column coordinates of the heatmap) on
the view.  Thus, the \Rclass{heatmapView} class is the only view that is not
currently interactive.  

As with the model classes, the view classes need an update
method and thus, all views have an \Rfunction{updateView} method that is
defined in the \Rpackage{iSNetwork} package.  This method must take the
information that a model has just been updated and appropriately update the
view to reflect that change.  Each method depends on how the view
represents the data so for a \Robject{spreadView} object the
\Rfunction{updateView} method may select or unselect a row on the spreadsheet
while for a \Robject{sPlotView} object the \Rfunction{updateView} method may
change the appearance of a point on the plot.  

Note that when updating a view in R we do not have access to objects on a
view.  Thus, a point on a plot is not an object that allows us to update its
attributes and then have that point redrawn to reflect its new attributes.
Instead in R we must currently draw over a portion of the view to update the
view.  However, if the method of creating R plots changed, the
\Rfunction{updateView} methods could be modified. 

The inheritance structure of the view classes is intended to be
extensible.  For instance, if users wanted to add a new plot view, say a
density plot, they could create a new view class that inherits from
\Rclass{plotView}, called \Rclass{dPlotView}.  This new class,
\Rclass{dPlotView}, has slots named \Rslot{dfRows} and \Rslot{col} to store
which rows and which column, respectively, were used to calculate the density
shown in the view.

\subsection{Controller}\label{Ssec:OneCont}

The controller must perform two tasks: the first task is to store information
and the second task is to allow the user to determine the course of actions.
For the first function, which is implemented in the \Rpackage{MVCClass}
package, the controller is implemented as an environment that is stored in the
\Rslot{controller} slot of a \Robject{MVC} instance, which is discussed in
more detail in Section \ref{Ssec:OneMVC}.  Although other options exist for
storing data, such as a list or a database, an environment is nice because in
R an environment is not copied each time a value within the environment
changes.  The controller in this first role needs to store information
pertaining to state, such as information about the appearance of the views in
a particular model-view-controller entity.

For the second function, which is implemented in the \Rpackage{iSNetwork}
package, the controller gives the user access to the application program
interface (API), either through the GUI or through command line functions.
Through the API the user can load data, create views, set the response to user
interaction with a view, quit the program and perform other functions.  On the
GUI, there are menus to let users decide which action is taken next.  If
the user would rather not use the GUI, there are command line functions that
provide access to the same functionality that is available through the GUI.
The GUI is shown in Figure \ref{Fig:ContWin} and is referred to as the
control window.

\begin{figure}[ht]
  \begin{center}
    \scalebox{0.35}{\includegraphics{ControlWindow.jpg}}
    \caption{ The Control Window. }
    \label{Fig:ContWin}
  \end{center}
\end{figure}

As shown in Figure \ref{Fig:ContWin}, the menus on the control window are
File, Edit, Display, Event, and Window.  These menus always appear on the
control window, but the menu items under each menu change depending on
the type of model that is active.  Because the goal is to have multiple
linked \Robject{MVC} objects, more than one \Robject{MVC} object is loaded and
thus, more than one model. However, the control window menus and the command
line functions only perform operations on one \Robject{MVC} object at a time.
Thus, in the \Rpackage{iSNetwork} package there is the concept of the
``active'' \Robject{MVC} object, where the ``active'' \Robject{MVC} object
(and thus, the ``active'' model) means that operations performed through the
control window menus or through the command line functions affect that
\Robject{MVC} object.  For example, the Display menu allows users to create
views of the active model, but only certain views are appropriate for a type
of model, as mentioned in 
Section \ref{Ssec:OneViews}.  If the active model was a data frame model
(\Rclass{dfModel}), then the views that the user could create are a
scatter plot (\Rclass{sPlotView}) and a spreadsheet (\Rclass{spreadView}),
but a graph plot (\Rclass{graphView}) does not make sense.  Thus, when the
model in the ``active'' \Robject{MVC} is of class \Rclass{dfModel}, then the
Display 
menu has menu items to create a scatter plot and a spreadsheet.  Also, if
the ``active'' \Robject{MVC} is of class \Rclass{dfModel}, then the command
line functions only let the user create a scatter plot and a spreadsheet view
of the active model.

Because one of the goals of creating linked views based on multiple linked
data sets is to create a software package that is flexible and extensible,
users are able to add menus and menu items to the control window through
the command line to access new functionality that they have created.  As an
example if a future programmer wants to add a new type of view, such as a
histogram, then a new menu item for that view could be added to the Display
menu, as long as that view makes sense for the active \Robject{MVC's} model.
By allowing users to change the controller, they can add new functionality that
is specific to their problem.  Note that when users make additions to the API,
they should add new command line functions in addition to adding menus and
menu items to access that functionality.

\subsubsection{Linking Events to Functions}\label{Ssec:OneEvent}

Linking callback functions to events, such as a button click, a mouse movement
or a key press event, is what allows users to have an interactive
environment.  When an event occurs, the callback function linked to the event
determines the response to that event.  To create a flexible environment
it is nice to be able to change the response, which is determined by the
callback function, to an event.  For example, when a left button press event
occurs, a user may sometimes want a point to be colored and at other times she
may want a point to be hidden.  

To allow this flexibility in the response to an event, a class called
\Rclass{gEventFun} was created.  The \Rclass{gEventFun} class stores all of
the information needed to create a particular response to an event.
Clearly, the response to an event can be performed by a single function,
which is called the callback function, as discussed in Section
\ref{Ssec:Backg}.  However, different responses to an event may require
functions with different signatures.  Using the example in the previous
paragraph, a callback function that colored a point needs two parameters,
the new color to use and the point to color, while a callback function that
hid a point needs just one parameter, the point to hide.  Since the
intention is to be able to interchange the responses to an event, the
signatures of different callback functions should be the same.  These design
decisions determined the slots in the \Rclass{gEventFun} class and are
discussed more fully in the following paragraphs. 

As shown in Figure \ref{Fig:EventFun}, the slots in the \Rclass{gEventFun}
class are \Rslot{callFun}, \Rslot{shortName}, and \Rslot{preprocessFun}.  The
\Rslot{callFun} slot is the callback function, the
\Rslot{shortName} slot is a short description of the function that
identifies the callback function, and the
\Rslot{preprocessFun} slot is a list of all preprocessing
functions that must be called before the callback function.

\begin{figure}[ht]
  \begin{center}
    \scalebox{0.6}{\includegraphics{EventClass.jpg}}
    \caption{ The gEventFun Class. }
    \label{Fig:EventFun}
  \end{center}
\end{figure}

The callback function that is stored in the \Rslot{callFun} slot must take
only one parameter.  As discussed previously, all callback functions must have
the same signature so that different callback functions can be interchanged in
the code to allow different responses to an event.  All callback functions
need to know what object they should act on so this is the one
parameter that the callback functions take.  Any other information a callback
function may need is set using the preprocessing functions.  The class of
the one parameter for the callback function depends on the model class in
the active \Robject{MVC} object.  For example, for a graph model, the
parameter is of class \Rclass{AgNode}, representing a node in the graph.  For
a data frame model, the parameter is of class \Rclass{character}, representing
a row in the data frame. 

The preprocessing functions that are stored in the preprocessFun slot
take no parameters.  The purpose of the preprocessing functions is to set
variables that the callback function needs.  Thus, not all callback
functions need preprocessing functions and if no preprocessing functions
are needed, then this slot is NULL.  If the callback function sets the
color of a node in a graph, then a preprocessing function is needed to
determine what color is used.  So in this example, the preprocessing
function opens a color browser to allow the user to choose what the new
color is.

When a user wants to link a callback function stored in an \Robject{gEventFun}
instance to an event, this can be performed either through the GUI or through
the command line functions.  The controller environment in each \Robject{MVC}
object, which is discussed in detail in Section \ref{Ssec:OneMVC},
stores which \Robject{gEventFun} object (representing the callback
function) is linked with each event.  Note that not all callback functions
make sense for each event so the controller environment also stores a list
for each event of appropriate \Robject{gEventFun} instances that can be linked
to that event.

\subsection{MVC}\label{Ssec:OneMVC}
 
The \Rclass{MVC} class binds the model, view, and
controller objects into one object.  Thus, whenever a new data set
is loaded, a \Robject{MVC} object is created.  A \Robject{MVC} object can have
one model and each model must be in one \Robject{MVC}
object so there is a one-to-one relationship between the \Robject{MVC} and
model objects.  Because of this relationship, the \Robject{MVC}
object and the model object are identified by the same name, which
is stored in the \Rslot{modelName} slot of the model object.  When
loading a new model, the name of the model is checked to
ensure that it is unique.

As shown in Figure \ref{Fig:MVCClass}, there is a virtual class, \Rclass{MVC},
that binds the MVC inheritance structure together.  The virtual class,
\Rclass{MVC}, has three slots, which are \Rslot{model}, \Rslot{viewList}, and
\Rslot{controller}.  The \Rslot{model} slot stores the model object, the
\Rslot{viewList} slot is a list of the view objects for this model, and the
\Rslot{controller} slot is an environment that stores information for this
\Robject{MVC}.  These three pieces of information are needed to bind the
model, view, and controller into one object.  To create instances of a single
MVC, the \Rclass{singleModelMVC} class, which inherits from the virtual
\Rclass{MVC} class, can be used.  

Inheriting from the \Rclass{singleModelMVC} class is the
\Rclass{linkedModelMVC} class, which represents a \Robject{MVC} object that
can be linked to other \Robject{MVC} objects.  The \Rclass{linkedModelMVC}
class has two additional slots: \Rslot{parentMVC}, which is the name of the
parent model (\Robject{MVC}), and \Rslot{childMVCList}, which is a list of the
child models (\Robject{MVCs}).  Note that model and
\Robject{MVC} objects use the same name so the \Rslot{parentMVC} slot refers
to both the name of the model and the name of the \Robject{MVC}.
Similarly, for the \Rslot{childMVCList} slot, the names in the list refer to
both the name of the model and the name of the \Robject{MVC}.  In this paper,
we are assuming that models are linked so all \Robject{MVC} objects are of
class \Rclass{linkedModelMVC}.

\begin{figure}[ht]
  \begin{center}
    \scalebox{0.6}{\includegraphics{fullMVCClass.jpg}}
    \caption{ The MVC Class. }
    \label{Fig:MVCClass}
  \end{center}
\end{figure}

Thus, the \Rclass{linkedModelMVC} class not only binds the model,
view, and controller objects together, but it also shows
that the \Robject{linkedModelMVC} objects are related to each other through a
parent-child (tree) hierarchy, as shown in Figure \ref{Fig:Hier}.  In this
picture, `model1' is the name of the original \Robject{MVC} object
(model) and from it, two \Robject{MVC} objects were created,
`model2.1' and `model2.2'. Then from `model2.1', three
\Robject{MVC} objects were created, `model3.1', `model3.2', and
`model3.3'.  As an example, model1 could be gene 
expression data, model2.1 could be gene expression data that is a subset of
model1 (based on filtering), model2.2 could be derived by performing
multidimensional scaling (MDS) on model1, model 3.1 could be the gene ontology
(GO) graph representing the molecular functions of the genes in model2.1,
model 3.2 could be the KEGG pathways that the genes in model2.1 are involved
in, and model 3.3 could be the chromosome locations of the genes in model2.1.

\begin{figure}[ht]
  \begin{center}
    \scalebox{0.6}{\includegraphics{Hierarchy2.jpg}}
    \caption{ The Parent-Child Relationship Between \Robject{MVCs}. }
    \label{Fig:Hier}
  \end{center}
\end{figure}

A design decision was that a new model (and thus, a new
\Robject{MVC} object) could either be loaded or could be created from an
already loaded \Robject{MVC} object.  As mentioned in Section
\ref{Ssec:MMVC}, the focus in this paper is on experimental data that are
linked to meta-data, as the linked data sets that we are most interested in
visualizing.  In this situation, the experimental data (and its
\Robject{MVC} object) can be thought of as determining what
meta-data are studied.  Thus, there is a hierarchical relationship between
these data sets where one \Robject{MVC} object creates another
\Robject{MVC} object.  This focus led to the decision that a
\Robject{MVC} object can have at most one parent
\Robject{MVC}, from which it was derived, but it can have many
child \Robject{MVCs}.  An easy example of a child model derived
from a parent model is to start with a data frame as the parent model and then
take a subset of this data frame as the child model. 

\subsection{Messages Within a MVC Object}\label{Ssec:OneMess}

The message classes provide communication between different
components of the MVC design, such as when the model changes a message needs
to be sent to the views to let them know that they should be updated.  This
communication between the model, view and controller is crucial for the pieces
to work together and yet, still be independent of each other.  For information
about messages that are passed between \Robject{MVC} objects, please see
Section\ref{Ssec:MultMess}. 

The object model for the message classes was derived from the idea
that all messages must have certain methods in common, such as
\Rfunction{initialize} and \Rfunction{handleMessage}, because all
messages must be created and handled in some manner so that the
message is read and acted upon.  All messages are sent to
the \Rfunction{handleMessage} method, which determines where the information
should be sent and hence is the dispatcher.   Also, since messages
are sent when something has changed, either through addition, alteration, or
deletion, the message classes reflect only certain operations.  These
common purposes for the messages allow the message object
model to be constructed, and this model is shown in Figure \ref{Fig:Mess}.

\begin{figure}[ht]
  \begin{center}
    \scalebox{0.6}{\includegraphics{newMessageClass.jpg}}
    \caption{ Inheritance for Message Objects. }
    \label{Fig:Mess}
  \end{center}
\end{figure}

As with the view classes, the top message class,
\Rclass{gMessage}, is a virtual class.  It contains no slots and its purpose
is to bind the other message classes together.

Currently, there are two types of messages for messaging within a
model, view, controller object: an add and an update message.  These two types
of messages are both performing some type of modification and thus, both the
add message, \Rclass{gAddMessage}, and the update message,
\Rclass{gUpdateMessage}, inherit from the virtual class,
\Rclass{gModifyMessage}, which contains three slots, \Rslot{dataName},
\Rslot{mData}, and \Rslot{type}.  \Rslot{dataName} is the character string
that gives the name of the model, 
\Rslot{mData} is a list of data needed to perform the addition or alteration
operation, and \Rslot{type} is a character string that gives the type of
addition or alteration to perform.  Both \Rclass{gAddMessage} and
\Rclass{gUpdateMessage} are virtual classes. 

Since adding a view requires different information and methods from adding a
model (and similarly with updating views versus models), it makes sense to
have two separate message classes for these elements.  Messages
sent between components are from one of the following classes:
\Rclass{gAddDataMessage}, \Rclass{gAddViewMessage},
\Rclass{gUpdateDataMessage}, and \Rclass{gUpdateViewMessage}.  The
\Rclass{gAddDataMessage} class represents a message to add a model
and a \Robject{MVC} object because whenever a model is added, a
\Robject{MVC} object is created that contains this model.  The
\Rclass{gAddViewMessage} class represents a message to create a view.  This
message can only be used after a model has been added. 

The \Rclass{gUpdateDataMessage} class represents a message to update
a model.  This message is crucial for linking because it is
responsible for ensuring that once a model has been updated this
information propagates to all views of the model.  This
same information must also be passed along to any other \Robject{MVC} object
that is related to this model.  Because this
information gets passed to other \Robject{MVC} objects (see Section
\ref{Sec:MultMVC}), this message also has one new slot, \Rslot{from}, in
addition to the slots it inherits from \Rclass{gUpdateMessage}.  The
\Rslot{from} slot is the name of the model that the update data
message came from.  This slot is necessary because the update data message can
come from one of two sources: the message can occur because of user
interaction with a view of this model or the message may
occur because a different model that is
linked to this model has been updated.  Thus, the update data
message may come from within this \Robject{MVC} object or it may come from
either the parent \Robject{MVC} or a child \Robject{MVC}.  Finally, the
\Rclass{gUpdateViewMessage} class represents a message to update a
view.  This message is created and handled whenever the
model is updated so that the views accurately reflect the model. 

%\subsubsection*{Example of Message Passing}

An example of message passing within a \Robject{MVC} object is shown in Figure
\ref{Fig:MPwithin}.  In this example, the response to a user performing a
button click event over a point in the scatter plot is to color the point red.
Setting the response to an event was discussed in Section
\ref{Ssec:OneEvent}.  Here the user first clicks on a point in the
scatter plot, which is shown as Step 1 (the circled 1 on the figure).  In the
figure, the point that has been clicked has an arrow next to it.  Then, in
Step 2, an update data message is sent to the model, which updates
the \Rslot{virtualData} slot of the model object.  After the
model has been updated, the views must be notified that a
change has occurred so in Step 3, an update view message is created and sent
to all views of this model.  In response to this
message, the view updates itself in Step 4 and now the
point is colored red on the view to reflect the change in the
model.  In this example, the \Rslot{from} slot in the
\Robject{gUpdateDataMessage} object is the name of this \Robject{MVC} object
since the message came from within the \Robject{MVC}. 

\begin{figure}[ht]
  \begin{center}
    \scalebox{0.6}{\includegraphics{newMPwithin.jpg}}
    \caption{ Message Passing within a \Robject{MVC} object.  The first step,
      indicated by a circled one, occurs when a user interacts with the y
      versus x scatter plot.  Then an update data message is sent to the model
      in the second step, which alters the model.  Next in the third step all
      views of this model are sent an update view message, which causes the
      view to be updated in the fourth step. }
    \label{Fig:MPwithin}
  \end{center}
\end{figure}

All four classes, \Rclass{gAddDataMessage}, \Rclass{gAddViewMessage},
\Rclass{gUpdateDataMessage}, and \Rclass{gUpdateViewMessage}, have
\Rfunction{initialize} and \Rfunction{handleMessage} methods, which perform
the following tasks.  The \Rfunction{initialize} method is used to properly
fill the slots of the object when it is created.  The
\Rfunction{handleMessage} method is necessary to process the message.  Since a
message is a form of communication between two components, once it is created
it must be sent to the proper recipient and action must be taken in response
to its information, which is the purpose of the \Rfunction{handleMessage}
method. 

As with the inheritance structures seen in previous sections, the message
inheritance structure is designed to allow for extensibility.  For example, a
user could create a \Rclass{gUpdateControlMessage} class that inherited from
the \Rclass{gUpdateMessage} class.  This new class,
\Rclass{gUpdateControlMessage}, could convey information that told the
control window to be updated in response to a change in the active view (the
active view is the view that has the focus).  Currently, the control window
does not reflect what the active view is, but if a view was created that could
be rotated, then a user may want the control window to have some type of
interface to allow the user to control the rotation.  The goal for the message
classes is that the design is flexible enough to allow a user to make
additions or changes. 

\section{Details of Multiple MVCs}\label{Sec:MultMVC}

We now describe the implementation of multiple \Robject{MVC} objects for
linking views of multiple linked data sets.  Each \Robject{MVC} object
represents one model and its views.  Now for the
views of different data sets to be linked, they must link through
the data sets so this linking information must be stored somewhere.  Also,
there must be message classes to pass information between
\Robject{MVC} objects. 

Thinking of experimental data that are linked to meta-data as an example, there
are two \Robject{MVC} objects, one for the experimental data and one for the
meta-data.  In the example of experimental microarray data that are linked to
the Gene Ontology molecular function graph that was first mentioned in Section
\ref{Ssec:Limit}, these two data sets are linked in the following manner: the
Affymetrix identifiers in the experimental microarray data are linked to Locus
Link identifiers, which are in turn linked to the Gene Ontology molecular
function terms.  Thus, to pass information between these two data sets a table
that links Affymetrix identifiers to Gene Ontology molecular function terms
must be stored or there must be a function to call that converts from
Affymetrix identifiers to Gene Ontology molecular function terms and vice
versa.  Once it is possible to link these data sets, then information must be
passed between them through messages to keep the views synchronized.

As mentioned in Section \ref{Ssec:OneMVC}, the \Rclass{MVC} class has slots
for how the current \Robject{MVC} relates to other \Robject{MVC} objects and
these slots are \Rslot{parentMVC} and \Rslot{childMVCList}.  These slots show
that \Robject{MVC} objects are related through a tree hierarchy where a child
model is derived from its parent model.  Consider Figure
\ref{Fig:Hier}, which was shown previously.  If model1's model changes, then
this information first gets passed to model2.1 and model2.2 and these two
\Robject{MVCs} may make changes to their models based on this
information.  Then model2.1 passes this information to model3.1, model3.2, and
model3.3 based on the changes that model2.1 made to its model.  Thus,
information passing between model1 and model3.1, for instance, only occurs
through model2.1.  So messages can only be sent from parent \Robject{MVC} to
child \Robject{MVC} or from child \Robject{MVC} to parent \Robject{MVC}. 

Next we consider how the data sets are linked (and thus, how \Robject{MVC}
objects are linked) followed by how messages are passed between these
linked \Robject{MVC} objects. 

\subsection{Linking Data Sets}\label{Ssec:MultLink}

For messages to pass between \Robject{MVC} objects, the information from one
\Robject{MVC} must be converted into useful information for a different
\Robject{MVC} object.  Thus, there needs to be some way to determine how data
from one \Robject{MVC} object relates to data in a different \Robject{MVC}
object.  This conversion is done by two functions that are stored in the
\Rslot{linkData} slot of the model objects.  The \Rslot{linkData}
slot is a list with two elements: a \Rfunction{toParent} function and a
\Rfunction{fromParent} function. 

When a child \Robject{MVC} is created from an existing \Robject{MVC}, the
child model's \Rslot{linkData} slot is filled with the two functions,
\Rfunction{toParent} and \Rfunction{fromParent}.  When the model in
the child \Robject{MVC} is updated, the \Rfunction{toParent} function in the
\Rslot{linkData} slot is used to convert the child model's data
change into useful information for the parent model.  

Now suppose that the parent model changed instead.  This information
needs to be passed to the child model.  However, a parent can have
multiple child \Robject{MVC} objects so the parent sends a message to each
child \Robject{MVC} to notify the child of the change and then each child
\Robject{MVC} handles the message by using its \Rfunction{fromParent}
function.  The \Rfunction{fromParent} function converts the parent
model's data change into useful information for this
particular child model.  Thus, the parent model's data
change may be converted into different information for different child models
and this can happen because each child model has
its own \Rfunction{fromParent} function.  When a child \Robject{MVC} object is
created and its model's \Rslot{linkData} slot is filled, the
\Rfunction{toParent} function converts information from this child
model into useful information for its parent \Robject{MVC} and the
\Rfunction{fromParent} function converts a message from its parent
\Robject{MVC} into useful information for this child \Robject{MVC}.

An example of how these functions, \Rfunction{toParent} and
\Rfunction{fromParent}, are used when messages are passed between
\Robject{MVCs} is given in Section \ref{Ssec:MultMess} where Figure
\ref{Fig:MessPass} shows the \Rfunction{toParent} function being used to
convert information from a child \Robject{MVC} object into useful information
for the parent \Robject{MVC} object.

\subsection{Messages Between MVC Objects}\label{Ssec:MultMess}

In Section \ref{Ssec:OneMess}, where the message classes to pass
information within one \Robject{MVC} object were discussed, it was noted that
there are two main types of messages: an add message and an update message.
These message types also are seen in passing messages between different
\Robject{MVC} objects, as shown in Figure \ref{Fig:BetwMess}.  

\begin{figure}[ht]
  \begin{center}
    \scalebox{0.6}{\includegraphics{MVCMessageClass2.jpg}}
%    \scalebox{0.6}{\includegraphics{newMessageClass2.jpg}}
    \caption{ Inheritance for Message Classes that are Passed Between
      \Robject{MVCs}. }
    \label{Fig:BetwMess}
  \end{center}
\end{figure}

The first message class that is discussed is
\Rclass{gAddChildMessage}.  A \Robject{gAddChildMessage} object is very
similar to a \Robject{gAddDataMessage} object because they are both adding a
new model and a new \Robject{MVC} object.  The difference with a
\Robject{gAddChildMessage} object is that it must fill in some extra
information to tie this new \Robject{MVC} object to its parent \Robject{MVC}
object.  The \Rclass{gAddChildMessage} class inherits from the
\Rclass{gAddMessage} class, with the same slots of \Rslot{dataName},
\Rslot{mData}, and \Rslot{type}.  The \Rslot{dataName} slot is the name of the
new model (and new \Robject{MVC}), the \Rslot{mData} slot is a list that
contains the
model data and virtual data to fill the \Rslot{modelData} and
\Rslot{virtualData} slots, respectively, of the new model, and the
\Rslot{type} slot gives the type of the model (currently, the options are
``ExpressionSet'', ``graph'', or ``data.frame'').  As with the previous
message classes, the \Rclass{gAddChildMessage} class has two methods:
\Rfunction{initialize} and \Rfunction{handleMessage}.  The
\Rfunction{initialize} method properly fills the slots of the object when it
is created and the \Rfunction{handleMessage} method ensures that the new
model and \Robject{MVC} objects are created (which is what the
\Rfunction{handleMessage} method for the \Rclass{gAddDataMessage} class does)
and then it fills the \Rslot{linkData} slot of the new child model
so that the \Rfunction{toParent} and \Rfunction{fromParent} functions are
available for messaging between \Robject{MVC} objects and finally it stores
information in the child \Robject{MVC} object's controller that determines if
the child model was created from a subset of the parent
model.  Thus, the \Rfunction{handleMessage} method for the
\Rclass{gAddChildMessage} class both creates the child \Robject{MVC} object
and relates it to the parent \Robject{MVC} object. 

The next two message classes pertain to sending information to linked
\Robject{MVC} objects when a parent \Robject{MVC} or child \Robject{MVC}
object has changed.  These classes are \Rclass{gSendParentMessage} and
\Rclass{gSendChildMessage} and they both inherit from the \Rclass{gMessage}
class, as shown in Figure \ref{Fig:BetwMess}.  Because the messages are
sending information to a linked \Robject{MVC} object, they both contain a slot
for a \Robject{gUpdateDataMessage} object that was just used to update a
\Robject{MVC} object.  The \Rclass{gSendParentMessage} class has one slot,
\Rslot{childUpdateDataMessage}, and this slot contains the
\Robject{gUpdateDataMessage} object that was used to update the child
model.  Similarly, the \Rclass{gSendChildMessage} class has two
slots, \Rslot{parentUpdateDataMessage} and \Rslot{childName}, where the
\Rslot{parentUpdateDataMessage} slot contains the \Robject{gUpdateDataMessage}
object that was used to update the parent model and the
\Rslot{childName} slot contains the name of the child model that is
being updated because a parent \Robject{MVC} can have more than one child
\Robject{MVC}.  

As with all the other message classes, these two send messages have
two methods: \Rfunction{initialize} and \Rfunction{handleMessage}.  The
\Rfunction{initialize} method properly sets the slots of the new object.  The
\Rfunction{handleMessage} method for a \Robject{gSendParentMessage}
takes the \Robject{gUpdateDataMessage} object from the child model
and converts it to a \Robject{gUpdateDataMessage} object for the parent
model using the \Rfunction{toParent} function.  Similarly, the
\Rfunction{handleMessage} method for a \Robject{gSendChildMessage} takes the
\Robject{gUpdateDataMessage} object from the parent model and
converts it to a \Robject{gUpdateDataMessage} object for the child
model using the \Rfunction{fromParent} function.  An example of how
these messages are passed and converted is shown in Figure \ref{Fig:MessPass}.

These message classes ensure that when a model is updated, its parent and
child models are notified of the change and most importantly are
notified of the change in a way that each model can properly act upon that
information.  Because each \Robject{MVC} object has a different model (and
thus a different data set and potentially a different data structure),
information that pertains to the model for one \Robject{MVC} must be converted
to useful information for the linked model and this conversion is done by the
\Rfunction{toParent} and \Rfunction{fromParent} functions.  

\begin{figure}[ht]
  \begin{center}
    \scalebox{0.55}{\includegraphics{newMP.jpg}}
    \caption{ Message Passing Between and Within \Robject{MVCs}.  When a user
      interacts with the y versus x scatter plot, the first step, indicated by
      a circled one, is to send an update data message to model 2.  After
      model 2 has been updated, all views of this model must be notified, which
      is shown in the second step when an update view message is sent.  Next
      any data that are linked to model 2 must be notified that model 2
      changed, which is shown in the third step as a send parent message.
      This message is converted into useful information for model 1 in
      the fourth step by the \Rfunction{toParent} function, and this
      information is sent to model 1 in the fifth step when an update data
      message is sent.  Finally, after model 1 is updated, an update view
      message is sent in the sixth step to update all views of model 1. }
    \label{Fig:MessPass}
  \end{center}
\end{figure}

Figure \ref{Fig:MessPass} is very similar to Figure \ref{Fig:firstMP} shown in
Section \ref{Ssec:Backg}.  Now, however, Figure \ref{Fig:MessPass} shows how
\Robject{MVC} objects are defined and how messages are passed within one
\Robject{MVC} as well as how this information gets passed on to its parent
\Robject{MVC} using messages.  Suppose for this example that when the user
clicks a mouse button over the scatter plot, the response to this event is to
color the point under the cursor 
red.  In this picture, the message passing starts when a user clicks a point,
that is indicated by the arrow, on the scatter plot.  An update data message is
sent to Model 2 in response to this user interaction.  As soon as Model 2 is
updated, it sends an update view message to all its views so that the views
are updated to reflect the changed data.  Now the scatter plot point that was
initially clicked is red.  Then a send parent message is sent because MVC
2, which is the \Robject{MVC} object for Model 2, has a parent \Robject{MVC},
which is MVC 1.  Next the \Rfunction{toParent} function converts the child's
update data message into an update data message that the parent \Robject{MVC}
understands.  Then the update data message that was created by the
\Rfunction{toParent} function is sent to Model 1.  Finally, after Model 1 has
been updated, an update view message is sent to all of Model 1's views.  It is
in this last step that the view of Model 1 has a point colored red to indicate
which data from Model 1 is linked to data from Model 2.  All of the data and
the views are synchronized. 

\section{Conclusions}\label{Sec:Conc}

Several examples of linked data sets were given at the beginning of this
paper, including linked tables from a relational database, and meta data that
are linked to experimental data.  The MVC paradigm was
discussed as a useful design for creating linked views of a data set.
Starting with the MVC paradigm, this paper provided a design for implementing
linked, interactive views of linked data sets based on expanding the MVC
paradigm.  For visualizing linked data sets, the MVC design, which is a well
known and thus, well tested software paradigm, was extended to multiple
\Robject{MVC} objects where each \Robject{MVC} object contains one data set
and its views.  This solution broke down the problem of linked, interactive
views of linked data sets into components (\Robject{MVC} objects) that can be
reused, extended and linked. 

Once the design settled on \Robject{MVC} objects as the component of interest
for creating linked views of linked data sets, the next step was to determine
how these \Robject{MVC} objects were related.  Because the focus in this paper
was on experimental data that are linked to meta-data, a hierarchical
relationship between \Robject{MVC} objects was built into the \Rclass{MVC}
class definition.  The experimental data can be thought of as determining what
meta-data are studied and thus, the meta-data are derived from the
experimental data, which shows a parent-child relationship.  
 
Another consideration in the design was creating a method for communicating
within and between \Robject{MVC} objects.  This method must pass information
between the components while keeping the components independent.
Communication within a \Robject{MVC} object was handled using instances of the
message classes, which performed one of four functions: adding a model, adding
a view, updating a model, or updating a view.  Starting with this design, it
seemed a natural extension to have message classes that passed information
between \Robject{MVC} objects.  When a \Robject{MVC's} model is updated, it
notifies its parent and child \Robject{MVCs} that a change has occurred using
message objects.  Then when a \Robject{MVC} gets a message from a parent or
child \Robject{MVC}, the \Robject{MVC} can either decide to ignore the message
or read the message, which results in this \Robject{MVC's} model being
updated.  However, the \Robject{MVC} object can not decide to only see certain
types of messages.  It must either accept all messages and update its model
based on the messages, or ignore all messages.  A future goal for message
passing is to allow more selectivity in which messages are accepted between
\Robject{MVC} objects so that the linking between \Robject{MVC} objects is
more sophisticated. 

The goals for this paper were to create linked views of linked data sets, to
create interactive views where the response to an event can be changed, and to
create an extensible design that allows future users to make additions.
The first goal was accomplished by implementing \Robject{MVC} objects as
components that communicate with each other through messages.  The second goal
of creating interactive views was met by using the \Rpackage{RGtk} and
\Rpackage{gtkDevice} packages to create devices that could respond to events.
In addition the \Rclass{gEventFun} class was designed so that users could
alter the response to an event.  Finally, the last goal of creating an
extensible design was achieved through the inheritance structure for classes,
which allows for extensions by the user, and through command line functions,
which let the user create new menu items to add to the GUI and also let the
user create new callback functions that can be linked to events. 

Although extensibility was a goal, certain design decisions, such as expecting
the data sets to be linked through a parent-child hierarchy, may not work with
some data sets.  As an example, the linked tables from a relational database
are not related through a tree structure and thus, having parent and child
\Robject{MVC} objects may not make sense with these data sets.  However, the
design allows users to add new types of models, new types of views, and new
message classes so there is still flexibility for additions as long as the
data sets are connected through parent-child relationships.  These new class
definitions could be created by the user in a new package that extends the
\Rpackage{MVCClass} package that was discussed in this paper.  Other additions
that the user may want to perform, such as adding new menus to the GUI and
adding new responses to an event can be performed through command line
functions that are defined in the \Rpackage{iSNetwork} package.

The functionality that is defined in the \Rpackage{iSNetwork} package is
discussed in detail in the Vignette for this R package.  Users can load data,
create views of the data, interact with these views and change the response to
the interaction (these interactions include mouse button click events and
mouse movement events), and users can create child \Robject{MVC} objects
through the GUI or through command line functions.  Using the functionality in
the \Rpackage{iSNetwork} package, the user can create views of linked data sets
and can explore visually the relationships between variables in different data
sets.  This functionality was implemented by extending the MVC paradigm in a
very natural way to encompass a much richer class of models and user
interactions. 

\section*{Acknowledgements}
We are indebted to Dr. Duncan Temple Lang for the creation of the
\Rpackage{RGtk} and \Rpackage{gtkDevice} packages as well as helpful advice on
their use.  

\bibliography{paper2}

\end{document}