remote visualisation system - australia telescope national facility

University of Technology, Sydney

Faculty of Engineering

REMOTE VISUALISATION SYSTEM

by

Anil Chandra

Student Number: 99069650

Project Number: S03-148

Major: Software Engineering

UTS Supervisor: Mr Stephen Murray

Industry Co-supervisor: Mr Malte Marquarding (ATNF, CSIRO)

A 12 Credit Point Project submitted in partial fulfilment of the

requirement for the Degree of Bachelor of Engineering.

22 November 2004

Declaration of Originality

I, Anil Chandra, declare that I am the sole author of this document and

have not used fragments of text from other sources without proper

acknowledgement. All theories, results and designs of others that I have

incorporated into this document have been appropriately referenced and

all sources of assistance have been acknowledged.

Signature:

Date:

Abstract

When astronomers observe regions of the sky, the data gathered by telescopes are

filtered, reduced into astronomical images and then stored in data archives. Since

these images are different from normal images and require specialised tools and

processing, astronomers view and analyse them using sophisticated astronomy

software packages

The global nature of astronomy has resulted in numerous different data archives

scattered all over the world. The International Virtual Observatory (IVO) is a recent

global effort to give astronomers transparent access to the images in these archives

over the internet. However, images may be hundreds of megabytes in size and the

client-side processing model does not accommodate well, situations where users

wish to quickly access large images that are often in remote data archives.

The Remote Visualisation System (RVS) is a solution that I conceptualised, designed

and fully implemented for my capstone project. It is a server-side distributed

software system that addresses the need for quick visualisation and analysis of large

astronomical images stored in remote locations. It is a system in which the majority

of the processing is done on the RVS Server, freeing the client from most of the

complex processing tasks.

Users of the RVS will not download images to their computers for quick viewing and

analysis. They may instead use a web browser to request the RVS Server to

download the image as well as request any processing that is required. The web

browser then simply displays the results of the processing requests. A high

bandwidth connection between the RVS Server and the data archive will result in a

much faster transfer of the image than if the users downloaded the image to their

local computers.

I developed the RVS at the Australia Telescope National Facility as an Australian

contribution to the IVO.

Acknowledgements

The following people have helped in some way to the success of the project.

Malte Marquarding

Thank you for all your help and guidance. You have shaped the project into what it is

today and I could not have completed it without your help.

Stephen Murray

Thank you for supervising this project. It was always reassuring to know that I was

on the right track.

Ne il Killeen

Thank you for your managerial guidance. The project went through some changes

earlier on and it was great to have your feedback on all the technical and non-

technical matters.

David McConnell

Thank you for giving me the opportunity to work at the ATNF. I wouldn’t have had

the chance to work on such an interesting project otherwise.

Pooja Raniga

Thank you for your encouragement and support during the project. Thank you for

pushing me hard enough to succeed.

My Uni Friends (you know who you are )

Thank you for all your little help, here and there, whenever I needed it. You have all

been a reliable source of help and comfort.

My Family (esp my mum and brother)

Thank you for your support during the busy times. Thank you for accommodating for

my ever-changing erratic schedule.

Table of Contents

ABSTRACT...........................................................................................................................................................3

ACKNOWLEDGEMENTS...............................................................................................................................4

I. INTRODUCTION.....................................................................................................................................2

1 OVERVIEW................................................................................................................................................2 2 ABOUT ATNF..........................................................................................................................................2 3 SYSTEM DESCRIPTION ............................................................................................................................2 4 SCOPE........................................................................................................................................................3 5 T ERMINOLOGY.........................................................................................................................................4

5.1 Acronyms.......................................................................................................................................4 5.2 Definitions.....................................................................................................................................4

6 DOCUMENT LAYOUT ..............................................................................................................................6

II. LITERATURE REVIEW........................................................................................................................7

1 OVERVIEW................................................................................................................................................7 2 ASTRONOMY BACKGROUND ..................................................................................................................7

2.1 Introduction ..................................................................................................................................7 2.2 Definition.......................................................................................................................................7 2.3 Types of Astronomy.....................................................................................................................8

3 DATA VISUALISATION AND ANALYSIS IN ASTRONOMY....................................................................9 3.1 Introduction ..................................................................................................................................9 3.2 Visualisation ............................................................................................................................... 10 3.3 Position Tracking....................................................................................................................... 12 3.4 Image File Formats ................................................................................................................... 14 3.5 VOTable....................................................................................................................................... 15 3.6 FITS – VOTable Comparison .................................................................................................. 16

4 T HE VIRTUAL OBSERVATORY............................................................................................................. 17 4.1 Introduction ................................................................................................................................ 17 4.2 Changing Science ...................................................................................................................... 18 4.3 Visualisation and Analysis in the VO ..................................................................................... 18

5 CURRENT VISUALISATION AND ANALYSIS SYSTEMS ...................................................................... 19 5.1 Introduction ................................................................................................................................ 19 5.2 MIRIAD ....................................................................................................................................... 19 5.3 AIPS++........................................................................................................................................ 20 5.4 Aladin........................................................................................................................................... 21 5.5 Oasis............................................................................................................................................. 23 5.6 Summary...................................................................................................................................... 25

6 CONCLUSION.......................................................................................................................................... 28

III. PROJECT MANAGEMENT PLAN............................................................................................. 30

1 OVERVIEW.............................................................................................................................................. 30 1.1 Introduction ................................................................................................................................ 30 1.2 System Description .................................................................................................................... 30 1.3 Project Constraints .................................................................................................................... 31

2 PROCESS MODEL................................................................................................................................... 32 3 SCHEDULING .......................................................................................................................................... 33

3.1 Work Breakdown........................................................................................................................ 34 3.2 Work Schedule ............................................................................................................................ 34

4 PROJECT RESOURCES ............................................................................................................................ 35 4.1 Human Resources ...................................................................................................................... 35 4.2 Hardware .................................................................................................................................... 35 4.3 Software....................................................................................................................................... 35 4.4 Time.............................................................................................................................................. 36

IV. SOFTWARE REQUIREMENTS SPECIFICATION.............................................................. 37

1 OVERVIEW.............................................................................................................................................. 37 1.1 Scope ............................................................................................................................................ 37 1.2 SRS Layout .................................................................................................................................. 39

2 GENERAL DESCRIPTION ....................................................................................................................... 39 2.1 System Functions ....................................................................................................................... 39 2.2 User Characteristics ................................................................................................................. 40 2.3 Operational Environment......................................................................................................... 41

3 SPECIFIC REQUIREMENTS..................................................................................................................... 41 3.1 Functional Requirements .......................................................................................................... 41 3.2 Non Functional Requirements ................................................................................................. 49

4 REQUIREMENTS ANALYSIS .................................................................................................................. 53 4.1 Use Cases .................................................................................................................................... 53 4.2 State Analysis.............................................................................................................................. 53 4.3 Class Diagrams.......................................................................................................................... 55

V. S YSTEM ARCHITECTURE ............................................................................................................... 56

1 OVERVIEW.............................................................................................................................................. 56 2 SCOPE...................................................................................................................................................... 56 3 ARCHITECTURE GOALS ........................................................................................................................ 56

3.1 Functional Objectives ............................................................................................................... 57 3.2 Non -Functional Objectives ...................................................................................................... 57

4 DESIGN PRINCIPALS .............................................................................................................................. 58 5 ARCHITECTURE DESCRIPTION............................................................................................................. 59

5.1 Component Descriptions .......................................................................................................... 60 6 LOGICAL VIEW ...................................................................................................................................... 61 7 PROCESS VIEW....................................................................................................................................... 62

8 DEVELOPMENT VIEW............................................................................................................................ 63 9 PHYSICAL VIEW ..................................................................................................................................... 64

VI. HIGH LEVEL DESIGN ................................................................................................................... 66

1 OVERVIEW.............................................................................................................................................. 66 2 SCOPE...................................................................................................................................................... 66 3 DESIGN CONSIDERATIONS ................................................................................................................... 66

3.1 Assumptions ................................................................................................................................ 66 3.2 Constraints .................................................................................................................................. 67 3.3 System Environment .................................................................................................................. 67 3.4 Design Methodology ................................................................................................................. 67

4 DISTRIBUTED ENVIRONMENT.............................................................................................................. 69 4.1 User Manager Invocation Service (UMIS) ............................................................................ 69

5 COMPONENTS......................................................................................................................................... 71 5.1 Command Centre....................................................................................................................... 72 5.2 Security Service.......................................................................................................................... 74 5.3 User Manager............................................................................................................................. 76 5.4 Session Manager ........................................................................................................................ 78 5.5 Data Communications Manager............................................................................................. 80

VII. LOW LEVEL DESIGN .................................................................................................................... 82

1 OVERVIEW.............................................................................................................................................. 82 2 T ECHNOLOGY SELECTION.................................................................................................................... 82 3 COMPONENTS......................................................................................................................................... 83

3.1 Command Centre....................................................................................................................... 83 3.2 Security Service.......................................................................................................................... 85 3.3 User Manager............................................................................................................................. 86 3.4 Session Manager ........................................................................................................................ 88 3.5 CORBA and AIPS++ in RVS................................................................................................... 89 3.6 Data Communications Manager............................................................................................. 97

VIII. PROTOTYPE RELEASE................................................................................................................ 98

1 OVERVIEW.............................................................................................................................................. 98 2 LEVEL OF IMPLEMENTATION ............................................................................................................... 98

2.1 Components ................................................................................................................................ 98 2.2 Demonstration Client ................................................................................................................ 99

3 SCENARIO ANALYSIS .......................................................................................................................... 100 3.1 Pre-Implementation................................................................................................................. 100 3.2 Post-Implementation............................................................................................................... 102

4 PERFORMANCE RESULTS.................................................................................................................... 104 5 IMPACT ON DESIGN ............................................................................................................................. 105

IX. TEST REPORT ................................................................................................................................ 107

1 OVERVIEW............................................................................................................................................ 107 2 FUNCTIONAL TESTS............................................................................................................................ 108

X. RVS CLIENT USER GUID E ............................................................................................................. 114

1 OVERVIEW............................................................................................................................................ 114 2 INSTALLATION..................................................................................................................................... 114 3 RUNNING THE CLIENT ........................................................................................................................ 115

3.1 Command Line ......................................................................................................................... 115 3.2 Java Web Start .......................................................................................................................... 115

4 USER INTERFACE................................................................................................................................. 116 4.1 Main Interface .......................................................................................................................... 116 4.2 Image Options .......................................................................................................................... 119 4.3 Colour map Selection Dialog................................................................................................ 121

5 FUNCTIONS ........................................................................................................................................... 122 5.1 Zooming..................................................................................................................................... 122 5.2 Changing Colour Maps .......................................................................................................... 122 5.3 Viewing a Remote Image ........................................................................................................ 122 5.4 Removing an Image................................................................................................................. 123 5.5 Overlaying Contours ............................................................................................................... 123 5.6 Position Tracking..................................................................................................................... 123 5.7 Changing Channels in a Cube............................................................................................... 123 5.8 Clearing the Canvas................................................................................................................ 124 5.9 Changing Image Options........................................................................................................ 124

XI. CONCLUSION................................................................................................................................. 131

XII. BIBLIOGRAPHY ............................................................................................................................ 133

XIII. APPENDICES ................................................................................................................................... 135

1 RVS SERVER ALTERNATIVE ARCHITECTURES ............................................................................... 135 1.1 Overview.................................................................................................................................... 135 1.2 Client – Server Architecture.................................................................................................. 136 1.3 Layered Architecture............................................................................................................... 138 1.4 Distributed Architecture......................................................................................................... 140 1.5 Data Centric Architecture...................................................................................................... 142 1.6 Summary.................................................................................................................................... 144

2 ANALYSIS OF ARCHITECTURE USING USE CASE D IAGRAMS........................................................ 146 3 IMPACT OF REQUIREMENTS CHANGE ............................................................................................... 159

3.1 Purpose...................................................................................................................................... 159 3.2 Design Issues ............................................................................................................................ 160

4 RVS PROJECT SCHEDULE .................................................................................................................. 163

List of Figures

Figure I-1: How RVS works ........................................................................................ 3

Figure II-1: Observation frequency ranges in astronomy (Houghton 2004) ................ 8

Figure II-2: Radio telescopes of the ATCA (ATNF 2004) .......................................... 9

Figure II-3: A 2D array of values mapped to colour map...........................................11

Figure II-4: Raster image from SGPS Archive (McClure-Griffiths 2003) .................11

Figure II-5: Contour image from SGPS Archive (McClure-Griffiths 2003) ..............12

Figure II-6: An overlay of a raster and contour map...................................................12

Figure II-7: Raster display with axis labels .................................................................13

Figure II-8: A VOTable example (Williams & Ochsenbein 2002).............................16

Figure II-9: AIPS++ Viewer screenshot .....................................................................21

Figure II-10: Screen shot of Aladin Java applet..........................................................23

Figure II-11: Screenshot of Oasis main window.........................................................24

Figure II-12: Client side processing model.................................................................25

Figure II-13: Partial server side model of processing .................................................26

Figure II-14: Pure server side processing model.........................................................27

Figure III-1: System overview diagram ......................................................................31

Figure III-2: Incremental process model of RVS........................................................32

Figure III-3: RVS Work Breakdown...........................................................................34

Figure IV-1: Boundary Model.....................................................................................38

Figure IV-2: Relationship between client, server, session and image ........................42

Figure IV-3: Relationship between clients and a session............................................43

Figure IV-4: Relationship of keys to uses and sessions..............................................44

Figure IV-5: Sequence diagram show image query and response ..............................48

Figure IV-6: Multiple users accessing a single image ................................................49

Figure IV-7: Level 1 Use Case diagram......................................................................53

Figure IV-8: Level 1 RVS State Diagram ...................................................................53

Figure IV-9: Level 2 State Diagram – Serving Client ................................................54

Figure IV-10: Level 1 Class Diagram.........................................................................55

Figure V-1: Conceptual view of RVS Server architecture..........................................60

Figure V-2: Logical view of RVS Server architecture ................................................62

Figure V-3: Process view of the RVS Server architecture..........................................63

Figure V-4: Development view of the RVS architecture ............................................64

Figure V-5: Physical view of RVS Server architecture ..............................................65

Figure VI-1: Communication between distributed RVS Server processes.................69

Figure VI-2: Creating user manager via UMIS ...........................................................70

Figure VI-3: UMIS and User Managers during normal operation..............................71

Figure VII-1: Command Centre class diagram ...........................................................84

Figure VII-2: Security Service class diagram.............................................................86

Figure VII-3: User Manager class diagram.................................................................87

Figure VII-4: Session Manager class diagram ............................................................88

Figure VII-5: Java Pixel Canvas design......................................................................90

Figure VII-6: Remote Display Data design.................................................................92

Figure VII-7: XML representation of AIPS++ record ................................................94

Figure VII-8: Event dispatcher for Remote Pixel Canvas...........................................95

Figure VII-9: Data Communications Manager class diagram ....................................97

Figure VIII-1: RVS Client configuration ....................................................................99

Figure X-1: Main interface screenshot ......................................................................116

Figure X-2: Image options window screenshot.........................................................119

Figure X-3: Colour map selection dialog screenshot................................................121

Figure XIII-1: Client - Server architecture diagram..................................................136

Figure XIII-2: Layered architecture diagram............................................................138

Figure XIII-3: Distributed architecture diagram .......................................................140

Figure XIII-4: Data Centric architecture analysis .....................................................142

Figure XIII-5: Use case - new user registers .............................................................146

Figure XIII-6: Use case - user joins a session...........................................................147

Figure XIII-7: Use case - user requests remote image ..............................................148

Figure XIII-8: Use case - User zooms image ............................................................149

Figure XIII-9: Use case - User views local image ....................................................150

Figure XIII-10: Use case - User creates new layer ...................................................151

Figure XIII-11: Use case - User obtains image statistics ..........................................152

Figure XIII-12: Use case - User rotates image ..........................................................153

Figure XIII-13: Use case - User changes image resolution ......................................154

Figure XIII-14: Use case - User draws circle............................................................155

Figure XIII-15: Use case - User views last error ......................................................156

Figure XIII-16: Use case - User requests canvas ......................................................157

Figure XIII-17: Use case - Slave User Gets Update .................................................158

Figure XIII-18: Use case - User switches to Quanta session....................................159

Figure XIII-19: Session sharing - one instance for all clients...................................161

Figure XIII-20: Session sharing - once image instance per user ...............................162

Figure XIII-21: RVS Gantt Chart..............................................................................168

List of Tables

Table III-1: Software resources required by RVS.......................................................35

Table III-2: Software resources required by RVS.......................................................36

Table IV-1: Characteristics of direct users of RVS Server .........................................40

Table IV-2: Characteristics of indirect users of RVS Server......................................40

Table VI-1: Command Centre Interface......................................................................74

Table VI-2: Security Service interface ........................................................................76

Table VI-3: UMIS Interface ........................................................................................77

Table VI-4: User Manager interface ...........................................................................78

Table VI-5: SIS Interface ............................................................................................79

Table VI-6: Session Interface......................................................................................79

Table VI-7 Data Comms Manager interface ...............................................................81

Table VIII-1: Time taken to perform operations .......................................................104

Table X-1: Main interface description ......................................................................119

Table X-2: Image Options screenshot description....................................................120

Table X-3: Colour map selection dialog description ................................................121

Table XIII-1: Architecture evaluation method ..........................................................135

Table XIII-2 : Client - Server architecture analysis ..................................................137

Table XIII-3: Layered architecture analysis ..............................................................139

Table XIII-4: Distributed architecture analysis.........................................................142

Table XIII-5: Data Centric architecture analysis ......................................................143

Table XIII-6: Summary of architecture analysis .......................................................144

Table XIII-7: Architecturally significant requirement weight ..................................145

Table XIII-8: Normalised result of architecture analysis ..........................................145

Table XIII-9: Task List for RVS Project...................................................................167

Remote Visualisation System I. Introduction

2

I. Introduction

1 Overview

This thesis covers the Remote Visualisation System (RVS) project conducted by me,

Anil Chandra, as part of my capstone project ending in autumn 2004. I designed and

developed the RVS as an employee at the Australia Telescope National Facility

ATNF), a division of CSIRO.

2 About ATNF

Radio astronomy is one of the major branches of modern astronomy. Studying the

radio waves emitted by stars, galaxies and gas clouds gives us a deeper

understanding of how these things work, just as an X-ray of a human body adds to

what we can learn from an ordinary photograph. (ATNF Outreach 2004)

The Australia Telescope National Facility (ATNF) supports Australia's research in

radio astronomy. It is administered by the CSIRO, Australia's national scientific

research organisation and is funded by the Australian Government. The ATNF

operates the Australia Telescope which consists of the Compact Array at Narrabri

and the Parkes and Mopra radio telescopes. (ATNF Outreach 2004)

The ATNF was created in 1989. Its immediate “ancestor” was the CSIRO Division

of Radio physics. It is now the largest single astronomical institution in Australia. It

has about 145 staff and an annual operating budget of about A$18M.

3 System Description

The RVS is a software system that will be used by scientists, mainly

astronomers/astrophysicists to visualise and analyse astronomical images that are

stored in remote locations. Astronomers often need to view astronomical images that

are stored somewhere other than their local computer or even their local network.


3

There are current and emerging data archives around the world that give electronic

access to such data. The RVS gives users the ability to view and analyse these

remote data, without needing to be concerned about its details such as the data’s size

and location.

Data Archive

RVS Server

RVSClient

Internet

Internet

Satellite dish

Signals from space

Figure I-1: How RVS works

The distinguishable feature of the RVS from other astronomy visualisation and

analysis systems is that the RVS is purely a server side system. That is, all image

processing operations are performed on the RVS Server. This can be seen in diagram

above which shows the RVS Server as the connection point between the user and the

data archive which stores the data to be visualised and analysed. This model has its

pros and cons, some of which are explain in later stages of this document.

4 Scope

This thesis can be seen as a complete description of the RVS Project. All relevant

documentation developed during the course of the project has been incorporated in

this document. The RVS is a much specialised software system and by performing a

literature survey described in chapter II, I hoped to give my self and other readers a

better understanding of the environment in which the system will be used.

This document does not:

o Include any source code written for the RVS.


4

o Include an SRS for the RVS Client. The main focus of this project was the

server. Although a client was developed, it was intended to be internal

software used to demonstrate the capabilities of the RVS Server.

5 Terminology

5.1 Acronyms

Acronym Description

AIPS Astronomical Information Processing System

ATNF Australia Telescope National Facility

CSIRO Commonwealth Scientific & Industrial Research Organisation

DC Data Centre

GUI Graphical User Interface

HTTP Hypertext Transfer Protocol

RVS Remote Visualisation System

TCP/IP Transfer Control Protocol/Internet Protocol

5.2 Definitions

Term Definition

AIPS++ Astronomical Information Processing System is a software

package used for processing (mostly Radio) astronomical data

Channel In the context of images, channel refers to a value along the z-

axis (or 3rd axis) of an image that has more than 3 dimensions.

Client A client is the software that a user utilises to gain access to an

RVS server.

Colour Map A finite set of (normally) smooth and continuous colours

Contour Map

A contour map shows lines of equal pixel intensity (e.g. flux

density) in a two dimensional cross-section of gridded data.

Contour maps are particularly useful for overlaying on raster

images, so that two different measurements of the same part of

the sky can be shown simultaneously


5

Data Centre A server provides data to clients. Clients typically browse for

data and then request any data desired.

Session idle time The time since a request was made to an RVS server using the

session id.

Marker map

A marker map represents pixel intensities by a particular marker

shape and fills style. For example, the marker shape may be a

square. The size of the square is proportional to the absolute

pixel intensity. If the pixel is positive the square is filled, if the

pixel intensity is negative, the square is open.

Master User In the RVS Server, a user that creates a session is the master user

for that session.

Position

Tracking

When the world and pixel coordinates of a cursor is displayed

and updated as it moves on the surface of an image.

Raster Image

A raster map represents pixel intensities in a two-dimensional

cross-section of gridded data with colours selected from a colour

map

Remote

Visualisation

System (RVS)

A proposed client/server system for visualisation and analysis of

data located in remote locations.

Server A program that awaits and fulfils requests from client programs

in the same or other computers

Session On the RVS Server, a session is a workspace used by clients and

data centres to hold the data they are interested in.

Slave User In the RVS Server, a slave user is one that accesses a session, but

is not the master user.

Thin Client

A client that knows little about and does little manipulation on

the data it receives from a server. For example, a thin client may

only display images and not let users zoom.

Thick Client

A client that ‘knows a lot’ about the data that it receives from a

server. This means the client can do data manipulation without

querying the server for additional information.

User An individual that uses a client to connect to an RVS server.


6

Vector Map

For complex images and arrays, where each pixel, represents an

amplitude and phase (position angle). A common method of

displaying amplitude and position angle data is via vectors (line-

segments) where the length of the vector is proportional to the

amplitude.

6 Document Layout

The remainder of this document contains the following sections:

o Literature Review – a review of the literature relevant to the RVS.

o Project Management Plan – a plan on how the RVS Project will be

conducted. Particular emphasis has been placed on the software engineering

process to be adopted and the project schedule.

o Software Requirements Specification – a definition of all requirements to be

satisfied by the RVS Server.

o System Architecture – a description of the selected architecture of the RVS

Server. This involves the determination of the high level components in the

software.

o High Level Design – a more detailed description of the components defined

in the system architecture. This includes the interfaces between the

components.

o Low Level Design – a look at the interfaces defined in the HLD and how they

will be represented in the software. Also, how the operations of the interfaces

will be implemented

o Prototype Release – a summary of the RVS prototype and its findings.

o Testing – an acceptance test report

o RVS Client User guide – A user guide for the demonstration client developed

for the RVS.

o Conclusion – Some concluding remarks about the project.

o Bibliography – a list of references used during the course of the project.

o Appendices – A collection of attachments, related to some of the above

sections in this document that may be of interest to readers.

Remote Visualisation System II. Literature Review

7

II. Literature Review

1 Overview

This chapter contains a summary of research I conducted before and during the RVS

project. The goals of the literature survey are as follows.

o To gain a better understanding of some of the issues involved in astronomical

data visualisation and analysis.

o To understand how scientists currently use visualisation tools to analyse their

data and achieve their scientific aims.

o To realize the various visualisation and analysis tools used by astronomers.

o To understand the needs of astronomers that existing software systems do not

satisfy.

o To determine whether there is, in fact, a need for the Remote Visualisation

System.

2 Astronomy Background

2.1 Introduction

This section gives readers a background into how scientists, mainly astronomers, use

data visualisation and analysis to achieve their scientific aims. It is hoped that by

understanding the needs of astronomers and the purpose of visualisation, readers will

be better equipped to understand the purpose of the Remote Visualisation System

(RVS) and its place in astronomy.

2.2 Definition

Astronomy is the scientific study of the planets, stars, galaxies and the universe.

Generally speaking, astronomy and physics are essentially the same science, with

different areas of research and application. (Houghton 2004)


8

The study of the astronomical objects, as mentioned in the above definition, is done

by astronomers. Astronomers ‘observe’ regions of the sky and then analyse the

observed data using sophisticated software systems and applications.

2.3 Types of Astronomy

Astronomers don’t just observe the universe by looking at visible light, as many

would expect. As well as observing visible light, astronomers also observe different

waves in the electromagnetic spectrum. The different frequency ranges that are

observed are:

o Gamma Ray

o X-Ray

o Ultraviolet

o Visible

o Infrared

o Radio

Figure II-1: Observation frequency ranges in astronomy (Houghton 2004)

Figure II-1 shows the different ways in which astronomers can observe the sky as

well as where each type of electromagnetic radiation lies in the spectrum. You will

notice that some of the visible and radio waves make it through the earth’s

atmosphere reaching the ground. Optical telescopes and radio telescopes on the

ground are used to observe visible and radio waves respectively. Other frequencies

are visualised using telescopes higher up in the sky such as satellites. (Houghton

2004)


9

There are many objects in the universe that are of interest to astronomers, but not all

of them emit radiation at all the different frequencies. Therefore, a radio telescope

may observe objects that an X-Ray telescope does not.

However, there are often objects or regions of the sky that emit radiation in more

than one of the frequency ranges. A useful analysis technique for astronomers is to

view a single region of the sky captured using different types of telescopes. For

example, an astronomer may view an optical image of an object, and then look at a

radio image of the same object to find the radio waves that the object is emitting.

Figure II-2: Radio telescopes of the ATCA (ATNF 2004)

3 Data Visualisation and Analysis in Astronomy

3.1 Introduction

Once the data is observed using telescopes astronomers perform analysis on this data

to extract the information they are interested in. Data analysis is the process of

examining a set of data to extract knowledge. An observation of the sky produces a

collection of numbers that do not provide any real knowledge. This data needs to be

investigated using specific techniques and used in conjunction with other data to

extract the knowledge that is sought, i.e. to make sense of all the data.


10

3.2 Visualisation

The primary goal of scientists using visual analysis is to better understand the data

they observe through the use of visual methods. Scientific data can be massive, and

when one tries to sift through to find correlations among numerous variables, it is

time consuming and often leads to a limited understanding of parameters of interest

to a professional. (Palu 2003)

As explained earlier, an observation produces a collection of numbers and

visualisation in astronomy is the representation of these numbers in a visual form.

There are different ways in which this can be done.

3.2.1 Rasters

A raster display of an image looks very much like an ordinary image. An array of

values is mapped to a particular colour map and then displayed as a raster. These

values may vary from very low negative to very high positive numbers, but for a

simple example, let’s take an array of numbers that range from 1 to 10. This is shown

below.

We now define a couple of colours for the two ends of the numerical range.

1 = 10 =

If the value 1 was mapped to red and the value 10 was mapped to blue as shown

above, the resulting raster image will be as follows.

1 2 3 4 5 6 7 8 9 10


11

Using the same colour map, if we display a 2-dimensional array with the centre value

of 1 and gradually increasing to the outside, the result will be:

Figure II-3: A 2D array of values mapped to colour map

Colour maps may consist of as many colours as the platform supports. As you see

above intermediate colours are usually ‘filled’ by the visualisation applic ation. The

image shown in Figure II-4 is a real image taken from ATNFs Southern Galactic

Plane Survey archive. It shows a cloudy structure mapped using a colour map

ranging from yellow to black. The minimum and maximum pixel values of this

particular image are -6.5302 and 110.798 respectively.

Figure II-4: Raster image from SGPS Archive (McClure-Griffiths 2003)

3.2.2 Contour Maps

Contour maps are another way of displaying astronomy images. Contours of images

are drawn by connecting the lines of equal ‘elevation’. In the case of astronomy


12

images, the word ‘elevation’ refers to ‘values’. Figure II-5 shows the same image as

Figure II-4, but as a contour map rather than a raster.

Figure II-5: Contour image from SGPS Archive (McClure -Griffiths 2003)

Figure II-6 shows contour map above overlayed on top of the raster display from the

same image.

Figure II-6: An overlay of a raster and contour map

3.3 Position Tracking

All astronomy images contain meta-data as well as the pixel data that is displayed.

One of the most important pieces of information provided by the meta-data is a

coordinate system that allows the user to determine the real position in the sky, of a

particular point in the image. Most good visualisation applications allow users to

move their mouse cursor over the image to have the position, in the sky, of where the

cursor is at any one time displayed to the user.

As well as the position in the sky, the real value of the pixel is also displayed. This is

not usually the value that is used to draw the image. The value is used with the


13

coordinate system that came with the image, to determine a real world value. For

example, one of the pixels in the images above may translate to a real world value of,

say, 1.672 x 10-4 Jy/Beam. Jy/Beam (“Janky’s per Beam”) is a measure of intensity.

Another way of displaying position information to the user is by placing axis labels

around the image. This is shown in Figure II-7.

Figure II-7: Raster display with axis labels

3.3.1 Catalogue Overlays

Images are not the only result of astronomy observations. Over the course of time,

surveys of the sky have unveiled thousands of objects such as galaxies, stars and

black holes. All these objects are given unique names and stored in catalogues that

can be accessed for later reference.

One of the details of each object stored is its position in the sky. By using this

position information it is possible to draw these objects on images that encompass

the position in the sky where the object was observed. Therefore, when viewing an


14

image such the one shown above in Figure II-7 it is possible (depending on the

capabilities of the software system being used) to find objects that have been

observed in that part of the sky and draw these objects on top of the image. This is

known as catalogue overlays.

3.4 Image File Formats

Just like any other visual display of data, astronomy images need standard formats in

which to format their data. This is so software can interpret the data and produce the

desired visual images. Common image types for non-astronomy data are JPEG, GIF,

TIF and PNG. Astronomy images however are very different, in that they contain

other information besides just the information about pixel colours.

A JPEG image is a binary file that simply contains visual information about each

pixel in the image. Since the colour of each pixel is defined in the file, all JPEG

images look very similar regardless of the computer or software used to view them.

Astronomy images, on the contrary, do not contain colour information. Each pixel in

the image is defined by a value that relates to a real world value. Each pixel has at

least the following information associated with it:

o A numerical value

o A real world unit, such as intensity in Jy/Beam

o Real world coordinates, such as the longitude and latitude in the sky.

Therefore, each pixel actually represents a point in the sky, and you can use the

image to determine the intensity value (as it was observed) at any point, for example.

Astronomy images may be 3 dimensional. Image of 3 dimensions are referred to as

cubes and they are common occurrences in astronomy. All good astronomy

visualisation systems will allow viewing of cubes.


15

3.4.1 Flexible Image Transform System (FITS)

FITS is the standard computer data format widely used by astronomers to transport,

analyse, and archive scientific data files. It evolved out of the recognition that a

standard format was needed for transferring astronomical data from one installation

to another. The original form, or Basic FITS, was designed for the transfer of images

and consisted of a binary array, usually multidimensional, preceded by an ASCII text

header with information describing the organization and contents of the array. The

FITS concept was later expanded to accommodate more complex data formats. A

new format for image transfer, random groups, was defined in which the data would

consist of a series of arrays, with each array accompanied by a set of associated

parameters.

FITS is by far the most widely used and accepted image format for the transfer of

astronomy images.

3.5 VOTable

The emergence of the Virtual Observatory (VO) has motivated the development of a

flexible file format for exchange and processing of tabular data. The VOTable is an

XML based format which is designed for generic use, but particular emphasis has

been placed on astronomical tables.

A VOTable is designed to be flexible in its use. It is not only used to transfer image

data, as FITS is, one can store any table data such as catalogue objects. This, along

with its XML heritage, makes VOTable an excellent format for mass data exchange.

Figure II-8 is an example of a VOTable that contains a table of star objects.


16

Figure II-8: A VOTable example (Williams & Ochsenbein 2002)

3.6 FITS – VOTable Comparison

o FITS has semantics for how data is to be represented when printed.

Formatting instructions using the TDISP keyword make this possible. For

example F12.4 means 12 characters are to be used and 4 decimal places. This

same feature has been represented in VOTable as the attributes width and

precision which, connected with datatype, are semantically identical. Note

that error estimation and the number of digits to print are rather different

semantically.

o FITS has a complex semantics for structuring a single string as a collection of

substrings, and VOTable does not support this. VOTable allows fixed and

variable-length strings, as well as variable-length arrays of fixed length

strings.

<?xml version="1.0"?>

<!DOCTYPE VOTABLE SYSTEM "http://us-vo.org/xml/VOTable.dtd">

<VOTABLE version="1.0">

<RESOURCE ID="Stars">

<PARAM ID="Mass" datatype="float" unit="solMass" value="1"/>

<RESOURCE ID="BigStars">

<PARAM ID="Mass-big" datatype="float" unit="solMass" value="10"/>

</RESOURCE>

<RESOURCE ID="SmallStars">

<PARAM ID="Mass-small" datatype="float" unit="solMass" value="0.2"/>

<RESOURCE ID="VerySmallStars">

<PARAM ID="Mass-tiny" datatype="float" unit="solMass" value="0.05"/>

</RESOURCE>

</RESOURCE>

</RESOURCE>

</VOTABLE>


17

o VOTable supports separating of data from metadata and the streaming of

tables, and other ideas from modern distributed computing. It bridges two

ways to express structured data: XML and FITS. It tries (through UCD) to

express formally what is the semantic content of a parameter or field. It has

the hierarchy and flexibility of XML. FITS does not handle Unicode

(extended alphabet) characters.

It should be noticed that the transformation of FITS to VOTable is meant to be

reversible: the conversion of a FITS file into VOTable does not lose any information,

and a transformation back into FITS is possible. It will however not be possible to

transform any VOTable into a FITS file without losing some information. (Williams

& Ochsenbein 2002)

4 The Virtual Observatory

4.1 Introduction

Astronomy faces a data avalanche. Breakthroughs in telescope, detector, and

computer technology allow astronomical instruments to produce terabytes of images

and catalogs. These datasets will cover the sky in different wavebands, from gamma-

and X-rays, optical, infrared, through to radio. In a few years it will be easier to

“dial-up” a part of the sky than wait many months to access a telescope. With the

advent of inexpensive storage technologies and the availability of high-speed

networks, the concept of multi-terabyte on-line databases interoperating seamlessly

is no longer outlandish. More and more catalogs will be interlinked, query engines

will become more and more sophisticated, and the research results from on-line data

will be just as rich as that from “real” telescopes. Moore’s law is driving astronomy

even further: new survey telescopes now being planned will image the entire sky

every few days and yield data volumes measured in petabytes. These technological

developments will fundamentally change the way astronomy is done. These changes

will have dramatic effects on the sociology of astronomy itself. (Hanisch & Quinn

2004)


18

The Australian Virtual Observatory (Aus-VO) is the Australian arm of the

International Virtual Observatory Alliance (IVOA), which umbrella’s the efforts of

the various alliance partners.

4.2 Changing Science

By providing the tools to assemble and explore massive data sets quickly, the VO

will facilitate and enable a broad range of science. It will make practical studies

which otherwise would require so much time and resources that they would be

effectively impossible. Federating massive data sets over a broad range of

wavelengths will be especially fruitful. This will minimize the selection effects that

inevitably affect any given observation or survey and will reveal new knowledge that

is present in the data but cannot be recognized in any individual data set.

VO-based studies would include systematic explorations of the large-scale structure

of the Universe, the structure of our Galaxy, AGN populations in the universe,

variability on a range of time scales, wavelengths, and flux levels, and other,

heretofore poorly known portions of the observable parameter space. The VO will

also enable searches for rare, unusual, or even completely new types of astrophysical

objects and phenomena. For the first time, we will be able to test the results of

massive numerical simulations with equally voluminous and complex data sets. The

VO-enabled studies will span the range from major, key project level efforts to

supporting data and sample selection for new, focused studies of interesting types of

targets, both for the space-based and major ground-based observatories. (Hanisch &

Quinn 2004)

4.3 Visualisation and Analysis in the VO

The VO introduces are new need for computer systems that are capable of handling

very large amounts of data and performing complex operations on the data in a

relatively short time. The transparent access to remote data introduces the need for

systems that perform remote processing for users.


19

When images that users wish to visualise are very large, it is inefficient for them to

download the image to their local computers for visualisation. With the use of remote

visualisation software, we can have a scenario as follows:

A user performs a query by submitting a HTML form in a web browser. The result of

the query is a list of images that the user may view. By clicking on one of the

images, the browser opens another window that displays the image and allows the

user to perform analysis operations on the image. All this occurs without the user

being aware of the location and the size of the image data.

5 Current Visualisation and Analysis Systems

5.1 Introduction

This section analyses the current ways astronomers view and analyse their data. It is

hoped that by studying the existing software systems we can determine what

requirements of astronomers are not being met, and whether the current systems can

support the emergence of the Virtual Observatory.

5.2 MIRIAD

MIRIAD (Multichannel Image Reconstruction, Image Analysis and Display) is a

toolbox, in the form of an environment with a large set of moderate sized programs

which perform individual tasks, involving complex data processing, image analysis

and visualisation. It was originally developed in 1987 on Sun workstations (SUN OS

3.2), but has since then been ported to a large number of UNIX flavours (SUN OS

4.x, 5.x, SGI/IRIX, HP/UX, ConvexOS, DEC Alpha, LINUX, and VAX/VMS).

Most of the code is written in Fortran 77, with some lower level I/O routine in ANSI-

C. (MIRIAD Introduction 2001)

MIRIAD is a reasonably old and quite popular software package. It is installed

locally, like any other software and supports all the necessary basic functionality that

is expected in a package such as this. MIRIAD, however, does not support:


20

o VOTables

o Catalogue Overlays

o Remote communications (to obtain images located elsewhere)

MIRIAD cannot be used on MS Windows platforms.

5.3 AIPS++

Astronomical Image Processing System (AIPS++) provides facilities for calibration,

editing, image formation, image enhancement, and analysis of images and other

astronomical data. Although the tools provided in AIPS++ are mainly designed for

processing data from varieties of radio telescopes, the package is expected to also be

useful for processing other types of astronomical data and images.

The core of the AIPS++ is written in C++ (although it makes of C and FORTRAN

functions) and the user interface layer is written in a scripting language called Glish.

Glish is an interactive programming language that makes AIPS++ a very tool-based

package that is programmable by the user.

Like MIRIAD, AIPS++ is a standalone package this is installed on the user’s

computer. In terms of basic features, AIPS++ has everything that MIRIAD provides,

the biggest difference between the two being AIPS++s object oriented approach to

user interactivity.

Figure II-9 shows a screenshot of the AIPS++ Viewer tool. This tool can be used to

visualise and analyse images, do position tracking, axis labels, zooming, etc.

AIPS++ does not support:

o VOTables

o Catalogue Overlays

o Remote communications (to obtain images located elsewhere)

AIPS++ is available for Solaris and Linux platforms only.


21

Figure II-9: AIPS++ Viewer screenshot

5.4 Aladin

Aladin is an interactive software sky atlas allowing the user to visualize digitized

images of any part of the sky, to superimpose (or overlay) entries from astronomical

catalogues or databases, and to interactively access related data and information from

popular data archives for all known objects in the field. (Fernique 2003)

Put simply, Aladin allows users to view images located in remote archives. Access to

these archives is given via a query interface where the user enters the query details

(e.g. sky coordinates), selects the archive to search and then receives a viewable

image as a result of the search.

Aladin is not a standalone software package such as MIRIAD and AIPS++. It is a

system that is accessible to users via the Internet, consisting of a client, that the user


22

interfaces with and a server that does the data retrieval and processing. There are

three types of clients:

o A simple previewer

o A java applet interface

o A java standalone interface

All of these can be access using a web browser. This feature makes Aladin extremely

accessible. A user does not need complex image processing software installed on

their local machine. Another big advantage is that the data is transparent. The user

does not need to be aware of where the image came from or how big the image is. In

fact, the Aladin clients don’t download the original image files. When a user requests

an image, the following sequence of operations occurs:

1. Client requests image from the server

2. Server obtains image from data archive

3. Server processes the image and generates a flat image file (e.g. jpg)

4. Server sends simple image file and meta-data to client.

5. Client displays the image.

Therefore, the client never has access to the original astronomy image (unless it

explicitly requests it). This results in a relatively thin client side application, but also

means the client is limited in the number of features it can provide. A couple of the

common visualisation features that are not provided in Aladin are axis labelling and

the viewing of cubes.

Another disadvantage of not having access to the original image is that the zooming

becomes lossy. The client only has the simple image to zoom into and the result will

become pixelated.


23

Figure II-10: Screen shot of Aladin Java applet

The greatest feature of Aladin is that it gives transparent access to image and

catalogue data that can be overlayed on top of each other. Simply by moving the

mouse cursor over the image display, users can see the details of the objects in the

image. This is a powerful VO feature that many other visualisation and analysis

packages don’t have.

5.5 Oasis

Oasis is a standalone Java application that provides basic astronomy data

visualisation and analysis tools. Its main objective is to allow the ‘fusion of multiple

dataset simultaneously’. This simply means:

o To allow users to view images from different remote archives by performing

queries on them.

o To allow users to perform queries on remote catalogue servers and overlay

the results on top of images.


24

This is exactly what Aladin allows users to do. The difference between the two is in

the way the images are processed. Oasis downloads the original FITS file from the

image archives and processes the file and displays it for the user to view. Aladin, on

the other hand does not process FITS files at all, it only displays the rendered image

file sent by the Aladin server.

Figure II-11: Screenshot of Oasis main window

The availability of the FITS image on the client side makes Oasis richer in features

than Aladin. The disadvantage of having feature packed client is that it makes the

client larger in size. The size of the downloaded jar is 4.67MB compared to Aladin’s

1.67MB file. Oasis also consumes more memory than Aladin.


25

5.6 Summary

There are a number of visualisation tools in the market some of which have similar

purposes and others have totally different goal. In general, we can split visualisation

and analysis systems into three different categories.

o Client Side Processing

o Partial Server Side Processing

o Pure Server-Side Processing

5.6.1 Client Side Processing

Data Archive

Physical transfer

Network transfer

Client

Figure II-12: Client side processing model

This model is the simplest, where there is no server involved at all. The common

characteristics of a system that fits the Client Side Processing Model are:

o The entire application runs on a single computer.

o The application is rich in features, supporting all the basic astronomy

visualisation and analysis operations.

o The application has great performance when viewing local images.

o There is an overhead in downloading remote data before application can

process it.


26

o The application uses a large amount of disk space.

o The application has a relatively large footprint (memory use).

o Accessibility is low, since the entire application needs to be installed on a

user’s computer for it to be used.

o Application is relatively easy to implement (relative to other models).

AIPS++, MIRIAD and OASIS are all examples of applications based on the client

side processing model. Although OASIS communicates with remote servers to

retrieve data, the visualisation and analysis processing is all done on the client.

5.6.2 Partial Server Side Processing

Data Archive

Network transfer

Server

Client

Network transfer

Figure II-13: Partial server side model of processing

The partial server side processing model is one where:

o One or more remote servers are used to perform stateless operations on behalf

of the client.

o Most user operations do not require communication with remote servers.

The critical detail in the first point is that the operations on the server are stateless.

That is, the server does not hold user state. Instead, it merely receives some input

data performs the requested operation and returns some output data. It has no notion

of users’ context.


27

The common characteristics of systems based on the partial server side processing

model are:

o The client application runs on a different computer to the server.

o The client is located in a different geographical location.

o The client application is very small in size. It users relatively small amount of

memory.

o The client application is a lot more accessible.

o Performances of some operations are slow.

o Client application required to do some image processing.

Aladin is an example of a system based on the partial server side processing model.

The Aladin client does not process astronomical images. When it wishes to view an

image, it requests the Aladin server to obtain and process the astronomical image and

return a rendered image that Aladin can simply display. Therefore, the Aladin makes

use of a server to perform some of the required image processing operations.

5.6.3 Pure Server Side Processing

ServerData Archive

PCClient

LaptopClient

PDA Client

Figure II-14: Pure server side processing model

The pure server side processing model is another client server model, similar to the

partial server side model. The different between the two is that in the pure server side

model, all image processing is done on the server. Also, the server performs stateful


28

operations on client requests. That is, the server is aware of the client state and all

operations are context sensitive according to that state.

The common characteristics of pure server side systems are:

o Client applications are required to do very little processing. All processing is

done on a server.

o Larger set of features than partial server side systems.

o Client applications are very small in size.

o Client applications have relatively small footprints (memory usage).

o Clients are very accessible due their limited processing requirements.

o Slow response times on user operations.

o Great performance on resource intensive operations (e.g. viewing large

images).

o A variety of client user interfaces possible.

o Server is difficult to implement.

There are currently no pure server side systems in use by astronomers. This is mainly

due to the difficulty in implementing such systems. There are, however, obvious

benefits of such systems in the virtual observatory. One of the aims of the VO is to

provide transparent data access. For data to be transparent, the user need not be

aware of the location and size of the data. This becomes very difficult in other

models where very large images require the transfer of the images from the data

archive to the processing server.

6 Conclusion

This literature survey has shown that astronomy is a much specialised science that

has the need for specific visualisation and analysis tools. The emergence of the

Virtual Observatory (VO) has introduced a new set of challenges mainly to do with

transparent data access and ways of analysing this data. The pure client side

applications such as MIRIAD and AIPS++ are good analysis tools for local data, but


29

do not provide the remote communication capabilities and accessibility required for

VO tools.

Astronomy is all about data. Data Archives around the world are hosting terabytes of

information in the form of images, catalogues, raw data, and other meta-data. Aladin

(and to some extent OASIS) have introduced for the first time, the ability to view

multiple images and catalogue information from different VO source all on the same

canvas. However, what is lacking at present is a system that provides visualisation of

large remote images.

As the VO expands and different data archives become available, we will see the

development of tools that access this data. From what we have seen so far, some of

these tools are starting to be developed and this is duplicating a lot of effort. If we

had a system that provided a set of core functionalities, then different clients (or

access points) could be developed that re-used this functionality.

It is evident then that we need a system that will meet the following high level

requirements:

o Provide a set of basic tools that astronomers these days are used to. This

includes image displays, axis labelling, position tracking, zooming and

contour overlays.

o Provide the ability to overlay objects from catalogues.

o Support the FITS and VOTable file formats.

o Allow users to view and analyse very large images transparently.

o Allow the development of differing user interfaces to make use of a core set

of functionalities.

Remote Visualisation System III. Project Management Plan

30

III. Project Management Plan

1 Overview

1.1 Introduction

This section covers the management plan for the Remote Visualisation System

project to be undertaken by me, Anil Chandra at the Australia Telescope National

Facility (ATNF).

The goals of this plan are to:

o Determine the process model that will be used to implement the system.

o Break down the work into smaller work components.

o Develop a schedule for the entire duration of the project.

o Determine the resources required for the project to be completed successfully.

o Perform a risk analysis and develop strategies of minimising the risks.

1.2 System Description

The Remote Visualisation System (RVS) is to be a software system that allows

remote visualisation and analysis of astronomical datasets through a generic

interface. For example, a user shall be able to use a web browser to visualise and

interact with a dataset that exists on a different machine at a different location.

Figure III-1shows a simplified view of the use of RVS. It receives commands from a

client (the user), obtains the required data from the appropriate external source,

formats the data so that it can be visualised by the client and sends this formatted

data back to the client.


31

RVS

User

Database/Catalogue of Datasets

User requests dataset

Visualisation Data (Image) returned to user

RVS requests dataset

Dataset returned to RVS

Figure III-1: System overview diagram

1.3 Project Constraints

The constraints of the RVS project are:

o Time – a period of one has been allocated for the duration of the project. The

system must be completed within this time.

o Resources – The software being developed is for research purposes and will

be an open source, freely available software system. Since there will be no

financial return on investment, the system will need to operate mostly with

freely available software.

o Expertise – My personal level of expertise is limited to my experience with

JAVA based web systems and application level C++ development. Since I

will be, primarily, the only software engineer working on the system, this

lack of expertise may limit the technologies to be used.


32

2 Process Model

To solve actual problems in an industry setting, a software engineer or a team of

engineers must incorporate a development strategy that encompasses the process, the

methods and the generic phases in the project. This process is often referred to as a

process model (Pressman, 2000). The list of general models that Pressman describes

is:

o The linear sequential model

o The prototyping model

o The Rapid Application Development (RAD) model

o The incremental model

o The spiral model (and the WINWIN spiral model)

o The concurrent development model

o Component based development

After reviewing the above models, I have decided that a slight derivation of the

incremental model is the most appropriate process for the RVS project.

analysis design code informal tests

System/Informationengineering

Increment 1

analysis design code informal testsIncrement 2

analysis design code informal testsIncrement 3

Completion ofincrement 1

Delivery of RVSPrototype

Completion ofincrement 3

analysis design code informal testsIncrement n

Completion ofincrement n

Figure III-2: Incremental process model of RVS


33

The incremental model combines elements of the linear sequential model applied

iteratively with the iterative philosophy of prototyping (Pressman, 2000). The RVS is

a project with some technological uncertainties. It is a technically challenging project

due to its server side nature and hence, the technical feasibility of the system must be

established as early as possible. This will be done by building a working version of

the RVS Server in the early phases of the project. From that point on, the RVS

Server will continue to be operational, with new functionality being added after each

increment. Figure III-2 shows the modified incremental process to be adopted by this

project.

Being a research project, the RVS does not have a ‘client’ as a project would have in

a business environment. The progress of the project will be monitored by my

industry supervisor, Mr Malte Marquarding, and at a much higher level by a CSIRO

Projects Review Committee. The incremental model requires a working prototype

model to be developed at the end of each increment. The RVS, however, will not

produce a working prototype after each increment. The output of each increment will

simply be an RVS Server that has been further implemented further since the

previous increment.

The reason behind this modification to the standard model is that the delivery of

official prototypes requires additional overheads in testing and documentation. This

has been avoided by having a less formal approach to the increment delivery phase.

Instead of a prototype after each increment, an official prototype will be released

after the second increment. This is necessary in order to guarantee the technical

feasibility of the project. After this increment, the design will be thoroughly

reviewed and modifications made where necessary.

3 Scheduling

This section details the schedule for the RVS project by first breaking the project

down into smaller components. These components are then represented in a Gantt


34

chart which shows different activities to be carried out and the sequence in which

they are carried out.

3.1 Work Breakdown

Figure III-3 shows a breakdown of the work required to complete the RVS project.

The two main components of the RVS are the Server and the Client. The server,

being the focus of the project, involves most of the work. Only a prototype version of

the client will be developed, which will not necessarily be publicly released.

Figure III-3: RVS Work Breakdown

3.2 Work Schedule

Appendix XIII.4 (RVS Project Schedule) contains a Gantt Chart of the RVS project

and a table describing each task in the chart in a more detail. You will notice that the

completion of the project, according to the Gantt chart was 25 May 2004. This is in

fact one month earlier than the date specified by University of Technology, Sydney.

There are two reasons for this difference in deadlines:

1. Aiming to finish earlier will leave some room during the project for delays.

This is a risk minimizing strategy.


35

2. My employment contract at ATNF finished on 25 June 2004. In the case that

I did not continue, ATNF wanted the project complete enough for my

successor to continue on it.

4 Project Resources

This section identifies all the resources required to complete the project successfully.

4.1 Human Resources

I am the only full time software engineer working on this project. It is intended that

assistance will be obtained from the following people when necessary.

Mr Malte Marquarding – Software Engineer at ATNF

Dr Neil Killeen – Software Developer / Team Leader at ATNF

Dr David Barnes – Scientist at University of Melbourne

4.2 Hardware

The hardware requirements of the project are listed below.

Hardware Comments Availability

Server to host CVS

and Bugzilla

To host the CVS server that can be

accessed at all times from any location. ATNF

Server to host the RVS To host a web server that will be the

RVS access point. CMIS

A development

platform with at least

256 MB RAM and

LAN adapter

Development PC. This will be the PC

that I will do all my development work

on.

Self + ATNF

Table III-1: Software resources required by RVS

4.3 Software

The following software resources will definitely be required during the course of the

project.


36

Software Comments Availability

Linux Linux is the development

platform for the RVS server ATNF + CMIS (Free)

MS Windows

2000 / XP

For documentation and

general use ATNF + UTS

MS Office Documentation Self + ATNF + UTS

Rational Rose Required for Object

Oriented Design Self + UTS

CVS Server Code repository server ATNF (Free)

CVS Client

(Linux) Code repository client ATNF + CMIS (Free)

JDK 1.4 SE Development of RVS Client CMIS (Free)

TOA C++ CORBA

Implementation CMIS (Free)

JacORB Java CORBA

Implementation CMIS (Free)

Apache Tomcat

Web Server to host web

services and web

applications

CMIS (Free)

Apache Axis Java SOAP Implementation CMIS (Free)

Apache Xerces XML Libraries CMIS + ATNF (Free)

Table III-2: Software resources required by RVS

4.4 Time

See section III.3 for scheduling information.

Remote Visualisation System IV. Software Requirements Specification

37

IV. Software Requirements Specification

1 Overview

This SRS defines all the requirements of the Remote Visualisation System (RVS)

Server. It should be used as a contract that acts as an agreement to the expectations of

the final solution.

The intended audience of this SRS are:

o End users of the system

o Designers and developers of the system

1.1 Scope

1.1.1 Function

The RVS Server is to be a software service that allows remote clients to connect to it,

and download astronomical data that they wish to view and analyse. A typical

sequence of events may be:

1. A client browses a data centre for images.

2. The client connects to the RVS server.

3. The client tells the server which image it wants to view and where ti get it

from.

4. The server then obtains the data from the data centre.

5. The server formats the data and transmits it to the client.

6. The client will use the data to display the image and its information.

Figure IV-1 depicts the boundary model of the RVS server. The shaded region

defines the scope of this SRS in relation to its environment. The three main elements

covered in this document are:


38

o The RVS server software

o The interface between the server and the Data Centres.

o The interface between the server and the client.

This document does not define the following:

o The functional or non-functional requirements of a client

o How a client connects to the server using the server - client interface.

o The interface between a client and a Data Centre

o The functional or non-functional requirements of Data Centres.

DataCentre

DataCentre

DataCentre

RVS Client

Server - Client InterfaceS

erve

r -

DC

Inte

rface

Clie

nt -

DC

Inte

rfac

e

RVS Server

Figure IV-1: Boundary Model

1.1.2 Objectives

The Objectives of the RVS Server are:

o To provide a facility for users to visualise and analyse images that reside on

different machine(s) at a different geographical location.


39

o To provide the visualisation data in a generic format so clients have

flexibility in terms of its use.

o To allow multiple users in remote locations to view a single instance of an

image concurrently.

o To provide its remote facilities at a speed that is comparable to client side

visualisation packages. That is, the interaction between user and system

should allow users to perform their tasks at a satisfactory speed.

o To develop a system that is scalable and easily extensible.

1.2 SRS Layout

The remainder of this SRS contains a general description of the RVS, the specific

requirements that it should meet an analysis of the requirements and a list of all the

requirements of the RVS Server.

o The general description section gives a high level view of the server and its

environment.

o The requirements sections details more specific requirements that the server

is to meet.

o The analysis section includes all analysis that was performed in order to

derive the requirements in this document.

o The Requirements Traceability Matrix is a table that that defines all the

requirements and the sections in which they are documented.

2 General Description

2.1 System Functions

The RVS server shall provide the following services to its clients:

o Allow clients to connect to it and use its services.

o Allow clients to request viewing of image located in remote Data Centres.

o Receive images from remote Data Centres.

o Encapsulate the image data in a consistent data format.


40

o Send the formatted data to the client that requested the data.

o Facilitate the sharing of images amongst clients.

o The formatted data sent to clients shall encapsulate sufficient information so

the clients can visualise it and, at a minimum, perform position tracking on

the image.

2.2 User Characteristics

Users of the RVS server can be divided into two groups; direct users and indirect

users.

Direct User Description

RVS Server Administrators

Individuals who have administrative right to the RVS server.

They shall have access to the application installations and be

capable of viewing/modifying the server’s internal

parameters. Administrator access shall not be provided

remotely.

Client Developers

Individuals that are involved in the development of RVS

client applications. They will use the client – server interface

to connect to the server

Data Centre Developers / Administrators

Individuals involved with interfacing a data centre to the

RVS server.

Table IV-1: Characteristics of direct users of RVS Server

Indirect User Description

End Users (Service Users)

Individuals such as scientists who will use an RVS client

software to visualise an analyse images using the RVS server.

Service users are divided into two types:

1. Master user 2. Slave user

Table IV-2: Characteristics of indirect users of RVS Server


41

2.3 Operational Environment

The RVS server will be a backend service that may run as a standalone service or in

conjunction with other services. There shall be no requirements for the server to be

place in a particular geographical location. Any location and environment is

acceptable as long as it allows the server to meet its non-functional requirements.

The operating system for the RVS will be determined during design/implementation.

There may be a GUI on the server to allow for easy configuration.

3 Specific Requirements

3.1 Functional Requirements

3.1.1 Client Management

3.1.1.1 Client Connections

Requirement ID Requirement Description

R01

All clients wishing to access data on the RVS server shall

connect to a session on the server using a user key provided to

them by the RVS

R02 A client shall be able to use a user key and a session key to

connect to a pre-existing session.

R03 One client shall be able to access more than one session on the

server.

R04 A client shall be able to register a new user by making a request

to the RVS server and receiving the user key in return.

R05 A client shall be able to create a new session by making a request

to the RVS server and receiving a session key in return.

R06 If a client provides a session key that is invalid, an error message

shall be returned indicating that the session key is invalid.


42

R07

Each session shall timeout after it has been idle for a

configurable period of time. There shall be a default timeout

period for all sessions (this value shall also be configurable).

R08

When a session is timed out it is deleted and all data associated

with only that session is deleted. A caching mechanism may hold

some data in case the need for the data arises again in the near

future.

R09 A master user shall have the ability to explicitly delete a session.

R10 All users of a session shall be notified when the session is

deleted. See related requirement R06.

Client/User : User Key : Session Key

SessionServer

Image

1 n

1

n

1

n

Figure IV-2: Relationship between client, server, session and image

3.1.1.2 Service User Types


R11

There shall be two types of end users of the RVS Service:

o Master user

o Slave user

R12 The user that created a session shall be the Master user for that

session.

R13 Master users shall have read and write access to the session they

create on the RVS server.


43

R14 All clients that are not Master users shall access a session as

Slave users.

R15 Slave users of a session shall only have read-access to that

session on the RVS server.

R16

When a Master user on the RVS server modifies the instance of

an image, the updated image data shall be sent to all users in that

session.

Client/User : User Key : Session Key

Master User

Slave User

Session n

1 n

n

Figure IV-3: Relationship between clients and a session

3.1.2 Security


R17 A client shall only be able to create a session when:

o The client explicitly requests a new session.

R18

When a new session is created the RVS Server shall:

o Generate a new unique session key for the session

o Send the session key to the client that requested the

session creation.


44

R19

A client shall only be given access to an existing session when:

o A valid user key is provided and

o A valid session key (for that session) is provided.

R20

A master user, when creating a session, shall have the option of

selecting the maximum number of users for the session. The

default shall be 1 (one). At any time a master user shall be able to

change this value to a value more than the number of current

users of the session.

R21 Provisions shall be made so that advance mechanisms such as

public key authentication can be added to the system in the future

Session

Key Session

User Key Client 1 n

n

n

1 1

Figure IV-4: Relationship of keys to uses and sessions

3.1.3 Data Centre Management

3.1.3.1 Connection


R22 The RVS Server shall initiate a connection with a data centre at

the request of a user.

R23

The user shall provide a URL to be used as a query to the data

centre. This URL must return an image of an acceptable standard

format. See 3.1.5 for acceptable image formats.


45

R24 After a connection is established the RVS server shall receive the

image data (see 3.1.5) from the data centre.

R25 After receiving all data from a data centre, the RVS server shall

associate the image with at least one session.

R26

If the data is of an invalid format or the data is not received

successfully, an error message shall be sent to the user indicating

that the requested the image cannot be obtained.

R27

If a failure occurs in receiving data from a data centre, the user

shall have the option of retrying the process without having to

submit all query data again.

R28

The caching of images shall be implemented so that frequently

accessed images can be accessed locally instead of transferring

remote data each time.

3.1.4 Visualisation

3.1.4.1 Image Canvas


R29 An image canvas shall be the container that holds all the

visualisation information in a session.

3.1.4.2 Image Manipulation


R30 The RVS server shall be able to obtain the image data of a single

channel from an image cube to send to a client.

R31

The RVS server, upon request from a client, shall rotate the

image on the X, Y or Z plane. When images are rotated, the

server shall retain the original axes order.

R32 The RVS server, upon request from a client shall return a subset

of the currently displayed image (zooming).


46

R33

The RVS server, upon request from a client, shall be able to reset

the image properties so:

o The current channel is the first channel (channel 1).

o The axis order of the image is as it was when the image

was imported.

o The zoom is reset to original scale as it was when the

image was first imported.

R34

The rendering of the canvas shall occur on the RVS server. RVS

clients shall receive rendered images that can be displayed

without further processing.

3.1.4.3 Annotations


R35 The RVS Server shall allow clients to draw annotations on image

canvases.

R36 The RVS Server shall accept commands to draw a straight line

between two points.

R37

The RVS Server shall accept commands to draw a straight arrow

between two points. The end(s) of the line to draw arrows on

shall also be provided.

R38

The RVS Server shall accept commands to draw a circle of a

specified radius at a point in the image canvas. The radius shall

be given in image pixels.

R39 The RVS Server shall accept commands to draw polygons of

various shapes on the image canvas.

R40

The RVS Server shall accept commands to draw text fields on

the image canvas. The location of the centre of the text field shall

be provided.

R41 When an annotation is drawn on an image canvas, the RVS

Server shall return a unique identifier for the annotation.

R42 The RVS Server shall accept commands to delete an annotation

using its annotation identifier.


47

3.1.5 Image Data


R43

The image format supported by the RVS server are:

o FITS

o AIPS++ images

o VOTable

R44 All images shall contain valid coordinate systems

R45 The data sent to all clients for visualisation and analysis shall be

in a standard file format (such as XML) so it is easy to interpret.

R46

The data sent to all clients shall encapsulate the following

information at a minimum:

o The data array to be visualised.

o The coordinate system of the image

R47 The RVS server shall be capable of compressing the image data

before transferring to the client.

3.1.6 Image Transfer


R48 The client shall provide the RVS server with the query string to

be used for accessing images from data centres.

R49 The RVS Server shall receive images after requesting it from a

data centre

R50

When an image is received from a data centre the RVS server

shall:

o Associate the image with at least one session

o Update the canvas inside which the image is placed.

R51 If an image is not associated with a session, it shall be removed

or cached in the RVS server.

R52 The RVS image data file shall be transferred to a client when the

client makes a request.


48

R53 The RVS shall also accept data from clients, without the use of

queries to external sources.

RVS : Server : Client/User Data Centre

query

query

image file

visualisation data

Figure IV-5: Sequence diagram show image query and response

3.1.7 Concurrency


R54

Each session shall contain one instance of an image. The state of

an image in one session shall appear the same to any client

concurrently accessing the session.

R55 Each session using the same image shall have different instances

of the image.


49

Image

Instance 1

Instance 2

Session 1

Session 2

Figure IV-6: Multiple users accessing a single image

3.2 Non Functional Requirements

3.2.1 Graphical User Interface


R56 The RVS server may have a GUI that can be used to adjust server

preferences and settings.

3.2.2 Availability


R57

An RVS server shall be available to clients and data centres at all

times while the server software is running. Connections to the

server shall only be blocked if serving more clients or data

centres compromises the stability or security of the server.


50

3.2.3 Portability


R58 The RVS server shall not necessarily be portable between

different platforms (operating systems).

R59

The RVS server shall run on the following platforms at a

minimum:

o Linux

3.2.4 Scalability


R60

The RVS server shall be scalable so it can support greater

number of concurrent connections and sessions if required. That

is, the number of users supported shall be limited only by the

hardware resources available. Applying more resources shall

provide support for a greater number of concurrent users of the

RVS.

3.2.5 Extensibility


R61 The RVS server shall be designed such that the effort required in

adding support for different image formats will be minimal.

R62

The RVS server shall be easily wrapped around a grid service.

That is, the RVS server shall be capable of, in future, acting as a

grid service to provide its services to other grid services and

clients.

R63 The design shall be such that functionality can be added to the

RVS server with minimal effort.


51

3.2.6 Usability


R64

The RVS server interface (to clients) shall be learnable, so that

client developers may learn to interface to the RVS server using

the interface documentation provided.

3.2.7 Reusability


R65 The RVS server application shall run on any system with the

appropriate operating environment (see R59).

R66

The RVS server shall have a clearly defined external software

interface so clients of all types can be served. Client types shall

include:

o Web Server

o Other independent servers

o Grid Services

o Cluster of servers.

o Client side applications

o Client side applets

R67 The RVS server shall be modularised so that there is a greater

emphasis on the re-use of individual components.

3.2.8 Configurability


R68 The RVS server shall be highly configurable with configuration

information stored in an easy to read format.

R69 Configuration information shall be modified without affecting

the availability of the RVS server.


52

R70 Configuration information shall be viewed and edited by RVS

server administrators only.

3.2.9 Reliability


R71 The RVS server shall provide the correct data for the requested

image 100% of the time.

R72 The RVS server shall never send image data to any user that did

not request that image.

3.2.10 Performance Requirements


R73 The RVS server shall provide connectivity via high bandwidth

broadband connection.

R74

The response to a command is to take longer than 20 seconds; an

acknowledgement of the command must be sent the client to

indicate that it is being processed.

R75 The RVS Server shall support at least 50 concurrent sessions.

R76 The RVS Server shall support at least 10 concurrent slave users

per session.

3.2.11 Documentation


R77

There shall be a user guide document constructed that details:

o The RVS server interface to clients

o A guide to writing clients

o A guide to adding components to the RVS server


53

4 Requirements Analysis

4.1 Use Cases

Log in to RVS server

Get image from data centre

Receive canvasVisualise canvas

Connect to data centre

<<include>>

Create canvas

<<include>>

Create session

Authorise user

<<include>>

Client

(from Actors)

RVS Server

(from Actors)

Send canvas<<include>>

Figure IV-7: Level 1 Use Case diagram

4.2 State Analysis

Loading settings (from settings file)

Awaiting connection

success

RVS offline

RVS starting

failure

success

failure

Serving client

completed

connected to client

Figure IV-8: Level 1 RVS State Diagram


54

Receiving data from client

Transmitting error message

Validating session details

Validating command

Processing command

success

success

success

Creating new session

success( no session details )

failure

failure

success

success

failure

failure

success

Figure IV-9: Level 2 State Diagram – Serving Client


55

4.3 Class Diagrams

Client/User

: User Key : Session Key

(from Logical View)

Master User (from Logical View)

Session

: Master User : Slave User : Image : Session Key

(from Logical View)

n

1

Slave User (from Logical View)

n

n

User Key 1 n

Session Key

n

n Server

: Session : Client/User

1

n

1

n

Image 1 n

1

1

Figure IV-10: Level 1 Class Diagram

Remote Visualisation System V. System Architecture

56

V. System Architecture

1 Overview

This chapter defines the software architecture of the Remote Visualisation System

(RVS) Server. Its purpose is to ensure that the business goals of the system will be

met by the final design, and hence, the final product that is developed. It compares

several alternative architectures as well as justifying the selected architecture by

demonstrating how it allows the system to meet the appropriate requirements as

defined in the RVS Server SRS (Chapter IV).

The selected architecture is broken down into several components and all of these

components are discussed in the sections below.

2 Scope

This chapter aims to provide a detailed definition of an architecture for the RVS

server selected from a set of alternatives. The criteria for selecting the appropriate

architecture is bounded by the software requirements stated in the software

requirements specification (Chapter IV). The architecture does not promise to meet

requirements outside this boundary.

3 Architecture Goals

There are two basic goals of the RVS server architecture.

o To provide a high level abstract design of a system that can meet the overall

functional objectives of the RVS server.

o To provide a high level design for a system that meets the non-functional

requirements of the RVS server.


57

3.1 Functional Objectives

o To provide a facility for users to visualise and analyse images that reside on

different machine(s) at a different geographical location.

o To provide the visualisation data in a generic format so clients have

flexibility in terms of its use.

o To allow multiple users in remote locations to view a single instance of an

image concurrently.

3.2 Non-Functional Objectives

The Architecture should meet all of the following non-functional requirements of the

RVS server:

o Availability – whether the RVS server is ready to be used by clients.

o Portability – whether the software written for the RVS server can be executed

on multiple platforms without re-compiling the code.

o Scalability – the extent to which more concurrent users can be supported

when required.

o Extensibility – the ease with which the functionality can be added to the

system.

o Usability – the ease with which the server can be set up and used.

o Reusability – whether components of the software can be reused within the

application and also by other applications.

o Configurability – the ease with which the operational options of the software

can be modified by administrators and end users.

o Reliability – whether the data received from the RVS server is exactly what is

expected. That is, whether the data is accurate.

o Maintainability – the ease with bugs in the system can be fixed and upgrades

performed.

o Performance – the efficiency of the system.


58

4 Design Principals

Principals are “a set of high-level decisions that will strongly influence the integrity

and structure of the system, but is not itself the structure of the system”. (Kruchten

1995) Below are some of the principals that will be used in the design of the RVS

Server architecture.

Principal Independent Components

Description Each component is totally independent of other components.

They should run as independent processes.

Rationale

Makes the system distributed

Improves scalability

Improves maintainability

Counterargument Decrease in performance due to interprocess communication.

Principal Cohesive Components

Description

Components should only perform functions that it is

responsible for (functions that their names suggest they

perform).

Rationale

Improves re-usability since it concentrates functionality

Improves useability by making the system easier to

‘understand’.

Helps in maintenance since problems can be narrowed down to

cohesive components.

Counterargument Results in more components, which results in more processes,

which introduce greater overheads in communication.

Principal Share data storage

Description For data that needs to be shared, share the data storage

locations amongst components.

Rationale

Avoids duplication of data in the system

More efficient since physical data not passed between

components.


59

Counterargument

Need to develop access control mechanisms.

Concurrent data access threatens data integrity.

Problems can be very difficult to track/determine/resolve

Principal Separate logic from data

Description Always separate the logic of a component from its data.

Rationale

Increases flexibility by allowing data to be used by other

components if needed.

Makes the system more configurable if persistent data can be

modified without modifying code.

Counterargument More storage needed

Data access becomes very slightly slower.

5 Architecture Description

Appendix XIII.1 shows a number of alternative architectures that have been

evaluated before arriving at the final architecture. The RVS Server will be a

Distributed Architecture since the evaluation shows that the business requirements of

the system can best be met with this architecture.

Figure V-1 shows the different conceptual components that make up the system. This

view is intentionally simplistic and further break down of the components will be

done in later stages of design.


60

Command Centre

Middleware

User Manager

Middleware

Session

Middleware

Security

Middleware

DataCommunications

Manager

Middleware

Data Storage

Figure V-1: Conceptual view of RVS Server architecture

5.1 Component Descriptions

5.1.1 Command centre

o The point of access for all RVS clients

o Uses the security sub-component to manage user access rights.

o Interpret commands received from clients

o Execute user commands by interfacing with other components

o Format commands for delivery to clients

5.1.2 Security Service

o Ensuring right user access to right sessions.

o Create user and session keys

o Manage list of user keys

o Manage list of session keys


61

5.1.3 User Manager

o Manage the user process

o Process commands from the command centre

o Send messages to users (via command centre)

o Manage a list of sessions a user is involved in

o Manage a set of user specific preferences

5.1.4 Session Manager

o Encapsulate data representing single sessions.

o Manage an image canvas for the session.

o Provide access to an interface allowing operations on a canvas.

5.1.5 Data Communications Manager

o Establish connections with remote data centres.

o Obtain data from remote data centres when requested.

o Provide caching of data that is retrieved.

o Send and receive any other data required by the RVS Server from an external

source.

6 Logical View

This view aims to provide an overview of the logical components that make up the

system. (Kruchten 1995)


62

Command Centre

Security

SessionUser Manager

Data Storage

1 1

1

n

n n

n

1

1

nData Communications

Manager

n

1

n

1

n

n

Figure V-2: Logical view of RVS Server architecture

As can be seen from Figure V-2, the RVS server will consist of multiple users,

multiple sessions along with single instances of the Command Centre, Security

Service and Data Communications Manager.

One command centre exists as a point of user access and this component uses a

single security component to authorise users. Authentication mechanisms may also

be built into the security component.

7 Process View

The process view looks at the tasks (or processes) that will be executing in the

system. (Kruchten 1995) Each component of the architecture executes as an

individual process. Each RVS server deployment will have one command centre

process, one user manager process for each user accessing the server and one session

process for every session running on the server.


63

Command Centre

User Manager Session

Security

Data Communications Manager

Figure V-3: Process view of the RVS Server architecture

Executing each component as a different process allows for scalability and

extensibility. It is envisaged that this architecture may be used for other application

aside from RVS. Separating the user manager from the session process, for example,

allows the session to encapsulate the details of the application and hide it from the

user manager.

8 Development View

The development view focuses on the actual software module organisation on the

software development environment. (Kruchten 1995) Figure V-4 shows a structure

that:

o Separates code from documentation.

o Separates utility classes from the component classes.

Utility classes are those classes that may be utilised by multiple components.

Communication classes, for example, may be used by the command centre to

communicate with clients, as well as by the data centre manager to communicate

with data centres.

The primary classes for each logical component have been separated into different

packages. This helps keep the software maintainable.


64

src

util

comms

imaging

datacomms

Security

Session

CommandCentre

...

User Manager

java

rvs

corba

src

util

comms

imaging

datacomms

Security

Session

CommandCentre

...

User Manager

cpp

corba

corba

corba

corba

corba

Figure V-4: Development view of the RVS architecture

9 Physical View

It is a requirement of the RVS server to support multiple client connections at any

one time. To support multiple users and still meet the performance requirements, the

RVS server needs to be distributed across multiple nodes on a network.

There needs to be a central server that receives and transmits messages to users and

other RVS server components. Figure V-5 shows the physical distribution of

processes amongst different machines (nodes).


65

User manager 1 Session Manager 1

DataCommunications

Manager 1

Command Centre Security Service

User manager 2 Session Manager 2

DataCommunications

Manager 2

Figure V-5: Physical view of RVS Server architecture

It shows only two nodes expanding from the main node (command centre node) but

there can be many nodes to support greater number of users and sessions.

In cases where multiple users are accessing the same session, all users do not need to

be executing on the same node. However, placing them in the same node will

improve performance since data is passed around locally, and not over a network.

It is of course possible for all components reside in a single machine. The

distribution of components over different nodes is required when one machine is

being overloaded with processing. If one node can do all the work, then the overall

performance will be better if all key components reside on a single node.

Remote Visualisation System VI. High Level Design

66

VI. High Level Design

1 Overview

The purpose of this chapter is to provide a high level description of the RVS server.

It follows on from the system architecture, described in chapter I, by further detailing

each component of the server and interfaces between them.

At this stage, some critical design decisions have been made, which tie some

components of the system to particular implementation technologies. These design

decisions will be justified by considering the likely alternatives.

2 Scope

The aims of the high level design are:

o To define the major software components of the RVS server.

o To define the interfaces between the components.

o To determine how these components will work together in various scenarios.

This chapter does not go into the low level design details of the components. That is,

it does not detail the processes and the data involved in completing the services

defined by its interfaces.

3 Design Considerations

3.1 Assumptions

o It is an assumption of the high level design that all participating nodes in a

distributed environment will be connected via a high bandwidth connection.


67

3.2 Constraints

o For the most efficient design, communication between an RVS client and the

RVS server needs to be asynchronous. However, the RVS server is to be

implemented as a GRID service, which limits the communication to being

synchronous (via HTTP). Therefore, although asynchronous communication

may occur for services other than GRID services, the design needs to be able

to handle the possibility of a user communicating only synchronously with

the server.

3.3 System Environment

The RVS server will run on Linux and shall be distributed amongst at least two

computers (nodes) on a network. The main node will be the one running the

Command Centre component and all other nodes will be connected to the data centre

via a very high bandwidth connection.

3.4 Design Methodology

3.4.1 Inter-Process Communication

Some of the RVS Server components shall communicate with each other through

some form of inter-process communication (IPC) if the components are functioning

as different processes (For example, the command centre will need to communicate

with the user manager using IPC). On the Linux platform there are several forms of

low level IPC.

o Pipes

o Message Queues

o Shared Memory

o Semaphores

o Sockets


68

IPC using sockets is the only mechanism for communication between processes

running on different nodes on a network. The problem with all of the above

mechanisms, including sockets, is that that they are all very low level. This results in

a lot of steps for designers and coders in order to achieve stable, secure and efficient

communication.

Alternatives to these low level approaches are the following application level

mechanisms.

o RPC

o SOAP

o XML-RPC

o CORBA

o RMI

It is apparent that for Object Oriented and flexible architectures such as this, CORBA

will be the most appropriate communication between processes on different

processors. There following features of CORBA were decisive factors:

o CORBA is built around pure object oriented architecture

o Language independence

o Platform independence

o Mature technology

o Wide support and resources

o Standard for distributed systems

Therefore, the major components of RVS server will be separate processes

communicating with each other using CORBA.


69

Command Centre

CORBA

User Manager

CORBA

Session

CORBA

Security

CORBA

DataCommunications

Manager

CORBA

Data Storage

Figure VI-1: Communication between distributed RVS Server processes

4 Distributed Environment

As mentioned in 3.4.1 CORBA will be the glue that holds together the RVS server’s

distributed environment. A command centre will be the central point of contact for

all uses of the RVS server. The command centre then has one of two options:

o Call the User Manager Invocation Service (UMIS) to create a User Manager

Service for a new user.

o Call the Session Invocation Server (SIS) to create a new Session.

o Send commands to user manager / session to satisfy the user command.

4.1 User Manager Invocation Service (UMIS)

A UMIS is special part of the user manager component that will be used by

command centres to create User Managers for new RVS users. It is an application


70

running on a networked server that offers a CORBA interface to its services. This

allows any number of UMIS applications to be distributed on multiple servers across

a network.

It is important to note that the reason for having a service such as UMIS is due to the

stateful sessions required for the RVS. For applications that are not required to

maintain user state information, the sensible solution will be to provide service

specific managers instead user specific managers. For example, instead of calling on

a user manager to convert an image to a different format, the image object can be

sent to an independent imaging service (that is distributed somewhere on the

network) to perform the conversion.

Command Centre

ORB

User manager 2

ORB

User manager 1

ORB

ORB

UMIS

Create Create

Create User

Figure VI-2: Creating user manager via UMIS

The diagram above shows a command centre instructing a UMIS to create a User

Manager. The larger dashed rectangle signifies a different node on the network. Each

of the User Managers, the UMIS and the Command Centre are all operating as

different processes in their respective node and communicating with each other

through an ORB.


71

Although multiple UMIS is allowed, there only needs to be one deployment of UMIS

per node. Therefore, each node wishing to host a User Manager shall have UMIS

running.

Once the User Managers are created, the command centre will communicate directly

with them, without going through the UMIS. This is illustrated in Figure VI-3.

Command Centre

ORB

User manager 2

ORB

User manager 1

ORB

ORB

UMIS

usercommand

usercommand

Figure VI-3: UMIS and User Managers during normal operation

4.1.1 Session Invocation Service (SIS)

The SIS is a special service that is part of the Session component. Its purpose is

almost the same as that of the UMIS, with the difference being the SIS creates

Session processes (when requested) instead of User Managers.

5 Components

The following section is a break down of all the architectural components in the RVS

Server. The purpose and the responsibilities of each component are identified as well

as the software interface exposed by the components.


72

5.1 Command Centre

5.1.1 Identification

RVS Command Centre

5.1.2 Component Type

HTTP Soap Service

5.1.3 Purpose

The purpose of the command centre is to act as the connection point for all RVS

clients. The services offered by the RVS Server will be limited by the operations

available on the command centre.

5.1.4 Function

o Receiving SOAP commands from clients

o Initiate security checks on each command.

o Forward commands to appropriate user components.

o Call distributed objects to perform actions required to process commands

o Format and send SOAP responses to clients

5.1.5 Sub Components

The Command Centre will be made up of two components:

o The SOAP Interface – that performs all SOAP-related operations.


73

o CORBA communications – that performs all the CORBA communication

with other distributed components.

5.1.6 Dependencies

The Command Centre relies on the following components to perform its operations:

o Security Service – used to authorise (and maybe authenticate) users when the

Command Centre is accessed.

o User Manager – used for user management

o Session Manager – used for managing sessions

o Data Communications Manager – used for communicating with data centres

when acquiring remote images.

5.1.7 Interfaces

Return type Operation

boolean exit ()

long createNewSession ()

boolean joinSession (long sessionKey)

boolean quitSession (long sessionKey)

boolean switchToSession (long sessionKey)

long getCurrentSessionKey ()

int addRemoteImage (String url, String type)

boolean removeImage (int id)

ImagePosition getPositionInfo (int imageId, double x, double y)

String getPosInfo (int imageId, double x, double y)

String getImageOptions (int imageId)

String setImageOptions (int imageId, String options)

String getOutputImage ()

boolean setOutputSize (int width, int height)


74

int[] getOutputSize ()

boolean waitForImageUpdate (long maxWait)

int drawLine (double[] x, double[] y, boolean

arrowEnd)

int drawPolyline (double[] x, double[] y)

int drawOval (double x, double y, int width, int

height)

int drawText (double x, double y, java.lang.String

text)

boolean zoom (double[] x, double[] y)

boolean unzoom ()

int getChannelCount (int imageId)

boolean gotoChannel (int channel)

boolean setColormap (int imageId, String colormap)

String[] getColormaps ()

String getLastError ()

Table VI-1: Command Centre Interface

5.2 Security Service


RVS Security Service


CORBA Service


75

5.2.3 Purpose

The purpose of the security service is to control the access to the other components

of the RVS Server (except Command Centre).

5.2.4 Function

o Create new User Managers when requested

o Create new Sessions when requested

o Create user keys

o Create session keys

o Maintain a list of users and their keys.

o Maintain a list of sessions and their keys.

o Authorise user keys for access to the RVS Server components.


The Security Service has no sub components.

5.2.6 Dependencies

The Security Service relies on the following components to perform its operations:

o User Manager – used to service users in the system

o Session Manager – use to create and manage sessions in the system

5.2.7 Interfaces

Return Type Operation

boolean removeUser (UserMgr userMgr)

UserMgr getUser (UserKey userKey)

RVSSession createSession (UserMgr userMgr)


76

boolean joinSession (UserMgr userMgr, SessionKey sessionKey,

boolean makeCurrent)

boolean quitSession (UserMgr userMgr, SessionKey sessionKey)

boolean quitAllSessions (UserMgr userMgr)

UserKey generateUserKey (long value)

SessionKey generateSessionKey (long value)

Table VI-2: Security Service interface

5.3 User Manager


RVS User Manager


CORBA Service

5.3.3 Purpose

The purpose of the user component is to represent a single user of the system and

hold data (or links to data) specific to each user.

5.3.4 Function

o Listen for commands from command centre and service those commands.

o Manage a set of user preferences.

o Manage a list of sessions that the user is part of.


77


The User Manager consists of the following sub components:

o User Manager Invocation Service (UMIS) – used by command centre to

invoke (create) new user managers and to remove user managers from the

system.

o User Manager – used to encapsulate a single user in the system. All user

specific data, such as preferences, is stored here.

5.3.6 Dependencies


o Session Manager – used when a user joins a session. The User Manager holds

a list of sessions that the user is part of.

5.3.7 Interfaces


UserMgr createNewUser(UserKey userKey)

UserMgr getUserMgr (UserKey userKey)

boolean killUserMgr (UserKey userKey)

int getVacancies ()

int getUserMgrCount ()

long getCreationTime (UserKey userKey)

Table VI-3: UMIS Interface


void addSession (RVSSession session, boolean makeCurrent)

RVSSession getCurrentSession ()


78

SessionKey [] getSessionList ()

RVSSession switchToSession (SessionKey sessionKey)

boolean quitSession (SessionKey sessionKey)

short getSessionCount ()

boolean setPreference (String name, String value)

String getPreferenceValue (String name)

Table VI-4: User Manager interface

5.4 Session Manager


RVS Session Manager


CORBA Service

5.4.3 Purpose

The purpose of the Session Manager is to provide and manage all the session related

functions of the RVS server.

5.4.4 Function

o To create new sessions upon request

o To hold all data associated with a session

o To maintain the integrity of session data during concurrent user access.

o To provide session related services to other components.


79


The Session Manager consists of the following sub components:

o Session Invocation Service (SIS) – used by the command centre to invoke

(create) new sessions and to remove existing sessions from the system.

o Session – represents and encapsulates data for a single session in the system.

5.4.6 Dependencies


o User Manager: used when a user joins a session. The Session Manager is

required to hold list of users that are part of (have joined) each session.

5.4.7 Interfaces


RVSSession createNewSession (SessionKey sessionKey)

RVSSession getSession (SessionKey sessionKey)

boolean killSession (SessionKey sessionKey)

long getVacancies ()

long getSessionCount ()

Table VI-5: SIS Interface

Return Type Operation void addUser (UserMgr userMgr) void removeUser (UserKey userKey) UserMgr getMasterUser () boolean isMaster (UserKey userKey) boolean setMaxUsers (int maxUsers, UserKey userKey) int userCount ()

Table VI-6: Session Interface


80

5.5 Data Communications Manager


RVS Data Comms Manager (DCM)


CORBA Service

5.5.3 Purpose

The purpose of the DCM is to provide other RVS components with easier

connectivity to remote data.

5.5.4 Function

o Download and return data from HTTP Servers.

o Download and return data from secured or unsecured FTP servers.

o Upload data to secured or unsecured FTP servers.


The DCM has no sub components.

5.5.6 Dependencies

The DCM has no dependencies on other components.


81

5.5.7 Interfaces


boolean getFileAsAnonymous (String url, String filename)

boolean getFileAsUser (String url, java.lang.String filename, String login, String password)

boolean uploadFile (String filename, String login, String password, String url, String location)

Table VI-7 Data Comms Manager interface

Remote Visualisation System VII. Low Level Design

82

VII. Low Level Design

1 Overview

The purpose of this Low Level Design (LLD) is to detail each of the RVS

components outlined in the High Level Design (HLD). The HLD in chapter VI

describes each of the architectural components and defines their purpose along with

the interfaces to the components.

The following sections describe how each component will be designed so that it can

provide the services offered by their interfaces. Class diagrams will be used to

provide a stepping stone form LLD to implementation.

2 Technology Selection

The following software technologies will be utilised for the development of the RVS

Server.

Software Description

Apache Tomcat A Java based Web Server

JacORB A Java implementation of CORBA

TAO A C++ implementation of CORBA

Apache Axis A Java SOAP Library

Xerces Java A Java XML library

Xerces C++ A C++ XML library


83

3 Components

3.1 Command Centre

The command centre will be a SOAP Service that will run inside a web server. When

a user performs an operation, the RVS SOAP Service (which I will refer to as RVS

Service) communicates with the other RVS Components to service the users request.

3.1.1 Session Management

Sessions will be used to help identify each user when a SOAP operation is

performed. Note, that this is different from the Session that managed by the Session

Manager component of the RVS. The Session Manager encapsulates a single

visualisation session for the user. All clients and users are unaware of this

mechanism. The session management referred to here is the way in which we

identify the user that requests an operation. This is exactly like using cookies to

identify a user on the web.

Since SOAP uses the HTTP communication protocol, cookies is one way the user

can be identified. Another way is to place a unique session id inside the SOAP

header instead of the HTTP header. In this case the SOAP header in the initial

message sent by the RVS Service will look something like:

<soapenv:Header>

<ns1:sessionID soapenv:actor=""

soapenv:mustUnderstand="0"

xsi:type="xsd:long"

xmlns:ns1= "http://xml.apache.org/axis/session">

-1919645576528915916

</ns1:sessionID>

</soapenv:Header>


84

The SOAP header session management style has been selected over the cookie style

of session management because SOAP can be used with other protocols besides

HTTP. Cookies are only a HTTP concept.

3.1.2 Class Diagrams

RVSService

$ sessionTimeout : int = 1200

exit() : booleancreateNewSession() : longjoinSession(sessionKey : long) : booleanquitSession(sessionKey : long) : booleanswitchToSession(sessionKey : long) : booleangetCurrentSessionKey() : longaddRemoteImage(url : String, type : String) : intremoveImage(id : int) : booleangetPositionInfo(imageId : int, x : double, y : double) : ImagePositiongetPosInfo(imageId : int, x : double, y : double) : StringgetImageOptions(imageId : int) : StringsetImageOptions(imageId : int, options : String) : StringgetOutputImage() : StringsetOutputSize(width : int, height : int) : booleangetOutputSize() : int[]waitForImageUpdate(maxWait : long) : booleandrawLine(x : double[], y : double[], arrowEnd : boolean) : intdrawPolyline(x : double[], y : double[]) : intdrawOval(x : double, y : double, width : int, height : int) : intdrawText(x : double, y : double, text : java.lang.String) : intzoom(x : double[], y : double[]) : booleanunzoom() : booleangetChannelCount(imageId : int) : intgotoChannel(channel : int) : booleansetColormap(imageId : int, colormap : String) : booleangetColormaps() : String[]getLastError() : String

(from commandcentre)

RVSInterface

exit()createNewSession()

joinSession()quitSession()

switchToSession()getCurrentSessionKey()

addRemoteImage()removeImage()

getPositionInfo()getImageOptions()setImageOptions()getOutputImage()setOutputSize()getOutputSize()

waitForImageUpdate()drawLine()

drawPolyline()drawOval()drawText()

zoom()unzoom()

getChannelCount()gotoChannel()setColormap()

getColormaps()getLastError()

(from commandcentre)

Figure VII-1: Command Centre class diagram

The interface defined in the HLD for the Command Centre has been realised in a

Java interface called RVSInterface. Such a generic name is used because this

interface, in fact, defines the RVS’s interface to the outside world (clients).

The RVSService implements the RVSInterface. This is the class that gets called

when a user performs a SOAP operation. The RVSCORBAService is another

implementation of the RVSInterface. This provides a CORBA interface to the RVS.

This allows a client to use the RVS Server via SOAP or via CORBA.


85

The RVSService uses the RVSCORBAService to service user requests, since

CORBA is the only way of communicating with other RVS components.

3.2 Security Service

The security service will be a CORBA service implemented in Java. Its major

purpose initially will be to manage the creation and deletion of sessions and user

managers. The Command Centre will use the Security Service to perform these

operations. Although this way of creating sessions and user managers is not

necessary, it will be done this way because a certain amount of care is required to

ensure that all resources are released and re-used appropriately.


86

3.2.1 Class Diagrams

SecurityServiceOperations

createUser()removeUser()

getUser()createSession()joinSession()quitSession()

quitAllSessions()generateUserKey()

generateSessionKey()

(from security)SecurityServiceHolder

SecurityServiceHolder()SecurityServiceHolder()_type()_read()_write()

(from security)

SecurityService(from security)

+value

SessionKeyImpl

keyValue : long

SessionKeyImpl()getKeyValue()

(from security)

UserKeyImpl

keyValue : long

UserKeyImpl()getKeyValue()

(from security)

UserKeyOperations

getKeyValue()

(from security)

SessionKeyOperations

getKeyValue()

(from security)

Figure VII-2: Security Servi ce class diagram

The UserKey and SessionKey are very simple classes that initially will store just a

long value. These long values will be used by the Command Centre to identify users

with their appropriate User Managers and RVS Sessions.

3.3 User Manager

The User Manager will be a CORBA service implemented in Java. It is responsible

for storing all user specific information in the RVS. The get and set preferences


87

functions, for example, store string based preferences that may be used across

multiple sessions.

Unlike the Security Service, the User Manager needs to create one instance of itself

for each user. For this reason, the User Manager Invocation Service (UMIS) will be

the service that creates the individual User Managers in the system.

3.3.1 Class Diagram

Server

$ maxUsers : int = 20

main()

(from usermanager)

UserMgrOperations

getUserKey()addSession()

getCurrentSession()getSessionList()

switchToSession()quitSession()

getSessionCount()setPreference()

getPreferenceValue()

(from usermanager)

UserMgrHolder

UserMgrHolder()UserMgrHolder()_type()_read()_write()

(from usermanager)

UserMgr

(from usermanager)

+value

UMISOperations

createNewUser()getUserMgr()killUserMgr()

getVacancies()getUserMgrCount()getCreationTime()

(from usermanager)

UMISHolder

UMISHolder()UMISHolder()_type()_read()_write()

(from usermanager)

UMIS

(from usermanager)

+value

Figure VII-3: User Manager class diagram


88

As can be seen, this is a very simple component. It consists of the UMIS class and

the UserMgr class. A UMIS creates and returns a UserMgr when required via the

createNewUser function call.

3.4 Session Manager

The Session Manager will be a CORBA service implemented in C++. It is in this

component that the bulk of the image processing occurs.

3.4.1 Class Diagram

RVSCanvasImpl

RVSCanvasImpl()setPixelCanvas()~RVSCanvasImpl()getPixelCanvas()createNewDD()deleteDD()getDisplayData()refresh()drawLine()drawPolyline()drawOval()drawText()deleteAnnotation()getWorldPosition()operator ()()zoom()unzoom()gotoChannel()installPositionEH()

(from canvas)

SessionImpl

SessionImpl()getSessionKey()~SessionImpl()addUser()removeUser()getMasterUser()isMaster()setMaxUsers()

(from sessionmgr)

SISImpl

SISImpl()createNewSession()~SISImpl()getSession()killSession()getVacancies()getSessionCount()findSession()

(from sessionmgr)

RVSSessionImpl

RVSSessionImpl()getCanvas()~RVSSessionImpl()getSessionKey()addUser()removeUser()getMasterUser()isMaster()setMaxUsers()userCount()

(from sessionmgr)

PCEventDispatcher

PCEventDispatcher()dispatchRefreshEvent()~PCEventDispatcher()dispatchMotionEvent()dispatchPositionEvent()

(from aips)

RemoteDisplayDataImpl

RemoteDisplayDataImpl()getOptions()~RemoteDisplayDataImpl()setOptions()getDisplayData()showPosition()showValue()addMotionEventHandler()addPositionEventHandler()removeMotionEventHandler()removePositionEventHandler()nelements()refresh()filterRecord()addHelpField()

(from aips)

0..1

1

-itsRVSCanvas0..1

1ProxyPixelCanvas

(from aips)

0..1

1

-itsEventDispatcher0..1

1

Figure VII-4: Session Manager class diagram


89

As mentioned in the earlier sections of this document, the processing of astronomy

images is a much specialised task. It would not be feasible to develop such software

in the time allocated for this project. In fact, it would be an unnecessary waste of

effort, since there are software packages that do this work already.

The RVS will use the AIPS++ Display Library (see section II.5) for all image

processing tasks.

3.5 CORBA and AIPS++ in RVS

There are a selected number of AIPS++ objects that have been ‘wrapped’ in a

CORBA wrapper making these objects distributed. That is, one process can send the

object to another process (possibly on another machine). Any process, with code

written in any language, can make calls to this object and expect the same result.

This is what CORBA allows us to do.

3.5.1 Pixel Canvas

PixelCanvas is an abstract C++ class within the AIPS++ Display Library. It acts as

an interface that can be used by AIPS++ to draw its data. There are specialisations of

the pixel canvas that implement the draw routines for a specific target. For example,

the PSPixelCanvas (postscript pixel canvas) draws to a postscript file and the

X11PixelCanvas allows drawing on the screen, via an X11 server

The RVS needs to draw image data on a Java panel and also to a PNG canvas, which

will end up outputting a PNG file. By using CORBA to create a Java based

JavaPixelCanvas object, we can not only achieve this, but also make the pixel canvas

distributed. That is, the canvas that is being drawn on can be located on another

machine to the one that is sending the draw commands. Figure VII-5 shows how the

CORBA based Java pixel canvas works.


90

IDL file

Skeleton (Java)

Stub (C++)

JavaPixelCanvas

ProxyPixelCanvas

PixelCanvas

Generates Generates

Has instance of

Inherits from

Inherits (implements)

Pixel Canvas Method calls

Output on java.awt.Graphics

object

Remote method call

Figure VII-5: Java Pixel Canvas design

The blue elements are the ones that we need to implement. The IDL file describes the

pixelcanvas interface, which is then used to generate the skeleton and stub classes.

The idl file is used by the java idl compiler to generate the java stub file. Similarly,

the c++ idl compiler is used to generate the stub file.

The JavaPixelCanvas implements the skeleton interface to draw on a java Graphics

object.

The ProxyPixelCanvas implements the existing AIPS++ PixelCanvas interface.

These implementations forward all requests to the stub. For instance, when a

drawImage(Matrix, ... ) method is called on the ProxyPixelCanvas, it does the

following:

1. Convert the Matrix into a type that the stub accepts (this is not difficult).


91

2. Call stub::drawImage(...)

Behind the scenes, the following sequence of events take place:

1. The stub calls the skeleton and sends it the drawImage method call.

2. Since the skeleton is implemented by the JavaPixelCanvas, the drawImage

method in the JavaPixelCanvas is called.

3. The JavaPixelCanvas creates an image out of the array of pixel values. To do

this, in my test application I have created a simple ColorModel (see the J2SE

API ) which is used to create the image.

4. This image is drawn, and the method returns, and so does the stub, and so

does ProxyPixelCanvas.

3.5.2 Display Data

A Display Data, in AIPS++, is a structure that encapsulates a set of data that is to be

drawn on a canvas. Before drawing an image as a raster, for example, the image is

stored in memory as a display data. Each display data has a set of options that can be

adjusted by the user. These options include:

o Colormap

o Position Tracking options

o Axis labels

In the RVS, users will want to change some of the image options at run time, via the

web service. This requires the RVS web service (written in Java) to get a hold of the

display data object (written in c++) and call its setOptions method.

To achieve this we need to again, wrap the display data object in a CORBA wrapper.

We have called this wrapper the Remote Display Data. Figure VII-6 shows the

design of the Remote Display Data and the flow of data from the user to the actual

display data object.


92

Similar to the Java Pixel Canvas shown in Figure VII-5, the blue elements are those

that have been implemented. The IDL file describes the Remote Display Data

interface that is used by the web service to make method calls to the end Display

Data object. This IDL file is compiled by the java IDL compiler into a stub file and

by the C++ IDL compiler into a skeleton file. The RemoteDisplayData class then

implements the skeleton file. Therefore, all remote method calls received by the

skeleton are forwarded on to their respective implementations in

RemoteDisplayData.

IDL file

Stub (Java)

Skeleton (C++)

Web Service

RemoteDisplayData

DisplayData

Generates Generates


Has instance of

Has instance of

User calls “set options” on the Display Data

Remote method call

Figure VII-6: Remote Display Data design

3.5.2.1 Remote Display Data Interface

The Remote Display Data interface does not implement all DisplayData methods,

since all of the methods are not required remotely. Only two methods are

implemented:

o string getOptions()


93

o boolean setOptions(in string optionsIn, out string optionsOut)

The original DisplayData object has these two methods, except the options are stored

in a Record class as opposed to a string as shown above. The strings are in fact XML

representation of an AIPS++ Record.

3.5.3 Records

A Record, in AIPS++ is a hierarchical collection of named fields of various types. A

record may contain any number of fields, any one of which may be another Record.

Display Datas use Records as a means of storing and communicating options. To

receive the current option settings from a Display Data, the options Record object

must be retrieved from Display Data. Similarly, when wanting to set new options, a

Record must be created for it and sent to the Display Data using setOptions.

To make the above requirement possible, the record must be wrapped in a CORBA

wrapper, in the same way as the Display Data was. However, this wrapper has NOT

yet been implemented. This is because there is a CORBA limitation that does not

permit method overloading in its remote interfaces and there is extensive use of

method overloading in the Record class. A little more time and effort will be required

to create the CORBA wrapper.

Not being able to distribute the Record object means that the web service can’t

obtain a reference to it. As a work around, we have developed a utility that converts

AIPS++ Record to XML format and vice versa. This allows options data to be sent as

Strings (containing XML data) instead of in Record format. On the java side the

XML string is converted to and from a JavaRecord class.


94

CORBA Interface

JavaRecord/ XML

Converter

Record/ XML

Converter

Web Service DisplayData

JavaRecord

XML String XML String

Record

Figure VII-7: XML representation of AIPS++ record

3.5.4 Event Handling

The lowest level events generated in the Display Library are:

o Position events – generated when users press a button on the keyboard or the

mouse

o Motion events – generated when users move the mouse cursor

o Refresh events – generated when a change in the data requires the ‘display’ to

be refreshed.

All three of the above events almost always originate from the pixel canvas.

However, sometimes the refresh event is generated elsewhere and sent to the pixel

canvas.

In the RVS, the java pixel canvas needs to send position, motion and refresh events

to event handlers that reside on the C++ side. One way to approach this problem

would be to wrap all events and event handlers with a CORBA wrapper as was done

with Display Data. This approach would mean overriding the ‘add’ and ‘remove’

(Event Handler) methods of the PixelCanvas in the ProxyPixelCanvas. However,

these methods are not virtual. The extensive use of polymorphism in he DL means,

this approach was not viable.


95

Instead, an EventDispatcher class has been developed to cater for events generated

by remote pixel canvases. Figure VII-8 shows the EventDispatcher architecture and

the flow of event data from the Java PixelCanvas to the event handlers of the pixel

canvas on the C++ side.

IDL file (Event

Dispatcher)

Event

Dispatcher Stub (Java)

Event Dispatcher Skeleton

(C++)

Java Pixel

Canvas

PCEventDispatcher

PixelCanvas

Generates Generates


Has instance of

Has instance of

User calls “set options” on the Display Data

Remote method call

Pixel Canvas distributes events to all its event handlers

Figure VII-8: Event dispatcher for Remote Pixel Canvas

1. When event handlers are added to a pixel canvas, the base PixelCanvas class

stores them in a list.

2. The PCEventDispatcher is created by passing it a pointer to a pixel canvas.

3. The PCEventDispatcher is then registered with the Java Pixel Canvas. The

Java Pixel Canvas will have the stub for that event dispatcher in its list.

4. When the Java Pixel Canvas wants to generate an event, it calls on the

following methods in the EventDispatcher stub:

o dispatchPositinEvent


96

o dispatchMotionEvent

o dispatchRefreshEvent

The event information is passed using CORBA object created specifically for this

purpose. These are RemotePCPositionEvent, RemotePCMotionEvent and

RemotePCRefreshEvent.

3.5.5 Data Types

One of the difficulties of distributed programming is the sharing of complex data

types between different components, which in the case of RVS are Java and C++

components. The example of sending Record object for display data options is one

example. However, there are more commonly used data types that need to be shared.

These include:

o Array

o Vector

o Matrix

o Complex

o DComplex

o String

CORBA (IDL) has a set of defined data types that map to language specific data

types. For example, the IDL type long maps to a Java and C++ type int. Float, double

and short types map directly to the same types in Java and C++.

We can also define an array (bounded array) and a sequence (boundless arrays).

These, more complex types, are used to map the list of AIPS++ types above, to IDL

types. With C++, an object of type Vector, for example, will need to be converted to

a sequence before it can be used in a distributed object such as a

RemotePixelCanvas. A utility class AipsCORBAUtil has been created to do these

conversions using static public methods.


97

3.6 Data Communications Manager

The data communications manager is a Java based CORBA service. It is a

convenience service in the RVS Server whose purpose is to provide communication

services so other RVS Server components can easily download and upload remote

data.

3.6.1 Class Diagram

Server

main()

(from dcmanager)

DataCommsMgrOperations

getFileAsAnonymous()getFileAsUser()

uploadFile()

(from dcmanager)

DataCommsMgrHolder

DataCommsMgrHolder()DataCommsMgrHolder()_type()_read()_write()

(from dcmanager)

DataCommsMgr

(from dcmanager)

+value

Figure VII-9: Data Communications Manager class diagram

Initially, the data communications manager will simply download files, given a

particular URL. Eventually, this functionality will be extended to support un-

anonymous FTP upload/download.

Remote Visualisation System VIII. Prototype Release

98

VIII. Prototype Release

1 Overview

On 18 November 2003, a prototype version of the RVS was completed. The goals of

the prototype were as follows:

o To demonstrate a ‘proof of concept’ implementation of the server. That is, to

prove that the architecture and high level design of the RVS Server were

feasible.

o To determine the technological feasibility of the server. That is, to determine

whether the different technologies can be used successfully to come up with a

good solution.

o To obtain some performance statistics and determine whether the design can

meet the performance goals of the system.

o To demonstrate the RVS to users and get feedback on areas of improvement.

2 Level of Implementation

2.1 Components

For the prototype, all the components of the RVS Server (as designed at that time)

were partially implemented. The components that made up the system at that time

were:

o Command Centre (Tomcat web server running a SOAP Service)

o Security Service (Java CORBA)

o User Manager (Java CORBA)

o Session Manager (C++ CORBA)

o Data Store (Java CORBA)

o Data Centre Manager (Java CORBA)

o Client Applet

o Client Web Application (Deployed on Tomcat)


99

2.2 Demonstration Client

2.2.1 Configuration

A demonstration client was developed to make use of the services offered by the

RVS Server. This client consisted of a Java applet that could be run inside a web

browser, somewhat similar to how the system was to be used in future. The applet

used HTTP Tunnelling to communicate with an intermediate servlet (Client Web

Application as listed earlier). This servlet then communicated with the RVS Server

using SOAP.

Client (applet)

Web Server (Servlet)

SOAP Server (Command Centre)

Firewall

HTTP Tunnelling

FirewallSOAP

CORBA

RVS Server Components

Figure VIII-1: RVS Client configuration

2.2.2 User Functions

The following, limited functions, were available to users of the RVS prototype:

o Allows the user to enter a URL to a FITS image

o When a URL is submitted, the image is displayed on the left half of the applet

o The image is always displayed with axis labels

o Allows the user to change the colour map of the image (from a list of options)


100

o If the image is a cube, allows the user to view any channel in the cube by

entering the channel number

3 Scenario Analysis

3.1 Pre-Implementation

Before the prototype was implemented, a collection of scenarios were developed.

The prototype was then implemented according to these scenarios.

3.1.1 Interactions between user, applet and the servlet

User enters username and password at home page:

1. Tomcat allows access to the target servlet, which sends a web page

containing the applet.

2. The web page is displayed on the user’s browser.

3. The applet requests (from the servlet) an array of strings specifying the

images that are available for display. These images will be located on the

Tomcat server and accessible via a URL.

4. The applet is displayed without any content. Only the image selection drop

down list is available. The status bar reads, “No image loaded”.

User selects “Image A” from the drop down list:

1. The applets activity light starts blinking and the status bar reads, “Receiving

image data”.

2. The applet requests (from the servlet) a java VOTable object that has the

image details.

3. The applet then gets the png image from the URL included in the VOTable.

This URL is stored as the image base for later use.

4. The applet asks for the options record java object (of the DD) from the servlet

5. The applet then displays the image.


101

6. The applet then parses the options record and displays them in an appropriate

form.

7. The activity light stops blinking and the status bar reads “Idle”.

User changes colour map and clicks ‘update’:

1. The activity light starts blinking and the status bar reads, “Updating

canvas…”

2. The applet sends a setImageOptions command to the servlet. This command

sends the options record and also sends the layer id of the layer that is being

operated on.

3. The servlet takes the options record and sends a setImageOptions SOAP

command to the RVS server. The options AND the layer id is sent.

4. The servlet receives a True value indicating the option has been set.

5. The servlet returns a True value to the applet.

6. The status bar changes to “update successful.”

7. The status bar changes to “downloading new image.”

8. The applet uses the stored URL of the image base to retrieve the latest image.

9. The applet displays the image.

10. The activity light is off and the status bar reads “Idle”.

3.1.2 Interaction between Servlet and RVS Server

Tomcat allows access to the target servlet, which sends a web page containing the applet:

1. The servlet registers a new user with the RVS server.

2. Servlet creates a new session on the RVS server and joins the new user in that

session.

The applet requests (from the servlet) a java VOTable object that has the image details:

1. Servlet creates a new layer in the RVS canvas.


102

2. Servlet requests ‘remote image’ to be added to the new layer. The URL for

the image is sent to the RVS server.

3. The RVS server obtains the remote image

4. RVS server creates DisplayData, PSPixelCanvas, WorldCanvas and

WorldCanvasHolder.

5. RVS server creates the ps file and converts it to png.

6. RVS server deletes the PSPixelCanvas. WorldCanvas and the

WorldCanvasHolder.

7. RVS server returns a True flag to the Servlet, indicating the remote image as

been added.

8. Servlet requests the RVSCanvas from the RVS server.

9. Servlet sends the VOTable (which is inside the RVSCanvas) to the applet.

NOTE: In the final product, the entire RVSCanvas will be sent to the applet.

The prototype is restricted to only one image (or DD) per canvas.

The servlet sends a setImageOptions SOAP command to the RVS server:

1. The RVS server takes the imageOptions and converts it to an options Record

that can be understood by DisplayDatas.

2. The RVS server retrieves the DisplayData and sets the option on the

DisplayData.

3. The RVS server then calls the refresh function on the RVSCanvas layer.

4. The RVSCanvas then creates a PSPixelCanvas, WorldCanvas and

WorldCanvasHolder.

5. RVSCanvas creates the postscript file and converts it to a png file.

6. RVS server returns a True flag to the Servlet, indicating the option has been

set.

3.2 Post-Implementation

During the implementation some details in the scenarios above were modified. For

example, instead of users selecting from a list of images to view, they may enter in a

URL to any valid FITS image. Following are a couple of scenarios that demonstrate

how the prototype worked after implementation was complete.


103

The user submits a new URL of an image to be visualised:

1. ‘Get Image’ command sent from applet to a servlet

2. The servlet sends a SOAP message to the RVS Server

3. The RVS Server downloads the remote image and writes it to disk

4. The RVS Server then gets the correct session object from the Security

component (CORBA).

5. The session object is used to load the downloaded image (CORBA). This is

when the Display Data and the PSPixelCanvas is created.

6. Still inside the session component, the postscript file generated is converted

to a PNG file using ImageMagick. This PNG file is stored at a location that is

accessible via URL.

7. The URL of the result image is sent to the servlet via a return SOAP message.

8. The servlet sends the URL of the result image to the applet. The applet

displays the image

The user submits a new colour map:

1. ‘Set co lour map’ command sent from applet to a servlet

2. The servlet sends a SOAP message to the RVS Server

3. The RVS Server then gets the correct session object from the Security

component (CORBA).

4. The session object is used to create a new PSPixelCanvas using the

DisplayData (which already exists).

5. The colour map on the DisplayData is changed to he desired colour map.

6. Still inside the session component, the postscript file generated is converted

to a PNG file using ImageMagick. This PNG file is stored at a location that is

accessible via URL.

7. The URL of the result image is sent to the servlet via a return SOAP message.

8. The servlet sends the URL of the result image to the applet. The applet

displays the image


104

4 Performance Results

One of the objectives of this prototype was to ensure that the performance

requirements of the system can be satisfied by the design. To analyse the

performance of the prototype, I decided to determine the time taken to perform a

couple of key user operations. These are:

o The time taken for a remote image to load once the users submit’s a URL.

o The time taken for a colour map to be changed and the new image to be

displayed, once the user submit’s the new colour map.

The following table shows these results, when viewing images of different sizes.

Image size (MB) Time to load image (s) Time to change colour map (s)

8.99 3.96 1.69

14.03 5.40 1.70

18.31 5.48 1.60

Table VIII-1: Time taken to perform operations

NOTE: All components (including the client and server) were on the same machine

when tested. The test data was located on a remote server with high bandwidth

connection to the RVS Server.

When changing the colour map, it was found that about 90% of the time (as

described above) was in the creation of the new PNG file. That is, about 10% of the

time was spent on data transfer, establishing context, etc. This amounts to

somewhere between 10ms to 300ms per client request.

That is, when a client makes a request to RVS Server, somewhere between 5ms and

300ms is spent in the transfer of data and establishing context for the user. In most

cases the time is less then 50ms.


105

The bottleneck seems to be in the conversion of the postscript file (generated from

PSPixelCanvas) to a PNG file. This takes between 850ms to 900ms. Ideally in the

final RVS system, this process will not be necessary. That is, the output from the

pixel canvas should be a PNG file (or a format that can be displayed on the client).

The overall performance of the system is quite satisfactory. One of the aims of this

prototype was to determine whether the overall performance objectives of the RVS

can actually be met. Even though the tests were done a single machine, these results

are promising.

5 Impact on Design

The prototype has resulted in a number of changes to the design of the RVS Server.

These changes are listed below.

o The Data Store should be removed. It is prone to errors if the CORBA

components are distributed. This occurs when all components do not share a

common file system. After further analysis it was though that the data store

component is not a necessity. File sharing can occur by simply using full

paths to file locations. There is no need to make this access transparent.

o The Data Centre Manager should be renamed to Data Communications

Manager. The Data Centre Manager performs a general task of downloading

images via a URL that is given to it. There is no specific communication with

any data centres, as was the original intention. Therefore, we should make

this component more generic by making it an interface to all remote data

access (not just to data centres). We can call this the Data Communications

Manager.

o The process of creating new users, registering them to new sessions and

managing these transactions are a little tedious. It would be better for the

security manager to perform create/delete operations.

o The session manager should not write image to a postscript file before

converting it to PNG format. This incurs an unacceptable overhead that we


106

can not afford. The image should be immediately written to a PNG file for the

user to download.

Remote Visualisation System IX. Test Report

107

IX. Test Report

1 Overview

This chapter contains the acceptance test report for the RVS. The main focus of this

project was to develop RVS Server and hence, this acceptance report is designed to

test whether the server meets all the requirements stated in the Software

Requirements Specification in chapter IV.

A number of test cases have been identified to test the different requirements of the

server. One use case may test more than one requirement. The tables below are

separated into the following columns:

o Case Id – a unique id for the test case.

o User Action – the action that the user performs.

o Expected Result – the result that is expected from the user’s action.

o Pass/Fail/NAT – Whether the test case passed, failed, or if the requirement

could not be tested

o SRS Reference – The requirements in the SRS that are tested by this test case.

o Comments – Any additional comments about the test case.


108

2 Functional Tests

Case Id User Action Expected Result Pass / Fail / NAT SRS Reference Comments

1 User starts RVS client Client window opens with session

id printed in the status bar Pass

R01, R02, R04,

R05, R17, R18,

R19, R20

2 User waits for 20 mins before

adding an image to the canvas

The operation will fail and the user

will be told that the session has

timed out

Pass R07, R08

3 User clicks on the “New

Session” button

The current session will be deleted

and a new one started Pass R09

4 User clicks the ‘share’ button

A new window should open to

allow users to enter in the session

id of another session. The user can

then view the output of that

session in another window.

NAT

R11, R12, R13,

R14, R15, R16,

R54

Cannot be tested

since this

functionality was not

implemented in the

client.


109

5

User enters a URL, selects raster

as the image type and clicks the

submit button.

The status bar indicated that the

client is communicating with the

server. Soon after, the image

should be displayed to the user.

Pass

R22, R23, R24,

R25, R34, R48,

R49, R50

6 User enters an invalid URL and

clicks submit button

An error message should be

displayed to tell the user that the

entered URL is invalid.

Pass R27

7 User enters a URL to an invalid

FITS image.



server. Soon after, the user should

be notified that the data download

was unsuccessful.

Pass R26

8

User adds a 3 dimensional image

(cube) to the canvas and selects a

single channel to view.



server. Soon after, the selected

channels image will be displayed

Pass R30


110

9

The user clicks the options

button for an image and goes to

the ‘display axes’ tab. The user

then changes the axis order and

clicks apply.



server. Soon after, an image with

the axes modified is displayed.

Pass R31

10

The user clicks on the zoom in

button (magnifying glass on ‘+’

symbol). He/She presses left

mouse button and drags a

rectangle on the image and

releases the button.



server. Soon after, the region

inside the rectangle is displayed in

full size.

Pass R32

11

User clicks on the line tool to

press and drag the mouse before

releasing at another point on the

canvas.

As the user drags the mouse a line

will appear between the points of

the button press and cursors

position.

NAT R35, R42

Annotations were not

implemented in the

demo client so this

feature cannot be

tested by the user.


111

12

User clicks on the circle tool to

press and drag the mouse before

releasing at another point on the

canvas

As the user drags the mouse a

circle is drawn, centred where the

user had pressed the mouse button.

NAT R38, R42


implemented in the

demo client so this

feature cannot be

tested by the user.

13

User clicks on the polygon and

then clicks on different points on

the canvas and the lastly on the

point of the first click

Each click on the canvas draws a

new line between that point and

the previous point, until the user

clicks on the first point again.

NAT R39, R42


implemented in the

demo client so this

feature cannot be

tested by the user.

14

User clicks on the text tool,

clicks at a point on the canvas,

and enters some text.

As the user presses keys on the

keyboard, the relevant text will

start to appear at the point where

the mouse was clicked.

NAT R40, R42


implemented in the

demo client so this

feature cannot be

tested by the user.


112

15 A user clicks on an annotation

and presses the delete key.

The annotation that was clicked is

removed from the canvas NAT R41, R42


implemented in the

demo client so this

feature cannot be

tested by the user.

16 A user submits a URL to a FITS.





Pass R43

17 A user submits a URL to tarred

AIPS++ image





Fail R43

AIPS++ images are

not yet supported by

the RVS Server

18 A user submits a URL to a

VOTable (image)





Fail R43

VOTables are not yet

supported by the RVS

Server


113

19 A user selects a local file (on the

users computer) to view


client uploading the image to the



Fail R53

The uploading of file

from client to server

is not yet supported

Remote Visualisation System X. RVS Client User Guide

114

X. RVS Client User Guide

1 Overview

The Standalone Client is Java application that allows users to visualise FITS images

by using the RVS Server. The application takes URL to FITS images and displays

the image for the user to analyse.

Users may zoom in and out of the image, change the colour map, select specific

channels in a cube to view, enable/disable axis labels and change other options of

images. The client also allows contours to be overlaid on top of raster images.

This chapter is a guide to the use of the client application.

2 Installation

Being a Java implementation, the client executes on all java enabled platforms

including Solaris, Linux and Microsoft Windows. There is no installation process for

the application besides placing the client jar file somewhere on the file system

accessible by the user.

The following are the minimum hardware and software requirements for the client:

1. Java enabled platform

2. 128MB RAM

3. JRE version 1.3.1 or higher

4. Java Web Start version 1.1 or higher (For running over the web)


115

3 Running the Client

There are a number of ways the client can be executed. It can either be started from

the command line or using Java Web Start technology to run it straight from within

the web browser.

3.1 Command Line

The client can be executed by typing the following on the command line:

java –jar democlient.jar

Where democlient.jar is the name of the client jar file.

You may also send width, height and image parameters the application. For example:

java –jar democlient.jar 700 500 http://server.com/image.fits

Starts the application with window width = 700 pixels, window height = 500 pixels

and loads the image at http://server.com/images.fits when the application begins.

3.2 Java Web Start

Java Web Start allows users to execute the RVS Client straight from within the web

browser. Doing this as simple as entering a URL in the browser window, or clicking

on a link that takes you to that URL.

The URL for starting the client using Java Web Start is as follows:

http://plexus.act.cmis.csiro:8088/rvsclient/democlient.jsp

Similar to the command line access, you may also specify width, height and initial

image parameters via the URL. For example, the following URL:

http://plexus.act.cmis.csiro:8088/rvsclient/democlient.jsp?width=700&height=500&image=http://server.com/image.fits


116

starts the application with window width = 700 pixels, window height = 500 pixels

and loads the image at http://server.com/images.fits when the application begins.

4 User Interface

The interface of the standalone client is simple and easy to use for even the most

novice users. Below is a description of three different graphical elements; the main

interface, image options and the colour map changer.

4.1 Main Interface

Figure X-1: Main interface screenshot

Figure X-1 shows a screenshot of the main application window. The table below

contains a description of the numbered items on the screenshot.

Item Number Item Name Description


117

1 Zoom In Tool

This tool can be used to zoom into an

image. When this button is depressed,

users may click and drag the mouse

pointer to create a rectangle above the

image. When the mouse is released the

zoom command is processed.

2 Image URL Entry

This text field allows users to enter a

URL of an image to be loaded. When

enter is pressed or the submit button is

clicked, the image pointed to by the

URL is loaded.

3 Image Type Selection

Users may choose to load an image as a

Raster or a contour. Typically a user

will load an image as a raster and then

overlay other images as contours.

Loading of multiple raster images is

not current permitted.

4 Submit Button

Once the URL to an image is entered in

the Image URL Entry field, the user

may click this button to submit the

URL to the server for loading.

5 Image Name

This is a name of a loaded image. By

default, the name of an image is the

URL used to load it followed by its

Image Type in brackets. The user may

modify this to be more meaningful

6 Options Button

Clicking this button opens the Image

Options window which allows users to

modify the options for that particular

image.

7 Delete Image Button Pressing this button removes that

image.


118

8 Position Display

A user may click anywhere on the

current image to have the current

position and the value displayed here.

9 Colour map Button

This button is available for raster image

types only. When pressed, the colour

map chooser dialog box is opened so

users may select the colour map to be

used.

10 Activity bar

When the client is busy, you will see a

read beam running across the activity

bar.

11 Channel Slider

When viewing a cube, the channel

slider may be used to go to a particular

channel. As the slider is dragged, the

number in the channel text field will

change according to the channel the

slider is at. When the mouse button is

released, the new channel is set.

12 Channel Text Field

This field indicates the current channel

that is being represented by the

displayed image. Users may change

this to another channel and press enter

to go to that channel. All invalid

requests will be ignored.

13 New Session Button

When this button is clicked, the current

session will be completely discarded

and a new session created. This

basically means you will you be

presented with a fresh client window

without any images loaded.

14 Exit Clicking this button will close the

application.


119

15 Status Bar The status bar displays the current

status of the application.

16 Un-zoom Tool When this button is clicked, the current

canvas is completed un-zoomed.

Table X-1: Main interface description

4.2 Image Options

Figure X-2: Image options window screenshot

Figure X-2 shows a screenshot of the Image Options window. The table below

contains a description of the numbered items on the screenshot.


120


1-5 Context Tabs

All options are categorised into

different contexts and these are

represented by one tab each. You can

display the options in each context by

clicking on its tab. The contexts and

their options are dependent on the type

of image.

6 Options Display

This is where the options for the active

tab (see 1-5) is displayed. The options

that are available depend on the image

type.

7 Close Button Clicking this button will close the

options window

8 Apply Button

Clicking this button will cause all

changes made (since the last press) to

be applied. This button is disabled if

Auto Apply is selected

9 Auto Apply

When this is enabled. Making a change

to an option will cause the change to be

applied immediately. When disabled,

any change will not be applied until the

Apply Button is pressed.

Table X-2: Image Options screenshot description


121

4.3 Colour map Selection Dialog

1

2 3

Figure X-3: Colour map selection dialog screenshot

Figure X-3 shows a screenshot of the colour map selection dialog box. The table

below contains descriptions of the numbered items in the figure.


1 Colour map List

This drop-down list can be used to

select a new colour map to be used on

the canvas

2 Cancel Button

Pressing this button will discard any

changes to the colour map (since the

dialog was opened) and close the

dialog.

3 OK Button

Clicking this button will set will set the

colour map to the currently selected

value in the list, and close the colour

map selection dialog.

Table X-3: Colour map selection dialog description


122

5 Functions

5.1 Zooming

Zooming operations can be performed by using the zoom and un-zoom tool on the

left edge of the application window.

You can zoom in to an image by firstly clicking the zoom in tool (indicated by the

magnifying glass over the + symbol). You can then click and drag the mouse pointer

over an image to create a rectangle region to zoom into. When the mouse button is

released, the zoom process will begin and you will shortly see the image resulting

from the zoom operation.

You can zoom out, to view the original un-zoomed image by clicking on the un-

zoom tool (indicated by the magnifying glass over the - symbol).

5.2 Changing Colour Maps

The RVS let’s you set different colour maps for Raster images. By clicking on the

colour map button corresponding to an image, you can select from a predefined list

of colour maps.

5.3 Viewing a Remote Image

The RVS let’s you view any valid FITS image that can be accessed via a URL.

Images can be added to the canvas by entering its URL in the text field located at the

top of the application window and either pressing enter or clicking the submit button.

The time taken to load an image depends on:

1. The size of the FITS file 2. The bandwidth between your computer and the RVS Server 3. The bandwidth between the RVS Server and the server where the file is

located.

A file is successfully loaded when you see the image drawn on the canvas and a new

entry for the image appears at to the right of the application window.


123

The RVS is currently limited to viewing a single Raster image at a time. You are not

permitted to overlay raster images.

5.4 Removing an Image

You may remove an image by clicking the delete button corresponding with the

image. When an image is successfully removed, you will notice the image is no

longer displayed on the canvas and the entry for that image (where the delete button

was located) has also been removed.

5.5 Overlaying Contours

You may display different images as contours on top of a raster image. The process

of doing this is the same as Viewing a Remote Image (see 5.3), but selecting the

image type to be a contour instead of a raster.

5.6 Position Tracking

You may click anywhere on top of an image to display the corresponding world or

pixel coordinate in the image’s Position Display area. See section 4.2 for options

relating to position tracking.

5.7 Changing Channels in a Cube

When viewing a cube, users may step to different channels by using either the

Channel Slider or by entering the channel number in the Channel Text Field. Valid

entries are between 1 (default) and n, where n = number of channels in the cube.

As the channel slider is dragged, the number in the channel text field will change

according to the channel the slider is at. When the mouse button is released, the new

channel is set. Alternatively, users may type in the channel in the text field and press

enter to go to that channel. All invalid requests will be ignored.


124

5.8 Clearing the Canvas

You can completely clear the canvas by clicking the New Session button. This will

delete all images that are currently loaded and start a new session for you.

5.9 Changing Image Options

You can change some options of an image by clicking on the image’s corresponding

Options button. This will open a new window containing the options that you may

alter.

All options are categorised into different contexts and these are represented by one

tab each. You can display the options in each context by clicking on its tab. The

contexts and their options are dependent on the type of image.

5.9.1 General Options

These options are available for all image types.

o Display axes

In this tab, adjustments can be made to select how the data is sliced for

display, i.e. which axes of the data are mapped to X and Y on the screen. The

new selection will take effect immediately if Auto Apply is selected.

Otherwise, the new selection will not take place until the Apply button at the

bottom of the adjustment window is pressed. If you have selected the same

axis for more than one display axis, then your request will be ignored, and

you should correct your error, and press Apply again.

o Hidden axes

This tab is only present when the image or array has more than three axes,

and is used to set the location in the data along all of the axes which are not

mapped to either X, Y or Z (movie) axes in the Display axes tab.


125

o Position tracking

In this tab, adjustments can be made to how the coordinates under the pointer

(mouse cursor, when clicked) are displayed. By default, position tracking is

enabled, so that when you click a mouse button with the pointer over an

image, the data value and coordinate are shown in the image’s Position

Display. You can turn position tracking off with the switch called Position

Tracking at the bottom of the tab.

Other options in this rollup are:

§ Position tracking - Absolute or relative

You may display absolute or relative (to the reference pixel)

coordinates.

§ Position tracking - World or pixel coordinates

You may display world or pixel coordinates.

§ Position tracking - Fractional or integral pixel coordinates

A data lattice is discrete, but each pixel can be considered to extend

over the range i±0.5. E.g. pixel [20, 30] in a 2D images covers the

range [19.5, 29.5] to [20.5, 30.5]. By default pixel coordinates are

presented integrally. If you like, this optional allows you to have them

presented fractionally.

§ Position tracking - Spectral unit

If the data contain a spectral axis, this menu will be included. It allows

you to select the units for the presentation of the spectral coordinates

(e.g. km/s or Hz etc). Conversion to km/s is only possible if the

Spectral coordinate contains the rest frequency. In its absence, no

conversion to km/s will be offered.

§ Position tracking - Velocity type


126

If the data contain a spectral axis, this menu will be included. If you ask

to see the spectral coordinate as a velocity, then this allows you to select

the type of velocity definition (e.g. optical, radio etc.).

o Axis labels

The parameters in this tab offer basic control over the axis labels (which by

default are visible). You can toggle them on and off by selecting True/False

for Axis labelling & annotation. The other parameters in this tab are pretty

much self explanatory, and include text entries for the axis labels and control

of whether tick marks or grid lines are drawn.

o Axis label properties

In this tab, finer control over the axis label properties is provided.

Here you have control over whether the axis labels are shown as world

coordinates or image pixel coordinates (1-relative). You may select whether

the labels are relative (to the reference pixel) or absolute.

For Direction coordinates, you may select the units of the labels if they are

relative. For Spectral coordinates you may select the units of the labels, and

the velocity type. For other Coordinate types, you don't yet have further

control over the units.

You can also choose the Direction coordinate reference type of the following

J2000, B1950, GALACTIC, ECLIPTIC and SUPERGAL. Your coordinate

grid will reflect these types.

You can also choose where to place your axis labels. The default Auto is

usually sufficient, but other placements are available.

o General


127

This tab has the parameters that most dramatically alter the generation of the

raster map itself from the image or array data. The elements of this tab are:

§ General - Aspect ratio

This option controls the dimensions with which data pixels are drawn

to the screen. Fixed lattice means data pixels will be mapped to square

pixels on the screen, in as much as the screen pixels themselves are

square. Fixed world means that the aspect ratio of the pixels according

to the coordinate system of the image will be honoured. Finally,

selecting flexible will allow the raster map to stretch independently in

each direction to fill as much of the canvas as possible.

§ General - Pixel treatment

This option controls how individual data pixels are drawn to the

screen. Selecting center means that pixels at the edge of the display

will be drawn only from the centres inwards. That is, down the left

hand border of the raster map, only the right-hand half of the pixels

will be visible, and along the bottom of the raster map, only the upper

half of the pixels will be visible. So for center, the raster map is drawn

from the center of the bottom left pixel in the selected data to the

center of the top right pixel in the selected data.

Selecting edge (the default) will change this behaviour such that all

data pixels will be drawn fully on the screen. This would be useful for

cases where only one of the display axes only has length one pixel.

§ General - Resampling mode

This setting controls how the data are resampled to the resolution of

the screen. Nearest refers to nearest neighbour resampling, where

each pixel on the screen is coloured according to the intensity of the

nearest corresponding data pixel. The alternative, bilinear (default),

applies a bilinear interpolation to produce smooth-looking images

independent of the screen pixel dimensions of the data pixels. While


128

bilinear resampling normally produces a better looking image, it can

be significantly slower than nearest neighbour resampling, so be

aware of this.

§ General - Complex mode

If the data source (image or array) is Complex, then this menu allows you

to select whether you wish to see the magnitude, phase, real or imaginary

part.

5.9.2 Raster Options

These options are available for Raster images only.

o General - Histogram equalisation

The default value for this option is False. When enabled for raster maps,

some internal optimisation of colours from the colour map (or colour

channel) is made. The number of colours allocated to a given range of data is

proportional to the fraction of pixels whose pixel intensities lie in that range.

Thus colour cells are allocated where they are needed most.

o General - Scaling power cycles

This option offers further control over the mapping of data values to colour

cells from the colour map. The overall process in selecting a colour for a

particular pixel is as follows: the data value of the pixel is clipped lie between

the data minimum and maximum as specified elsewhere in this General tab.

Then, according to this option which is described below, this clipped pixel

intensity is mapped to an index between 0 and the number of colours

available in the selected colour map. The colour which is in the colour map at

this position, which itself is controlled by the current stretch, shift, contrast,

brightness and invert settings of the colour map, is then drawn for this

particular pixel.


129

So, the scaling power cycles option controls the mapping of clipped pixel

intensities to colour look-up values. When this is set to zero, a straight line

connects (domainMin, rangeMin) and (domainMax, rangeMax) on a plot

where the domain is the input data values constrained to the range given by

the data min and max sliders, and the range runs from 1 to number of colours

in the selected colour map.

As the scaling power decreases from zero, the curve deviates from the

straight line, rising above it, such that an increasing fraction of the available

colour map is used for data values close to the data minimum. This curve is

calculated using a log function.

As the scaling power increases from zero, the curve deviates from this

straight line, falling below it, such that an increasing fraction of the available

colour map is used for data values closer to the maximum. The curve is

calculated using an exponential function.

5.9.3 Contour Options

The following options are available for contour images only.

o General - Contour scale factor

The contour levels given will be multiplied by the factor entered in this

option before being drawn.

o General - Level type

This option indicates whether the vector of contour levels, specified in the

Contour levels box, multiplied by the scale factor, are absolute levels (that is,

in the native units of the image), or are instead fractional levels, where 0 is


130

mapped to the lowest pixel intensity in the image, and 1 is mapped to the

highest.

o General - Line width

This option controls the thickness of the contour lines.

o General - Dash negative contours?

Set this option to True if you would like contours of negative values in your

data to be dashed rather than solid lines.

Remote Visualisation System XI. Conclusion

131

XI. Conclusion

The RVS is a distributed server side software system that allows users to visualise

and analyse large images that are located on a remote data archive. This is a unique

system, where the user is not required to download the image to his/her computer for

visualisation. This results in a quick and efficient display of the required data.

There is an enormous amount of astronomy data all around the world. One of the

goals of the International Virtual Observatory is to provide scientists with transparent

access to this data. That is, a scientist in one corner of the world should be able to

enter a set of query parameters and have the data from all over the world searched,

queried, processed and then presented in a form that is requested. The user should

not be concerned with the location and size of the data.

Current systems such as client side packages and the more modern systems like

Aladin (section II.5) are part way to meeting these requirements. Aladin and Oasis

provide great correlation between data from various different archives and

catalogues, but they fail to address the issue of very large dataset that will be

common in the VO. The RVS was designed to address this issue in particular, as well

as provide an architecture that is extensible to accommodate the growing needs of the

VO.

The RVS project was conducted at the Australia Telescope National Facility (a

division of CSIRO) as part of a one year employment contract. This has been only an

initial phase in the development of the RVS. The intention was to have an

operational system, but to also lay a foundation for further development. There are

already plans at the ATNF to use the RVS framework to deploy other services,

besides visualisation, to the astronomy community. It is my hope that eventually the

RVS will be utilised by other organisations to provide access to their data in the VO.

This project has been a great learning experience for me as I have had to apply

majority of the Software Engineering skills I have obtained during the course of my

degree at UTS. I have used and as a result, learnt, a host of software technologies

Remote Visualisation System XI. Conclusion

132

including SOAP, CORBA, Linux development, XML, C++ and Java. Being

responsible for a somewhat ambitious project such as this has given me valuable

experience in the software project management. I am confident that this experience

will provide a good foundation on which I can build the rest of my career.

Remote Visualisation System XII. Bibliography

133

XII. Bibliography

1. Anantharamaiah K. R, Cornwell T. J, 2004, Getting Started in AIPS++,

Associated Univserties Inc, [online] Available at:

http://aips2.nrao.edu/docs/user/gettingstarted/gettingstarted.html

2. ATNF Outreach 2004, About the ATNF, Australia Telescope Outreach And

Education [online] Available at:

http://outreach.atnf.csiro.au/about/background/

3. Australian Virtual Observatory, Astrophysics Group-School of Physics,

University of Melbourne, [online] Available at: http://www.aus-vo.org/

4. Consulting, B. 2003. Resources for Software Architects, Bredemeyer

Consulting

5. Department of Defence, Software Requirements Specification (SRS) Standard

DI-IPSC-81433, Department of Defence.

6. ESA 1995, Guide to the User Requirements Definition Phase, ESA Board for

Software Standardisation and Control (BSSC), ESA PSS-05-02 Issue 1

Revision 1, March 1995

7. Fernique P 2003, Aladin – Frequently Asked Questions, Centre de Donnees

astronomiques de Strasbourg, [online] Available at: http://aladin.u-

strasbg.fr/java/FAQ.htx

8. Glossary of Astronomy Terms, [online] Available at:

http://www.webcom.com/safezone/NAS/glossary.html

9. Hanisch, R. J. Quinn, P. J 2004, The International Virtual Observatory,

NVO, AVO.

10. Houghton, P. 2004, Patrick’s Web ASTRO – Different types of Astronomy,

[online] Available at:

http://www.btinternet.com/~patricks.web/astro/differentkinds.htm

11. IRSA 2004, OASIS Quick -Start User Guide, NASA/IPAC Infrared Science

Archive, [online] Available at:

http://irsa.ipac.caltech.edu/applications/Oasis/docs/help/quickstart.html

12. Kruchten, P. 1995, Architectural Blueprints - The "4+1" View Model of

Software Architecture, Rational Software Corp.

Remote Visualisation System XII. Bibliography

134

13. Malan, D. B. 2001, Defining Non-Function Req uirements, Bredemeyer

Consulting.

14. Malan, D. B. 2002, Software Architecture: Central Concerns, Key Decisions,

Bredemeyer Consulting.

15. Matjaz B. Juric, I. R., Marjan Hericko, 2000. Performance Comparison of

CORBA and RMI. Maribor, University of Maribor Smetanova.

16. McClure-Griffiths N 2003, Southern Galactic Plane Survey, Australia

Telescope National Facility, [online] Available at:

http://www.atnf.csiro.au/research/HI/sgps/queryForm.html

17. MIRIAD Introduction, University of Berkeley 2001 [online] Available at:

http://bima.astro.umd.edu/miriad/intro.html

18. Palu S 2003, Data Visualization in Java for Technical Computing,

developer.com, [online] Available at:

http://www.developer.com/java/article.php/1483661

19. Pence W. D 2004, A Brief Introduction To FITS , NASA, [online] Available

at: http://fits.gsfc.nasa.gov/fits_overview.html

20. Sandholm, J. G. 2003, Globus Toolkit 3 Core - A Grid Service Container

Framework , Globus.

21. Williams R, Ochsenbein F 2002, VOTable: A Proposed XML Format for

Astronomical Tables, United States Virtual Observatory (US-VO), [online]

Available at: http://www.us-vo.org/VOTable/VOTable-1-0.htm

Remote Visualisation System XIII. Appendices

135

XIII. Appendices

1 RVS Server Alternative Architectures

1.1 Overview

The RVS Server is the type of software system that may be designed in many ways.

For this reason, a number of different architectures were designed and then

evaluated. The remainder of this section outlines these alternative architectures and

demonstrates how the non-functional requirements of the system were used to

determine the best architecture.

Four alternative architecture styles have been evaluated to determine which style is

most appropriate for the RVS server. Please note, that the architectures are applied to

the RVS server only. They do not apply to the entire RVS system, which would

include clients and data centres.

The following table is used to determine the appropriateness of each architecture.

Requirements Satisfied Comments

The requirement

to be satisfied

A rating 0 and 5.

0 = Not Satisfied

5 = Fully Satisfied

Justification of the rating and other

comments.

Table XIII-1: Architecture evaluation method


136

1.2 Client – Server Architecture

User 1

User 2

User 3

ServerCommon Storage

Figure XIII-1: Client - Server architecture diagram

This architecture follows a client server model where multiple user processes are

created (one per user) and they all act as clients. There is also a server process

running for all logic and data that needs to be shared amongst different users. A user

component would request a service and the server would perform the requested

operation and return a result. For example, a user can:

o Use the server to order an image from a data centre.

o Obtain canvas or image data from the server.

o Perform a zoom on an image by calling a zoom service on the server.


Availability 3

All user components rely upon a single

server process. Downtime of server

component will always equal downtime of

the whole RVS server.


137

Portability 4

Since the number of different processes is

limited, the components don’t necessarily

need to rely too heavily on inter-process

communication. The components can be

written to be platform independent.

Scalability 3 Scalable due to multiple user components.

Extensibility 3

Although it is extensible, it’s not easy to do

so. With so much functionality bundled

into a single component, it may be difficult

to extend.

Reusability 2

The large server component makes it very

specific for its purpose. There are no

components that can be re-used for similar

purposes.

Configurability 3

The decomposition by function means the

user and the server component can each

have different configuration options.

Although, too much further configuration

of the server component can be difficult

Reliability 5

One component controlling access to all

data ensures good access control and

reliability

Maintainability 2

The server is too large a component to be

easily maintained. Need further

decomposition by functionality.

Performance 3

Server and data access may be a

performance bottleneck if two many users

are being serviced.

Table XIII-2 : Client - Server architecture analysis


138

1.3 Layered Architecture

Layer 1

Layer 2

Layer 3 Users

zoom image

get new data re-grid

Format data

Figure XIII-2: Layered architecture diagram

The layered architecture is a separation of the operations based on their level of

complexity. For example, in Figure XIII-2 a user level component calls layer 2

components telling it to zoom in on an image. User components are unaware of the

complexities of how an image is zoomed. The layer 2 components then call layer 1

components to get new image data and to re-grid the data.


Availability 2

Each layer needs to be operational for all

system functions to work. It’s also possible

that a problem in one component affects all

components in the same layer.

Portability 4

Only lower layer services may be bound to

the platform. Higher level services are

abstract, which improves portability


139

Scalability 2

Multiple users will place more burdens on

lower layers. Ultimately, the lowest of

layers will experience problems.

Extensibility 2

Adding functionality means separating that

functionality and implementing it in all

layers. This is difficult since it means

modifying interfaces.

Reusability 4

Very re-usable components because they

are broken into functional parts based on

complexity. Each service can be re-used.

Configurability 3 Dependent on high-level design. Cannot be

judged at this stage.

Reliability 5

One point of access to all data ensures

good access control and reliability. Lower

layers often access the data so the higher

layers can concentrate on business logic.

Maintainability 2 Not very maintainable since bugs and

faults can be difficult to track.

Performance 3

Performance may suffer if there are too

many layers. Data needs to pass through

multiple layers and then back again for

each operation.

Table XIII-3: Layered architecture analysis


140

1.4 Distributed Architecture

User 1

User 2

ImagingService

User 3

SessionService

Other service

Figure XIII-3: Distributed architecture diagram

A distributed architecture is similar to the client server architecture described section

1.2 except that it’s more distributed. This means that different components run as

different servers (and hence processes) and offer certain services to other

components of the system. The example in Figure XIII-3 shows user components

distributed along with an imaging service and a session service. It’s possible for all

these components to run as different processes on different processors.


Availability 4 Less change of down time since problems

are bound to the different components.


141

Portability 2

Depends slightly on implementation, but a

lot of inter-process communication results

in system specific code. Although it is

possible to use CORBA, RMI, RPC, etc to

communicate between platforms.

Scalability 4

Distributed architectures are known for

greater scalability since processes can be

spawned as demand increases. Processes

can also be spanned across multiple

processors.

Extensibility 4

Very modular, and hence, components can

be added without affecting other

components.

Reusability 4

Since all components are highly cohesive

and act as a service, they can be re-used in

different environments.

Configurability 3

Each component can be configured

independently. System-wide configuration

may be a problem since it is so modular.

Reliability 3

Reliability suffers when so many different

components behave independently. There

is greater threat to data security and

integrity.

Maintainability 5

Another common advantage of distributed

architectures is maintainability. Bugs can

easily be tracked to components and

updates can be performed on one

component without affecting another.


142

Performance 3

Dependent on implementation, but

typically distributed architectures perform

better with higher workloads, and slower

than other architectures with less

workload. This is because interprocess

communication carries a significant

overhead.

Table XIII-4: Distributed architecture analysis

1.5 Data Centric Architecture

Data Storage(Disk or memory)

User 1

User 2 User 3

Figure XIII-4: Data Centric architecture analysis

The data centric architecture models the system as a set of components that share

common data. It is similar to the client – server architecture except that the

functionality of the server is enclosed into the user components. Therefore, there is

no logic or services that are being shared by all user components. Each component is

responsible for its own operation.

Data such as images are stored in a central location (in disk or memory). The

components use locking mechanisms to control access to the data.


143


Availability 2

All users are dependent on a single source

of data. Downtime of the storage means

downtime for the entire RVS server.

Portability 4

Can be made very portable since no inter-

process communication needs to take

place.

Scalability 4

More users will put a greater burden on the

data storage. This can become a bottleneck

of the system if it cannot process requests

in time. Although, multiple users can be

spanned across processes and different

processors.

Extensibility 2

Due to the lack of modularity, adding

functions to this architecture may affect

other functions. More care is needed.

Reusability 1 Very little re-usability due to the lack of

modularity.

Configurability 2 Configurable per user only.

Reliability 2

Low reliability due to multiple processes

accessing one piece of data at one time.

More opportunities for errors to occur and

because each user component is

responsible for itself, errors can go

undetected.

Maintainability 3

Overall system is easy to understand but

complexities may arise with bug fixing.

Faults often cannot be narrowed to

individual components.

Performance 5

Extremely efficient due to the time saved

in communicating between multiple

components.

Table XIII-5: Data Centric architecture analysis


144

1.6 Summary

Table XIII-6 below summarises the data in the above sections. The values represent

the raw points obtained by the architectures without considering the importance of

each requirement that the points were obtained for.

Requirement Client - Server

(Raw)

Layered

(Raw)

Distributed

(Raw)

Data - Centric

(Raw)

Availability 3 2 4 2

Portability 4 4 2 4

Scalability 3 2 4 4

Extensibility 3 2 4 2

Reusability 2 4 4 1

Configurability 3 3 3 2

Reliability 5 5 3 2

Maintainability 2 2 5 3

Performance 3 3 3 5

Total 28 27 32 25

Table XIII-6: Summary of architecture analysis

The summary shows the distributed architecture to be most suitable assuming that

each requirement is equally as important, which isn’t the case. Table XIII-7 shows

the weighting of each requirement. These values are determined by considering the

importance of each requirement to the RVS server. The RVS-S-SRS document as

was used to as guide for these values.

Requirement Requirement Weight

Availability 4

Portability 2

Scalability 4

Extensibility 4

Reusability 3


145

Configurability 4

Reliability 5

Maintainability 3

Performance 5

Table XIII-7: Architecturally significant requirement weight

Using the weightings, the points gained by the architectures for each requirement can

be normalised. Table XIII-8 shows a summary of the normalised points earned by the

architectures.

Requirement

Client - Server

(Normalised)

Layered

(Normalised)

Distributed

(Normalised)

Data - Centric

(Normalised)

Availability 12 8 16 8

Portability 8 8 4 8

Scalability 12 8 16 16

Extensibility 12 8 16 8

Reusability 6 12 12 3

Configurability 12 12 12 8

Reliability 25 25 15 10

Maintainability 6 6 15 9

Performance 15 15 15 25

Total 108 102 121 95

Table XIII-8: Normalised result of architecture analysis

Using the points Ð weight system of selection it is evident that the distributed

architecture is most appropriate for the RVS server.


146

2 Analysis of Architecture using Use Case Diagrams

The following use case diagrams were used to analyse the initial software

architecture of the RVS Server. The goal was to use common user scenarios to

determine the events that occur on the RVS Server as a result of user operations.

NOTE: This analysis was performed in the initial iteration of the architecture. Some

components were removed and design decisions altered after the prototype

evaluation.

Client

(from Actors)

register new user

Create new user

UserManager

(from Actors)

CommandCentre

(from Actors)

register new user

Security

(from Actors)

Figure XIII-5: Use case - new user registers


147

UserManager

(from Actors)

Session

(from Actors)

Security

(from Actors)

Client

Create session

(from Business Use-Case Model)

Join session

Register update listener

Join session Create session


<<include>>

The command centre registers as an update listener so that it is notified when an update in the session has occured.

The client creates and joins a session

CommandCentre

(from Actors)

Authorise user


Figure XIII-6: Use case - user joins a session


148

DataCentre

(from Actors)

Store file DataStore

(from Actors)

Security

Get file

Store file

Session

Client

get image from URL

add image to session

Send update event

(from User zooms an image)

Authorise user


get image from URL<<include>>

The data centre stores the received file in the datastore for the session to retrieve

The client requests that an image be retrieved from the given URL and added to the canvas (inside the current session)

CommandCentreAuthorise user


Figure XIII-7: Use case - user requests remote image


149

DataStore Store file

(from User opens remote image)Session

Security

Client

Zoom image

Send update event

Authorise user


Zoom image

The session zooms the image and stores the result in the DataStore

The update event is sent to notify all listeners that the canvas has been updated.

The client requests that an image be zoomed in to the specified region

CommandCentre

(from Actors)

Authorise user


<<include>>

Figure XIII-8: Use case - User zooms image


150

Client

(from Actors)

Security

(from Actors)

Authorise user

(from Business Use-Case Model) Add FITS image to canvas<<include>>

Authorise user


add image to session

(from User opens remote image)

CommandCentre

(from Actors)

Session

(from Actors)

Store file


Get file


DataStore

(from Actors)

The user views a FITS image located on client computer

Figure XIII-9: Use case - User views local image


151

Client

(from Actors)

Security

(from Actors)

Create new layer

Authorise user


Authorise user


<<include>>

CommandCentre

(from Actors)

Session

(from Actors)

Create new layer

The user creates a new layer on the canvas

Figure XIII-10: Use case - User creates new layer


152

Client

(from Actors)

Security

(from Actors)

Get statisticsAuthorise user


<<include>>

Authorise user

(from Business Use-Case Model)CommandCentre

(from Actors)

Session

(from Actors)

Get statistics

The user asks for the statistics of a region inside an image

Figure XIII-11: Use case - User obtains image statistics


153

DataStore

Store file


Client

(from Actors)

SecuritySession

change axis orderAuthorise user


<<include>>

Authorise user


change axis orderCommandCentre

(from Actors)

User rotates an image on the canvas

Figure XIII-12: Use case - User rotates image


154

Security

Client

(from Actors)

Authorise user


Authorise user


Set new resolution<<include>>

CommandCentre

(from Actors)

Set new resolution

UserManagerSessionSet new resolution

The user changes the image resolution it wants to receive from the RVS server

Figure XIII-13: Use case - User changes image resolution


155

DataStore

Store file


Client

Security

Session

Draw circle

Authorise user


Draw circle

The user draws a circle by specificying a centre and radius

CommandCentre

(from Actors)

Authorise user


<<include>>

Figure XIII-14: Use case - User draws circle


156

Client

(from Actors)

get last errorAuthorise user


<<include>>

CommandCentre

(from Actors)

Authorise user


Security

(from Actors)

The user requests to view the last error generated by the RVS for the user

Figure XIII-15: Use case - User views last error


157

Client

Security

View canvas

Authorise user

(from Business Use-Case Model)Retrieve canvas

SessionGet file


DataStore

CommandCentre

(from Actors)

Authorise user


<<include>>

The user requests the entire canvas including the image to be displayed, the coordinate systems, the layers, annotations, etc.

Figure XIII-16: Use case - User requests canvas


158

Session

Security

Send update event


get session slaves

Client

CommandCentre

(from Actors)

Slave Client

Send update event


The session is modified and so an update is sent to all slave clients

Figure XIII-17: Use case - Slave User Gets Update


159

Client

Security

Switch to different session

Authorise user


UserManager

Switch to different sessionCommandCentre

(from Actors)

Authorise user


<<include>>

The user switches to a quanta session that he/she created earlier

Figure XIII-18: Use case - User switches to Quanta session

3 Impact of Requirements Change

3.1 Purpose

On 4th June 2003, a major requirements changed had been proposed. This analysis

report was created before the change was finalised. It contains some of the design

issues that need to be considered when add the requirement. The requirement is as

follows:

“The RVS Server shall support multiple clients viewing a single instance of an

image. This will allow, for example, user A to view and manipulate an image while

user B and user C can both view the changes being made by user A.”


160

3.2 Design Issues

Following are some of the design issues we’ll need to consider if we want to make

concurrent image sharing a requirement of the RVS. If we do decide to add this as a

requirement, then the initial design will need take this into consideration. Adding it

in later will be too difficult.

o If the image on all clients (connected to one session) need to appear identical:

§ Then the image sent to clients need to be pre-rendered (using a colour

map), or

§ The colour map to be used has to be sent to the client so the client can

render it.

o We’ll need command from server to clients for setting a new position. If a

‘master’ client track’s to a new position, that new position needs to be seen

with other ‘slave’ clients.

o It might be good have a message log so clients can pass messages to one

another. It depends on how we want the system to be used. Two users may

talk on the phone and share images on the computer, which would eliminate

he need for message passing.

o There needs to be a locking mechanism on the RVS server. The instance of

the image that is being manipulated needs to be locked for write access to

only one client.


161

Figure XIII-19: Session sharing - one instance for all clients

Client 1 has read/write access to the instance of the image. Client 2 can only read the

instance of the image. If the colour map is changed in client 1, then client 2 will be

updated to reflect this change. I.e. what you see in client 1 is what you get in client 2.

Alternatively we can have concurrent changes to an image.

Client 1

(Master)

Client 2

(Slave)

Instance

Image

RVS Server

Client 1

(Master)

Client 2

(Slave)

Instance 1

Instance 2

Image

RVS Server


162

Figure XIII-20: Session sharing - once image instance per user

The most of the properties of instance 1 and instance 2 will mirror each other, but if

client 1 changes the colour map it’s using, then client 2 will be told that the colour

map on client 1 has changed, but client 2 has the option to use a different one. Client

2 will have an option to ‘sync’ its instance of the image to that of client 1.

The design in Figure XIII-19 will take more time and effort to implement. It will also

use more resources, since each client will have instance of the image. However, for

flexibility and scalability reasons, it seems like the way to go.

o We also need to consider whether control can be switched between clients, so

can client 2, for example, become the master and client 1 the slave? How this

is done will require some coordination.

o This new requirement of sharing images will mean a little more work for the

client developers. Keeping a slave client in sync with a master will require

some ‘auto-update’ option in the client.


163

4 RVS Project Schedule

Task Duration Start Date Description Finish Date

RVS SRS 15 days

9/06/2003

8:00 RVS Software Requirements Specification 27/06/2003 17:00

RVS Software

Architecture 18 days

30/06/2003

8:00

Create a High Level Design (HLD) document

that defines all the software components of the

RVS server and also the interfaces between

them. 23/07/2003 17:00

Architecture research 5 days

30/06/2003

8:00 Research on software architecture.... 4/07/2003 17:00

Determine Alternatives 5 days

7/07/2003

8:00

Document the alternative architectures that can

be used 11/07/2003 17:00

Analyse Alternatives 5 days

14/07/2003

8:00

Analyse the alternative architectures (pros and

cons) 18/07/2003 17:00

Architecture Selection 2 days

21/07/2003

8:00

Select an architecture from the alternatives and

justify selection 22/07/2003 17:00

Architecture Traceability 1 day

23/07/2003

8:00 Trace the architecture back to the requirements 23/07/2003 17:00


164

RVS High Level Design 27 days

24/07/2003

8:00 29/08/2003 17:00

HLD Research 3 days

24/07/2003

8:00

Research into what goes in High Level Design

and how it can be derived from Architecture 28/07/2003 17:00

Determine software

components 2 days

29/07/2003

8:00

Determine what the different components of

the software system will be. 30/07/2003 17:00

Define components 4 days

31/07/2003

8:00

Document the purpose and function of each

component. 5/08/2003 17:00

Perform Use Case analysis 5 days

6/08/2003

8:00

Perform Use Case analysis on each of the tasks

that the user will perform. This will help in

defining the interfaces between components. 12/08/2003 17:00

Define component

interfaces 10 days

13/08/2003

8:00 Define the interfaces between components 26/08/2003 17:00

HLD Traceability 3 days

27/08/2003

8:00

Document how the HLD traces back to the

architecture and hence, the requirements 29/08/2003 17:00

RVS Prototype 57 days

1/09/2003

8:00 Develop a prototype for ADASS XIII 18/11/2003 17:00

Environment Setup 30 days

1/09/2003

8:00 10/10/2003 17:00


165

Server Low Level Design 3 days

10/10/2003

13:00 Low level design of the RVS server prototype 15/10/2003 12:00

Server Implementation 11 days

16/10/2003

8:30 31/10/2003 8:30

Server Testing 2 days

31/10/2003

13:00 4/11/2003 12:00

Client Design 3 days

3/11/2003

13:00 6/11/2003 12:00

Prototype Client

Implementation 7 days

6/11/2003

8:30 17/11/2003 8:30

Client Testing 2 days

17/11/2003

8:00 18/11/2003 17:00

RVS Low Level Design 38 days

19/11/2003

8:30

Create a Low Level Design (LLD) document

that details how each component of the RVS

server will operate. 15/01/2004 8:30

LLD Research 2 days

19/11/2003

8:30

Research into what goes in a Low Level

Design Document and how it can be derived

from HLD 21/11/2003 8:30

Component Design 35 days 24/11/2003 Low Level detail of all the components of the 15/01/2004 8:30


166

8:30 RVS

RVS Implementation

68.94

days

4/12/2003

8:00

This task is the implementation of the RVS

Server software. 12/03/2004 16:30

Implementation Research 3 days

4/12/2003

8:00

Research on how to approach the

implementation and what resources are needed. 8/12/2003 17:00

Develop Components 66 days

8/12/2003

8:30 Develop the RVS Server Components 12/03/2004 16:30

RVS Testing

74.94

days

1/01/2004

8:30 - Units tests of each component... 15/04/2004 16:30

Unit Testing

60.76

days

1/01/2004

8:30 Test the individual RVS server components 8/04/2004 16:58

Integration Testing 5 days

8/04/2004

16:30 Test the whole system together with the client 15/04/2004 16:30

RVS Documentation 10 days

1/04/2004

16:30 Create an API doc for server developers... 15/04/2004 16:30

Client Design 2 days

12/03/2004

16:30 Design of the RVS Demo Client 16/03/2004 16:30

Client Implementation 17 days

16/03/2004

16:30 Implementation of RVS demo client 8/04/2004 16:30


167

Client Testing 5 days

8/04/2004

8:30

Unit testing and Integration testing of RVS

demo client 15/04/2004 8:30

Client Documentation 5 days

26/04/2004

8:30 - Create user guide for the RVS demo client 3/05/2004 8:30

Acceptance testing 4 days

15/04/2004

16:30

Use the requirements validation matrix in the

SRS to see if all requirements have been met 21/04/2004 16:30

User (Beta) testing 15 days

21/04/2004

16:30

Let the users run beta tests on the system and

report bugs 12/05/2004 16:30

Bug Resolution 15 days

21/04/2004

16:30 Resolve any bugs found during user testing 12/05/2004 16:30

Software Setup 5 days

13/05/2004

8:30 Setup software infrastructure for RVS 20/05/2004 8:30

CVS Setup 2 days

13/05/2004

8:30 Make RVS available via CVS 17/05/2004 8:30

Bugzilla Setup 3 days

17/05/2004

8:30 Setup Bugzilla as a Bug Reporting system 20/05/2004 8:30

Enhancements 3 days

20/05/2004

8:30 Make any enhancements to RVS 25/05/2004 8:30

Table XIII-9: Task List for RVS Project


168

Figure XIII-21: RVS Gantt Chart

remote visualisation system - australia telescope national facility

Documents