next up previous contents
Next: 3 FCM Detailed Design Up: 2 Design Description Previous: 2.1 FCM   Contents

Subsections


2.2 SAM

2.2.1 Design Philosophy

The architecture of SAM has been based on a modified Model-View-Controller (MVC) architecture [4], and Unified Modelling Language (UML) has been used in the design process [8]. The traditional MVC architecture consists of three modules, as shown in figure 2, which form the title:

Note: The use of the term `module' in the design of SAM refers to a grouping of classes, and is intended as a higher level description.

Figure 2: Shows the traditional MVC architecture
\includegraphics[width=5cm]{diagrams/mvc}

After some small modifications as to be discussed in section 2.2.3, this architecture turned out to be the simplest and hence the most reliable. In particular, the View module caters for the variety of types of output that SAM must be able to perform. It was also believed to be the most efficient out of those considered, hence it was chosen for SAM.

A modified Pipes and Filters architecture was also considered, where a control module selected the filters from user input and then the data was read and passed through each filter. Although this would provide a clear conceptual framework, the overhead required in reading and parsing data at multiple stages was significant.

An event based architecture was also considered, but only the GUI is naturally event based; the rest of SAM focuses on data processing. Further, the event queueing and handling system required by the GUI is already provided by a typical widget set and windowing system, so a separate system to handle these functions was not required. It was sufficient to use the MVC architecture with an event based Controller module handling the GUI.

2.2.2 Implementation Language

The Python language will be used to implement SAM. Python is an interpreted high-level object-oriented language. It provides many useful libraries in its standard distribution, which along with its object-oriented nature, allow for greater reuse of existing code and code written for SAM. Being an interpreted language, speed will be less than that of compiled languages such as C. However, Python provides extensive facilities for interfacing with C code, such that if speed proves to be a problem in a particular class, it can be coded in another language, such as C.


2.2.3 Design Overview

Due to the many and varied analyses required of the SAM product, the Model module has been decomposed into three separate modules, which are called Logger, Model and Analysis: Logger is responsible for capturing packet information over a network interface and dumping this to a file; Model is responsible for parsing dump files; and Analysis is responsible for performing various types of analysis on the data parsed by Model. This breakdown can be seen in Figure 3. Note that all communication between modules is now performed by Controller, as it is initiated by user input. The file format chosen for network dumps is of NETLOG format, a format native to RAMI which is defined later (see section 5.1).

This architecture has been chosen to separate the different phases of the analysis, which are as follows:

  1. The data is collected, from the network, and placed into a log file to be read at a later date.
  2. A log file is loaded into a table in memory, and all TCP streams are identified and listed to the user, who then selects some to be analysed.
  3. A table of data is processed in some way to produce another table which represents a particular analysis.
  4. The new table of data is displayed as a table or graphically.
The MVC architecture as implemented in our architecture provides this separation. This separation promotes reusability and extensibility, as each module can be replaced with another - changing the input, analysis or output.

Figure 3: Shows the modified MVC architecture used for SAM, including the decomposition of the model module into Logger, Model and Analysis modules.
\includegraphics[width=8cm]{diagrams/modmvc}

Each of the analysis and output modules have been developed as plugins. That is, they are loaded by the program and make themselves available for their task. However they can be added or removed without any modifications to the program. This allows for easy extendibility. For example, if a new analysis is required, a simple python module can be written, and when placed in the correct directory, it will automatically become available within SAM.

The following sections detail each of the modules of the architecture, and provide diagrams of further decomposition of these modules into classes.

2.2.4 Controller Module

Module Name:
Controller

Purpose:
Handles the main GUI window of SAM, and controls the collection, processing and display of data.

Responsibilities:
This module is responsible for:

Collaboration:
This module collaborates with:

SRS References:
3.2.1.1, 3.2.1.2, 3.2.1.3, 3.2.1.5, 3.2.1.6, 3.2.1.8, 3.2.1.9, 3.2.1.10, 4.3.4.4, 4.4, 4.3.4.5, 5.2.1, 5.2.3

The Controller module is decomposed into the classes as shown in figure 4.

Figure 4: Shows the class decomposition of the Controller module
\includegraphics[width=0.8\textwidth]{diagrams/control}

2.2.5 Model Module

Module Name:
Model

Purpose:
Provides an interface to abstract away the details of parsing of NETLOG and STREAMSLOG files and the submodule decomposition.

Responsibilities:
This module is responsible for providing an interface for:

Collaboration:
This module collaborates with:

SRS References:
3.2.1.1, 3.2.1.2, 3.2.1.5, 3.2.1.8, 5.2.3

The Model module is decomposed further into the classes as show in Figure 5.

Figure 5: Shows the class decomposition of the Model module
\includegraphics[width=0.9\textwidth]{diagrams/model}

2.2.6 Analysis Module

Module Name:
Analysis

Purpose:
This module performs the chosen analysis on a given table of data, and produces another table of data which is an analysis of the initial table. This new table is now ready to be graphed. The analysis is performed by plug-in modules, which all register a function that gets called when analysis needs to be done. The module is actually a collection of plugins.

Responsibilities:
The Analysis module is responsible for:

Collaboration:
This module collaborates with:

SRS References:
3.2.1.3, 3.2.1.4, 3.2.1.8, 4.3.3.2, 5.2.3

The Analysis module consists of the classes shown in Figure 6. Each of the plugins registers itself with the AnalysisPluginsClass.

Figure 6: Shows the class decomposition of the Analysis module
\includegraphics[width=0.8\textwidth]{diagrams/analysis}

2.2.7 Logger Module

Module Name:
Logger

Purpose:
Based on user specified parameters, this module will dump information about packets on the network over a given time to a file. This file will later be read by other components of this program.

Responsibilities:
The Logger module is responsible for:

Collaboration:
The Logger module collaborates with:

SRS References:
3.2.1.9a, 3.2.1.9b, 3.2.1.9c, 3.2.1.9d, 3.2.1.9e, 5.2.3

The Logger module is decomposed into the classes as shown in figure 7. Additionally, a Python module, NetLogger, implemented in C, performs the low level logging task. However, the GUI is handled by Python classes.

Figure 7: Shows the class decomposition of the Logger module
\includegraphics[width=0.8\textwidth]{diagrams/logger}

2.2.8 Output Module

Module Name:
Output

Purpose:
This module produces a graph either to the screen, to a postscript file, to a table displayed on the screen, to a table written to a text file or outputs gnuplot commands and data, to a file loadable by gnuplot. The graph is produced from a table of data which must be provided. A GUI is provided to select any parameters required. The module is actually composed of a set of plugins which register with the OutputPlugins object.

Responsibilities:
The Output module is responsible for:

Collaboration:
The Output module collaborates with:

SRS References:
3.2.1.6, 3.2.1.7, 3.2.1.8, 4.3.3.2, 5.2.2, 3.2.2.1, 5.2.3

The Output module is decomposed into the classes as shown in figure 8. Each of the plugins registers itself with the OutputPluginsClass.

Figure 8: Shows the class decomposition of the Output module
\includegraphics[width=0.7\textwidth]{diagrams/view}

next up previous contents
Next: 3 FCM Detailed Design Up: 2 Design Description Previous: 2.1 FCM   Contents