Software Project


Pasi Aho

Henrik Härkönen

Miikka Lahti

Minna Rajala


Software Plan







University of Jyväskylä

Department of Mathematical Information Technology


This document is the application plan for the Nexus software work project. The purpose of the project is to implement a distributional software that calculates and visualizes 3 dimensional fractals. The project also implements a sniffer to gather the results of the cost efficiency of the distribution. The software plan considers the structure of the distributed application, the fractal calculation and the user interface. This version of a document does not include description of the sniffer because a different document will be made considering implementing it.


1      Introduction. 1

2      The goals for the software. 2

3      The requirements for the system.. 3

3.1       Requirements for the software. 3

3.2       Requirements for the user interface. 3

3.3       Requirements for testing. 4

4      The structure of a Globus application. 5

4.1       The Globus resource management architecture. 5

4.1.1        The components of the GRAM... 6

5      Classes for the Globus system.. 8

5.1       The classes that are needed for the distribution. 8

5.1.1        Classes to be developed. 10

5.1.2        Classes in package org.globus. 10

6      Fractal calculation. 13

6.1       Quaternion fractals. 13

6.2       Visualization of a quaternion fractal 14

6.3       Calculating the fractal 14

6.4       How the fractal calculation works. 15

6.5       Distributing the fractal calculation. 17

6.6       Transferring the results of the fractal calculation. 18

7      3D visualization. 20

7.1       The classes. 20

7.2       The rendering method. 21

8      User interface. 22

8.1       The main window of the user interface. 22

8.2       The number of the fractals dialog. 23

8.3       The fractal properties dialog. 24

8.3.1        Shape. 24

8.3.2        Calculation. 25

8.3.3        Drawing. 26

8.4       The calculating computers dialog. 27

9      Use cases. 28

9.1       Starting the program.. 28

9.2       Defining the number of the fractals. 28

9.3       Choosing the fractal parameters. 29

9.4       Choosing the calculating machines. 29

9.5       Carrying out the calculation. 30

9.6       Canceling the calculation. 30

9.7       Closing the program.. 31

10        Commenting the code and the coding practices. 32

11        Testing principles. 33

12        Conclusion. 34


1         Introduction

Nexus is a student software project to be carried out in the University of Jyväskylä during the spring 2002. The project implements a system of a distributed computational Grid for VTT Information Technology. The system will make use of Grid technology by using Globus Toolkit available freely from the Globus organization.

The software project will collect information about distribution and explore when it is efficient to use decentralization in computational tasks. The practical software to be developed will calculate and visualize three-dimensional fractals using distributed computing. A monitor for analyzing the computational results with different sets of computers and data amounts will also be made.

The software contains two separate components. The client part includes the user interface and the fractal visualization. From the end-user point of view, the application will render fractal under consideration on a screen. The user can rotate it or zoom the view and the fractal is then recalculated. The fractal calculation is divided in specified amount of smaller tasks and then shared with several computers connected as a network with Globus framework. The results are sent back to the client machine as the calculation is going on.

This document describes how the software will be implemented. Chapter 2 represents the goals and Chapter 3 the requirements of the software. In Chapter 4 the structure of a distributed system is introduced. Chapter 5 describes the classes of the JavaCoG that are used in the application and also shows the class diagram. The fractal calculation is represented in Chapter 6 and the next chapter describes how the 3D visualization of the fractals will be done. Chapters 8 and 9 describe the user interface of the application and the use cases in connection with the user interface. Chapter 10 represents the comments and the coding practices that are used and Chapter 11 introduces the main features of the testing principles.

2         The goals for the software

The goal of the project is to produce information about the efficiency of distribution when the Globus toolkit is used with different amounts of calculation tasks. The most important priority is to implement a computational Java software which uses Globus toolkit in distribution and operates on Windows 2000. It is also important to gather information about the traffic in the network. It must be possible both to control the calculation and to distribute it in several Linux computers by using Globus and to calculate it just in the local machine. By enabling this, it is possible to estimate the efficiency of the distribution. The secondary goals include visualizing the calculation results impressively.

To achieve these goals, it has been decided to implement a program that calculates and visualizes 3-dimensional fractals. The fractals are three-dimensional intersections of the quaternion Julian sets. The program should cope with 1 to n fractals and the calculation of each fractal can be distributed from 1 to n machines. The decision has been made that it is enough if the program copes with nine fractals. The aim of the distribution is that the calculation on each machine is approximately equally demanding. The software should include functionalities to determine the calculated area, the number of iterations and the rotation angle for the fractals.

Because the application is developed for gathering and presenting information on a limited area, the graphical user interface, its usability and the functions are not the primary things in this project. Instead, it is emphasized to produce accurate and systematic measuring information about the distribution. In general, the biggest part of efforts will be directed to handling the Globus and distribution.

3         The requirements for the system

This chapter clarifies the requirements of the software, user interface and testing. 

3.1        Requirements for the software

The requirements for the software are listed below.

3.2        Requirements for the user interface

The user interface must operate on Windows 2000 and from there the user must be able to

3.3        Requirements for testing

The requirements for the software are the following ones:

A separate measuring plan will be written that describes the requirements for testing more specific.

4         The structure of a Globus application

This chapter describes the structure of the system from the Globus point of view. The main features of it can be seen in the Figure 1.

4.1        The Globus resource management architecture

A Globus application consists of the following components: a client application, broker, information service, co-allocator and one or more GRAM components. Information between these components is transmitted using the resource specification language (RSL).

The information service provides access to information about the current availability and capability of resources the user has access to. In the Globus system the Metacomputing Directory Service (MDS) is used for maintaining information service. MDS uses the data representation and the application programming interface defined in the Lightweight Directory Access Protocol (LDAP).

Resource brokers are responsible for taking RSL specifications and transforming them into more concrete specifications. These can be passed for example to a co-allocator that is responsible for coordinating the allocation and management of resources at multirequests. Co-allocator splits the request into its components, submits each component to the appropriate resource manager and handles the resulting set of resources as one. Dynamically Updated Request Online Co-allocator (DUROC) is a component for handling all these tasks.  

GRAM (Globus Resource Allocation Manager) belongs to the lowest level of the resource management architecture in the Grid technology. It is responsible for processing RSL specifications representing resource requests by either denying the request or by creating one or more processes according to the request. It also enables remote monitoring and management of the created jobs and updates the MDS information service with information about the current availability and capabilities of its resources.

4.2        The components of the GRAM

The principal components of GRAM are the gatekeeper, the job manager, the local resource manager, the RSL parsing library and the MDS: Grid Resource Information Service. The GSI (Globus Security Infrastructure) is used for authentication.

The task of the gatekeeper is to respond to requests of other machines. This is done by doing three things: performing mutual authentication of user and resource, determining a local user name for the remote user and starting a job manager which is executed as that local user and actually handles the request. The first two tasks are performed by calls to the GSI.

A job manager creates the actual processes the user has requested with help of the RSL Library. This usually involves submitting a resource allocation request to the underlying resource management system. The job manager handles the monitoring of the state of the created processes. It also notifies the callback contact if the state of the process changes and implements control operations such as process termination.

The MDS: Grid Resource Information Service is responsible for storing into MDS various information about scheduler structure and state. This includes e.g. total number of nodes, number of nodes currently available, currently active jobs and an expected wait time in a queue.















Figure 1. The structure of the Globus system in the project.

5         Classes for the Globus system

In this chapter the classes that will be used to implement a distributional software are described. Most of them are part of the Java CoG library but a few classes have to be implemented. All these classes can be seen in the class diagram in Figure 2.

5.1        The classes that are needed for the distribution  

The application has the class GlobusClient that controls the usage of the Globus toolkit. It implements the interface GramJobListener. The class JobListener implements the interface JobOutputListener and handles the output of the GramJobs.

The class GlobusClient uses the class org.globus.mds.MDS to get information of available resources and collects the information to hashtable mdsResult. After locating the resources the class GlobusClient uses the class org.globus.gram.Gram to ping the computers meant to use. Then the class GlobusClient creates a new gramJob using the class org.globus.gram.GramJob and adds it to the gramJobList.

To create GramJob the class GlobusProxy and the string rsl are needed. The class GlobusProxy contains the user key and the user certificate of the globus. The string rsl is created by using the class org.globus.gram.GramAttributes.

When all the initializations above have been made the gramJobs are transmitted to the resources (GRAM) by using the method request of the class org.globus.gram.GRAM. When the status of each job changes the method statusChanged in the class GlobusClient is called.

Each output of the gramJobs goes to a different output file to the computer where GASS server is located. The class GassServer redirects each output file to the separate jobOutputStream stream. When output of each jobOutputStream is updated the method outputChanged in the class GlobusClient is called. When GramJob is finished and no more output is generated method OutputClosed in the class GlobusClient is called.

Figure 2. The class diagram of the Globus system.

5.1.1      Classes to be developed

The classes below will be developed for the distribution.

The class GlobusClient implements GramJobListener. The class manages the use of the Globus toolkit, listens to the state changes of the GramJobs and commands the visualization class to draw given pixels. The attributes of the class are listed below.

Vector gramJobList           is a list of all existing GramJobs.

HashTable mdsResult   is a hashtable that contains the results of mds searches.

The methods of the class are listed below.

public statusChanged()is used to notify the implementer when the status of a GramJob has changed.

The class JobListener implements JobOutputListener. It handles the outputs of GramJobs. The methods of the class are listed below.

public outputChanged(java.lang.String output) is called whenever the job's output has been updated.

public outputClosed() is called whenever job is finished and no more output will be generated.

5.1.2      Classes in package org.globus

The classes below from the package org.globus will be used for the distribution.

The class org.globus.gram.Gram has the constructor Gram(). Methods of the class are listed below.       

request(String resourceManagerContact, GramJob job) is used to transmit a GramJob to the specific Gram.

cancel(GramJob job)      cancels a GramJob.

ping(GlobusProxy proxy, String resourceManagerContact)pings the resource manager

The class org.globus.mds.MDS has the constructor MDS(String hostname, String port). The methods of the class are listed below.

connect()             connects to the specified server.

disconnect()          disconnects from the MDS server.

Hashtable search(String baseDN, String filter, String[] attributes int searchScope)     issues a specified search to the MDS.

The class has the constructor GassServer(GlobusProxy proxy, int port). The methods of the class are listed below.

OutputStream getOutputStream(String id) returns the output stream of the GassServer.

registerJobOutputStream(String lb, out) registers the output file to the output stream.


has the constructor The methods of the class are listed below.

close()              notifies the that no more output will be produced.

The class org.globus.gram.GramJob has the constructor The class has the following methods:

String getStatusAsString() returns the status of the job as string.

cancel()              cancels the job.

GlobusURL getID()     returns the as .

The class has the constructor

The class org.globus.gram.GramAttribute has a constructor The class contains the following methods:

String toRSL()       to string.


6         Fractal calculation

The chapter explains how the fractal calculation will be implemented.

6.1        Quaternion fractals

The fractal objects that will be used in our software are quaternion number Julia sets. A quaternion number has 1 real and 3 imaginary parts, and it is often marked as c = (a, bi, cj, dk). Quaternion Julia sets are defined correspondingly to typical Julia sets, using quaternion numbers instead of complex numbers.

Let us define the quaternion Julia set with a quaternion constant c and quaternion set:

Definition 1:  A quaternion number z is inside of a set if a sequence

z(0) = z

z(n) = z(n-1)^2 + c


Definition 2: A quaternion number z is inside of a set if a sequence

z(0) = z

z(n) = z(n-1)^2 + z


6.2        Visualization of a quaternion fractal

The software to be developed will contain a 3D visualization of a 4D quaternion fractal. This can be done by simply keeping one of the dimensions constant.

A fractal object is calculated to a form of a depth buffer (or z-buffer). The depth buffer is a two dimensional array which have on each (x,y)-position a  value of a top z-coordinate of an object in that position. The depth buffer is then rendered on the screen somehow.

6.3        Calculating the fractal

The chapter describes the information that a fractal calculating program in our software uses.

An area on 3D-space where a fractal is calculated is defined by a start point (start_x, start_y, start_z)  and an end point (end_x, end_y, end_z). Quaternion fractal objects are presented with double precision and their values belong to [(-2.0, -2.0, -2.0),  (+2.0, +2.0, +2.0)].

The number of the iterations (integer) defines how many times the sequence z(n) = z(n-1)^2 + c is iterated until a decision can be made whether it is converging or diverging. A bigger value means better estimation of a fractal set but also longer computing time.

A Julia quaternion constant C is defined as (C_x, C_y, C_z, C_w) which is represented with double precision. In all interesting Julia-sets the values are small.

Rotation angles are defined as (R_angle_x, R_angle_y, R_angle_z) and represented with integer values. They tell how many degrees the object is rotated in x, y and z directions.

The number of the steps in x, y and z direction (Steps_x, Steps_y, Steps_z) tells how many steps (integer) the area is divided in calculation. Steps_x and Steps_y determine how many x- and y-elements the result depth buffer array contains eg. the resolution of an image. They are typically set according to the resolution and the size of the window that views the fractal.

Steps_z determine how smoothly the top z value of a set in each (x,y)-position is searched. Bigger Steps_z means a smoother image but also a longer computing time.

Constant dimension value W (double) is a value for dimension that is kept constant.

6.4        How the fractal calculation works

Let us consider how the fractal computing will be implemented. The routines described here might change a bit for a speed purpose.

The main loop of a fractal calculator for one machine in a pseudo-code looks like this:

void Main (properties) {

Origo      = a middle point of an area defined by (Start_x, Start_y, Start_z), (End_x, End_y, End_z)

for(Y_index = 0 to Steps_y ) {

  for (X_index = 0 to Steps_x)  {

Z_index = 0;

    Decision = false;

//depth_buffer element is initialized with a value, which tells that there is no //object in this position.

    depth_buffer[X_index, Y_index] = -1;

//This do-loop searches the top z-value by simply moving on z-direction one

//'Step_Z' by one and testing on every point if it belongs to the fractal set.

//This is very slow method and might have to be replaced because of a speed

//purpose. (A split search would be much more efficient, but it doesn’t work /

//properly in this case because the fractal-set is not "convex".)

    do {

           Value_X =  ((End_x - Start_x) / Steps_X) * X_index;

           Value_Y =  ((End_y - Start_y) / Steps_X) * Y_index;          

Value_Z =  ((End_z - Start_z) / Steps_X) * Z_index;

           Value_W = W;               // constant dimension


// Rotate value

(Value_X, Value_Y, Value_Z) =

Rotate(Value_X, Value_Y, Value_Z, R_angle, Origo);    

           // The value is inside a set.

Decision =

Is_inside_a_set(Iterations, Value_X, Value_Y, Value_Z, Value_W, C);       

           if (Decision == True)  {

                  // Top Z-value was found and is set in a depth_buffer.

                  depth_buffer[X_index, Y_index] = Z_index / Z_Steps;   


           Z_index ++;

    } while ((Z_index <= Steps_z)  and (Decision = false))




The subroutines simply rotate the point (x,y,z) around the given origo by the given angles. This routine may have to be excluded because of speed purpose (rotating will then be done on a main loop by moving on rotated base vector direction beside of x-, y-, z-direction)

The subroutine Is_inside_a_set estimates whether the value belongs to Julia set. Its implementation looks like this:

Bool/int   Is_inside_a_set(int Iterations, double x, y, z, w, C_x, C_y, C_z, C_w)


    Bool/Int decision;

    Z = (x,y,z,w);             // quaternion

    int i = 0;

    do {

    Z = Z^2 + C;        // Julia

           // Z = Z^2 for quaternions is computed easily.

normp = (Z.x)^2 + (Z.y)^2 + (Z.z)^2 + (Z.w)^2;

// Vector's norm in the power of two.

           i ++;

    } while((i <= Iterations) and (normp < 4))     

    Decision = true;

// When the norm >= 2 the sequence diverges.

    if (normp => 4) {                                                         

           Decision = false;


    return Decision;


6.5        Distributing the fractal calculation

We distribute the fractal calculator described above to n different GRAMs (machines) by creating n processes of a routine, each of one running under GRAM of its own.

One of the processes is a “master” process, which only collects the results of the fractal calculation. Other processes are the “slave” processes that will do the calculating work. The computing work is divided by letting each of the slave processes compute their own part of horizontal lines of a depth buffer. Each slave process can conclude it’s part by it's ID-number and the amount of processes (these are given by MPICH-G2 and the master’s ID-number is zero).

Slave processes send the calculating results to the master process by using MPI’s message-passing routines. The master process then encodes the result depth buffer line to the form of char. After this, it puts it in the output stream from where the client Java-CoG program receives, decodes and finally draws it in the screen.

The Main loop then looks like this:

void Main (properties) {

    if MY_ID = 0 {             // master process

           while (calculating is going on) {

depthBuffer_line = receive_data_from_the_slave_processes





    else {                     // slave process

           for (Y_value = MY_ID to Steps_y, by step = Amount_of_Processes-1) {

//Mostly same as in chapter 6.4, only depth-buffer-handling differs //since data is sended to the master process one horizontal line by one.




So the routine calculates horizontal lines of a depth buffer on every (Amount_of_Processes – 1) line starting from line MY_ID. This way every line will be calculated and the amount of computing work is quite equal in each process.

6.6        Transferring the results of the fractal calculation

The master process will send the result data to the user interface by putting it in the output stream. To do this, the integer depth data is encoded to the character form. The integer contains 32 bits and character contains 8 bits, but in this case the values are quite small (< 100000), so that only three characters are needed in encoding one integer-value. Encoding is done by simply putting the uppermost 8 bits of an integer value to the first character, the lower 8-bits to the second character, and the lowest 8 bits to the third character. The line number of an encoded depth buffer line is put in the beginning of a character table so that the client machine knows where to render the line in the screen.

The encoding of the integer value is done by the precision of three characters (bytes):

Integer: aaaaaaaabbbbbbbbcccccccc

à Char 1 : aaaaaaaa Char 2 : bbbbbbbb Char 3: cccccccc

After the master process puts the encoded depth buffer line to the output stream, it will be transferred to the machine that views the fractal by GASS server (this is more precisely explained in Chapter 5.1).

7         3D visualization

The original requirements stated that the visualization should be implement by Java 3D but there appeared a problem. Java 3D supports only polygon rendering and not raster rendering, which is needed to visualize complex images like quaternion fractals. Due to this we shall implement a small rendering machine of our own by using standard Java packages.

7.1        The classes

The visualization contains two parts. First there is a rendering part that takes a depth buffer of a fractal object (see Chapter 6) and modifies it to the intensity buffer. Intensity buffer is a two dimensional array which contains light intensity value for each (x,y) pixel position. Secondly there is a drawing part that takes an intensity buffer and modifies each brightness value to the RGB colour value, which is then plotted to the corresponding (x,y) position in the screen. The depth buffer is provided to the visualization part one horizontal line by one.

DB_Visualizer is a class for visualizing the depth data computed by a fractal computing part of the software. It contains its own viewing window and has a method for visualizing the depth buffer horizontal line, which is given by one-dimensional array and its y-position.

The class has attributes for a size and resolution of a viewing window, for a size of a depth buffer array and probably for some rendering information (colours, point of a light source etc.). The class also needs the area from where the fractal is calculated (start point and end point), the angles (angle x, angle y, angle z) that describe how the fractal is rotated, and information about the resolution in x-, y- and z-directions (first two describe the size of a depth buffer). It uses DB_Renderer class.

DB_Renderer is a class for rendering the depth data. It transforms the pixel depth values to the light intensity values in a way that result looks three-dimensional. It contains attributes for a size of a depth buffer, for the area and rotating angles of fractal, for the resolution in z-direction, as well as for some information of rendering. It also contains brightness buffer array mentioned earlier and a depth buffer array, which is needed in rendering.

The class contains a method for rendering horizontal depth buffer line which is given by one-dimensional array and its y-position. The given line is stored to the depth buffer array which the intensity buffer array is used to be recalculate. There is a method for getting data from the intensity buffer array, which is used by DB_Visualizer.

7.2        The rendering method

If the rendering method in DB_Renderer is implemented by ourselves, it probably will be based on an idea of approximating the normal of the object’s surface in each pixel point. The pixel point is here a point in 3d-space corresponding to the pixel of a visualized object picture and to the position of a depth buffer array. Approximation is done by using four or eight neighbouring pixel points of a current pixel point. When the normal of the pixel point and the point of the light source are known, the intensity of light for a pixel point (Ip) can be calculated from the Lambert law:

Ip = Il * Kd * cos A

In the formula Il is the intensity of the light of the light source. Kd is constant between 0 and 1, which is an approximation to the “diffuse reflectivity”. In nature it depends on the material of the surface and the wavelength of a light. A is an angle between surface’s normal in the current point and the line from the point to the light source. A varies between 0° – 90° (0 – p/2), where the small values represents high intensity of light (the surface is nearly towards to the light source in the current point) while the big values represent low intensity of a light. To make this calculating task easier, the light source might be set to the infinity, which makes the line from the pixel point to the light source to be a constant vector for every pixel point.

8         User interface

This chapter describes the user interface and the dialogs and also shows the pictures of them.

8.1        The main window of the user interface

When the user starts the program there are only the command menu File and few buttons in the top of the user interface (see Figure 3). In the same time the program starts, the MDS server is being contacted to find out the resources on which the fractal calculation can be done. This information is used when the user defines on which machines each of the fractals will be calculated. In order to get new resources the user has to apply for them directly from the owner of the wanted machines.

Figure 3. The main window of the user interface.

The user interface contains the command menus File, Fractals, Calculation and Help. The first three buttons are shortcuts choosing the number of calculating machines, the fractal parameters and the calculating machines for each fractal. After all these values are chosen the fractal calculation can be started either with the Start button or from the Calculation menu. If the calculation is going on it also can be cancelled before the calculation of the fractals is finalized. This can be done with the Stop button or from the Calculation menu.

8.2        The number of the fractals dialog

The number of calculated fractals can be chosen from the Number of the fractals dialog seen in Figure 4. The user can choose from one to nine fractals to be drawn.

Figure 4. The number of the fractals dialog.

8.3        The fractal properties dialog

This dialog is meant for determining all the parameters in connection with the calculation and the appearance of the fractals.

8.3.1      Shape

The values that affect to the calculation and the visualization of the fractals can be determined from the dialog Fractal Properties seen in Figure 5. The values in the first interleaf Shape affect to the shape of the fractals. The values for the rotation angle, the calculation area and Julia constant values can be determined.

Figure 5. The parameter dialog for the shape of the fractal.

8.3.2      Calculation

The interleaf Calculation (Figure 6) contains the values for determining how demanding the fractal calculation will be.

Figure 6. The parameter dialog for the fractal calculation.

8.3.3      Drawing

From the interleaf Drawing (Figure 7) the user can determine the values attached to the drawing of the fractals. The color of the fractals and the background, the coefficients affecting to the light as well as the value for defining the roughness of the fractal surface can be determined.

Figure 7. The parameter dialog for the visualization of the fractals.

8.4        The calculating computers dialog

The dialog Calculating computers is seen in Figure 8. In this dialog all the available machines for calculation are seen in the list on the left side of the dialog. From these the user can determine the machines on which the calculation of each fractal is distributed. The user can also determine that the fractal calculation will be done on the local machine. This can be done by choosing the item Calculate on this machine from the bottom of the dialog.

Figure 8. The dialog for choosing the calculating machines for each fractal.


9         Use cases

This chapter describes the different use cases of the system.

9.1        Starting the program

Precondition: -

Description: The user starts the program.

Postcondition: The program has started. The default values that define the fractal are set to the parameters. These values are the number of the fractals and the fractal parameters. The calculating computers are searched and they are shown in a list. The screen is empty.

Exceptions: There are no machines found or available at the moment. The dialog that announces about the situation is shown.

9.2        Defining the number of the fractals

Precondition: The program has started.

Description: The user chooses the command Number from the Fractals menu. The program shows a dialog where the user can choose the number of the fractals to be calculated. The number can be chosen between one and nine. The number is accepted with the OK button and abandoned with Cancel button.

Postcondition: The number that the user defined is set to the variable and the dialog is closed.

Exceptions: -

9.3        Choosing the fractal parameters

Precondition: The program has started.

Description: The user chooses the command Properties from the Fractals menu. After this the program shows a dialog with three interleafs: Shape, Calculation and Drawing. From these the user can determine values that define how demanding the calculation will be and how the fractals will be visualized. These values are for example the number of iterations, the rotation angle, the area from which the fractal is calculated and the color of the fractal and the background. The options are accepted with the OK button and abandoned with Cancel button.

Postcondition: The values are set to variables and the dialog is closed.

Exceptions: The user inputs a number that is either too big or too small. The value is not accepted and the default value is set to the text field.

9.4        Choosing the calculating machines

Precondition: There has to be machines available for the calculation.

Description: The user defines the calculating machines for each fractal from the dialog. In the dialog there is a list where all the available machines are shown. The user can choose the calculating machines from this list for every fractal. It is also possible to determine that the fractal will be calculated on the local machine and not to be distributed. The choices are accepted with the OK button and abandoned with the Cancel button.

Postcondition: The calculating machines are chosen and the dialog is closed.

Exceptions: -

9.5        Carrying out the calculation

Precondition: The fractal parameters, the number of the fractals and the calculating machines must be defined. There is no fractal calculation going on.

Description: The user chooses the Start command from the Calculation menu. After this the execution of the program propagates as described in Chapters 6.5 and 6.6 with the parameters the user has defined. During the calculation the results of it are transferred to the user interface machine that visualizes the fractals as the calculation goes on. This is how the user can see the progress of the calculation.

Postcondition: The fractals are being calculated and drawn to the screen.

Exceptions: [1] There is no connection to the “gram-job-machine” or to several machines. The calculation does not start and the error message is shown.

[2] If there is no connection to a single machine the user can define whether to stop the calculation or keep on calculating without that machine. If he chooses the latter choice the fractals that are supposed to be calculated on that machine are not drawn.

[3] If the connection is lost during the calculation an error message is shown and the calculation is stopped.

9.6        Canceling the calculation

Precondition: The fractal calculation is going on.

Description: The user chooses the Stop command from the Calculation menu. After this the confirmation dialog asks if the user really wants to stop the calculation. Yes stops the calculation and No closes the dialog without doing anything.

Postcondition: The calculation is stopped and the dialog is closed.

Exceptions: -

9.7        Closing the program

Precondition: The program has been started.

Description: The user chooses the Exit command from the File menu. If there is still some calculation going on the confirmation dialog is shown. If the user chooses Yes all the calculation is cancelled and after that the program is closed. Choosing No just closes the dialog. If there is no calculation going on the program is exited without a confirmation dialog.

Postcondition: The program is closed and the user is returned to the operating system.

Exceptions: -

10   Commenting the code and the coding practices

All the comments and notations are written in English. At the beginning of each program the filename, the authors, the date and the changes that have been made are shortly described. Also a short description on the purpose of the code and the most important variables and methods are defined. In connection with each method its operation is declared. Also case specific comments are added to the code when necessary.

The following example describes the commenting practices.


Date: 21.3.2002

Copyright: VTT, JyU, Pasi Aho, Henrik Härkönen, Miikka Lahti, Minna Rajala


Description: Class is responsible for sending a job to the printer.

Attributes:   String printerName:  the name of the printer that receives the job

              String status:  status of the printer

Methods:      public void sendJob(int jobID): sends the job to the printer

              public String getStatus(int jobID): returns the status of the job 


11   Testing principles

During and after the development of the application, functionality and usability testing will be carried out. This testing doesn’t focus on the cost-efficiency of decentralization or similar aspects of the project, but takes care of the wanted functionality of the system. First, the single components and parts of the software will be tested and after that the whole system.

More detailed measurements are made with different sets of computers connected to this system and different complexity of fractals. Sharing tasks with multiple servers is tested here. These tests include monitoring and logging the network traffic and latency.

At the end, the purpose of these tests is to make summary of the situations when and for how many computers it is reasonable to use decentralization with particular size task. These tests are made firstly with the project room’s computers and later tests with the computers in a computer class will be carried out. Few larger scale tests will be made in co-operation with VTT.

12   Conclusion

Nexus group implements software that visualizes three-dimensional fractals, distributes the calculation of them with the Globus toolkit and measures the cost-efficiency of the distribution. This document described how the fractal calculation is implemented, how the fractals are visualized and how does the user interface look like. Also the different use cases were presented among other things. Overall, this plan described how the software and its components are implemented. The implementation of the sniffer and a specific measuring plan will be represented in another document.