+ All Categories
Home > Documents > Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The...

Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The...

Date post: 10-Mar-2018
Category:
Upload: vutu
View: 212 times
Download: 0 times
Share this document with a friend
69
School of Computer Science Relational User Interface Final Report Supervisors: Dr Shayne Flint Dr Ramesh Sankaranarayana Student: Jeff Stiff (u4689321) Course: COMP8790 Software Engineering Project Semester: Two, 2010 Version: 1.0 Version Date: 27 October 2010
Transcript
Page 1: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

School of Computer Science

Relational User Interface

Final Report

Supervisors: Dr Shayne Flint

Dr Ramesh Sankaranarayana

Student: Jeff Stiff

(u4689321)

Course: COMP8790 Software Engineering Project

Semester: Two, 2010

Version: 1.0

Version Date: 27 October 2010

Page 2: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Abstract

User Interfaces on Computer Operating Systems have remained essentially unchanged since the first Graphical User Interface (GUI). Graphical components and quality have increased since the first mainstream GUI in 1981 with the Xerox 8010 Star, but the basic concept of representing the files as objects and storing them in arbitrary directories has remained relatively static.

The Relationship User Interface (RUI) has several features that lend itself to being an enhancement of a Zoomable User Interface (ZUI) and the Desktop Relational Search tool. A RUI is an interface that presents all the information stored or required by the user in a relational map as nodes and connecting lines on a surface that can be panned and zoomed. This lends itself to easy control via a touch screen or a mouse and keyboard.

Acknowledgements

I would like to thank my project supervisors: Dr Shayne Flint and Dr Ramesh Sankaranarayana, for allowing me the opportunity to work on this project. Through their guidance and support I was able to experiment with various ideas.

I would also like to thank all those involved in the development of the Piccolo2D, ext3cow and neo4j FOSS projects, without which the possibility of a RUI would be much further away.

Page 3: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Table of Contents

1 Introduction........................................................................................................................................................51.1 Objectives......................................................................................................................................................................51.2 Method...........................................................................................................................................................................5

2 Preparation and Research...............................................................................................................................52.1 Past Approaches..........................................................................................................................................................6

2.1.1 GUI – A Quick History..............................................................................................................................................62.1.2 Zoomable User Interface...........................................................................................................................................6

2.2 Desirable Features from Other Systems................................................................................................................62.2.1 Internet Relational Search........................................................................................................................................62.2.2 Desktop Relational Search........................................................................................................................................62.2.3 Topic Maps...................................................................................................................................................................72.2.4 Version Control System.............................................................................................................................................7

3 Project Motivation............................................................................................................................................7

4 Requirements and Analysis.............................................................................................................................74.1 Process............................................................................................................................................................................74.2 Issues Resolved.............................................................................................................................................................84.3 System Requirements Specification........................................................................................................................8

4.3.1 Major Features............................................................................................................................................................84.3.2 Desirable Features......................................................................................................................................................9

5 Design......................................................................................................................................................................95.1 Design Overview..........................................................................................................................................................95.2 Process..........................................................................................................................................................................105.3 Issues Resolved...........................................................................................................................................................11

5.3.1 Design Choices..........................................................................................................................................................115.3.1.1 Development Language.......................................................................................................................................... 115.3.1.2 Relational Mapping Framework........................................................................................................................... 125.3.1.3 Database..................................................................................................................................................................... 125.3.1.4 File System................................................................................................................................................................. 12

6 Implementation..................................................................................................................................................136.1 Process..........................................................................................................................................................................136.2 Issues............................................................................................................................................................................14

6.2.1 Relational Mapping Framework............................................................................................................................146.2.2 File System..................................................................................................................................................................14

7 Innovation...........................................................................................................................................................14

8 Conclusion..........................................................................................................................................................158.1 Future Work................................................................................................................................................................15

9 Glossary...............................................................................................................................................................16

10 References..........................................................................................................................................................17

Appendix A – System Requirements Specification...................................................................................18

Appendix B – System Design Document........................................................................................................31

Appendix C - IOzone File-System Test Results..........................................................................................57IOzone – ext3 Test Results............................................................................................................................................58IOzone – ext3cow Test Results.....................................................................................................................................60IOzone – ext4 Test Results............................................................................................................................................62IOzone – jfs Test Results................................................................................................................................................64

Page 4: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

IOzone – reiserfs Test Results.......................................................................................................................................66IOzone – xfs Test Results...............................................................................................................................................68

Index of Tables Table 1: X Window Managers.........................................................................................................................11

Index of FiguresFigure 1: System Components...........................................................................................................................10Figure 2: File System KB/sec Write Speed Comparison............................................................................13

Page 5: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Final Report

1 IntroductionWhat has changed in the way information is stored or displayed in the PC world since the inception of the GUI? There have been several iterations of interface design from the major players, Linux X Windows, Apple Macintosh, OS/2, and Microsoft. However, the basic concept of displaying the files and folders, and the storage hierarchy has remained relatively static. All of this while the power of modern desktop systems has continued to increase according to Moore's Law [1][2]. Most operating systems organise their files based on some arbitrary directory hierarchy. The GUI usually has some form of application menu that is also based on some hierarchy, such as Internet Browsers and Internet Chat applications forming part of an Internet Sub-menu. Granted there is some structure to the organisation of the files and applications within the system space, but very little once delving into the user space.

This is where the Relational User Interface (RUI) differentiates itself. The RUI is an amalgamation of many of the features that have been used in other User Interfaces (UI). It is meant to take the best features from each of these other systems and roll them into the new RUI. Some of the features that the RUI takes are a:

➢ Zoomable User Interface (ZUI),➢ Relational Desktop Search Tool,➢ Relationship Mapping from Mind Maps,➢ Version Control File-System, and➢ Full-Text Retrieval for content searching.

1.1 Objectives

The main objective of this project was to provide the requirements and design for a usable Relational User Interface. The project aimed to provide a small prototype as a proof of concept that a RUI could replace the standard GUI and provide a rich user experience. The project aimed to adopt a software engineering philosophy, rather than diving in to develop a prototype as detailed requirements analysis and design was firstly undertaken. The project was however more that just about the UI experience, it was also about delving into the way the entire Operating System works. Not down to the level of system calls or multi-tasking, but how files are represented, stored and the behaviour of the file system itself.

1.2 Method

Prior to rushing into the development phase to provide a working prototype for the proof of concept, the requirements for the RUI needed to be clarified. A typical waterfall development approach was adopted. This was selected as the best approach as it became apparent that the requirements and expectations of the system were not clear. There was significant differences in what was meant by RUI between the three parties involved. This clearly showed that, as this was a significant departure from conventional UI's, a clear set of requirements and design was a must for anything usable to be produced.

2 Preparation and Research

The first step in attempting to define what was needed from a RUI was to first determine what had come before. This project was not about reinventing the wheel, rather about determining what was already available, and taking the best features. This included the standard GUI, and standalone applications that provided some of the desired features.

Page 5 of 69

Page 6: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Final Report

2.1 Past Approaches

2.1.1 GUI – A Quick History

A quick review of the GUI history shows that very little has changed since the GUI inception in 1973 with the Xerox Alto [3], which is claimed to be the forerunner of the modern GUI. The graphics have become better, cleaner, sharper, and more animation and colour has slowly been introduced to the UI, but the underlying principle has not undergone any significant changes.

Looking at the major offerings from the main stream UI providers, they all provide to some extent:

➢ a structured menu for launching applications, ➢ a structured, albeit arbitrary, file storage hierarchy,➢ a user interface where the desktop is relatively clear, and the information is buried,➢ the user needs to be able to remember where they saved files, as limited searching ability exists,➢ limited version control of user based files, or system files.

Some of the above points have progressed in leaps and bounds over the last few years, such as content based searching from the desktop, with most major vendors now offering this feature. However, the system still relies on the user to break the storage of files into some arbitrary hierarchy, for separation.

2.1.2 Zoomable User Interface

The Zoomable User Interface came into existence in 1993, thanks to the efforts of Ken Perlin, Jim Holland and Ben Bederson [4]. The results of this effort was the Pad++ project. There is some claim that the multiple desktops provided by many of the X Window Manager are a semblance of a ZUI implementation (wikipedia, ZUI), this however, is very debatable.

Whilst the ZUI has not found success in the desktop UI environment, it has found success in the application space. Some very well known applications owe their beginning to the ZUI such as Google Maps and Google World, even the iPhone interface has its roots in the ZUI space with its zoomable web browser [5].

2.2 Desirable Features from Other Systems

2.2.1 Internet Relational Search

There have been several attempts over the years to provide relational searching results on Internet Search Engines, however none seemed to have survived. One such attempt was KartOO [6] which had a brief success from 2001 until it closed down in early 2010 [7]. The question here was did KartOO close down due to it being too hard for end users to use, and therefore the relational model is not so good. Or was the reason for closing simply due to struggling to gain market share against the Internet Search Engine giants such as Google?

Another such visual search engine was the offering from Microsoft, Tafiti [8]. This search engine may still be available, but has not gained much support from the user community. Gorog did not recommend the interface, claiming it was “too confusing for novice users” [9]. Is this destined to go the same way as KartOO, is this a sign of why there are no RUI's in present use?

2.2.2 Desktop Relational Search

There have been many applications that allow the searching of information from the desktop PC. These include searching for documents on the machine or a network share, by file name, file contents, and also searching for terms on Internet pages. The majority of these present their results in a tabular

Page 6 of 69

Page 7: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Final Report

format, maybe with a match percentage for how closely the results match the search criteria. Given the relatively small size of internal disk space this approach has been relatively successful, however with the ever increasing size of disks in even the modest home PC, and the explosion in the Internet, this approach is starting to show its flaws. Schlegel proposed a new approach that provided the results in a relational map [10]. This approach has some differences in the search algorithms, but the main difference that is of concern to us is in the way the results are presented to the user. The results are drawn on a panel in a relational map. Allowing the user to possibly discover other documents that refer to the same subject, that were not originally being searched for.

This concept of the relational map for the search results is what we were looking for, with the expansion to the entire system interaction rather than just for searching.

2.2.3 Topic Maps

There are a myriad of applications that are either in current use, or have come and gone, that provide the means to represent information in a relational map format. These have had many names over the years. There are subtle differences between each variant, however the basic concepts seem to be very similar. The one that we will use when referring to this type of map is the Topic Map as it has a defined ISO standard [11]. Some of the more widely known variants are Topic Maps [12], Resource Description Framework (RDF) [13] and Mind Maps [14]. Was it possible to provide an entire desktop interface, rather than just a standalone application, that followed the Topic Map approach?

2.2.4 Version Control System

Whilst not strictly part of the UI space, a version control system (VCS) has features that were deemed desirable for the mapping interface. A version control system provides the means of keeping track of the various versions of a document, and can also provide for the locking of documents to stop unauthorised modification. One of the side features of most of these systems is that they can by extension provide a means of displaying the current state of a document at any given time. It was this feature of the VCS that was of interest to this project.

3 Project MotivationThe motivation of this project was to attempt to provide a better user experience by providing a new and easier way to interact with the information on the PC. Was the reason for the little change on the UI due to it being “correct”, or was there a better approach out there? Could the information be organised in such a way that made it easier to find and work with? These were some of the questions that we hoped would be answered by this project.

The RUI was to be developed as a Linux Window Manager. This would allow the X Windows system to take care of the underlying components, and the development to focus on the higher level issue of implementing a RUI.

4 Requirements and AnalysisThe goal of this project was to provide a design and small prototype of a user interface focused on the relational mapping of objects and events interacted with on the system.

4.1 Process

It was deemed that the required and desired features of the system were not clear, and that diving into developing a prototype was not the correct Software Engineering approach and would not gain the results expected. The prototype would have been a appropriate option if more of the requirements

Page 7 of 69

Page 8: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Final Report

were known, but with what was known, we would have been building blind. A Waterfall approach to the project was adopted, which entailed completing the requirements analysis and documentation prior to any development taking place.

The documenting of the system requirements took an iterative approach. The first few drafts had major changes while all involved solidified what they thought a RUI meant. Once again another iteration was created during the creation of the design document, and again during the prototype development as different features and scenarios became apparent.

4.2 Issues Resolved

The major issue that needed to be overcome for the requirements gathering was determining just what was meant by a relational user interface.

The questions revolved around what was to be represented and how:

➢ Was the entire system going to be represented by Nodes and Lines,➢ What did a Node represent,➢ What did a Line represent,➢ Was a single object allowed to be represented by more than one node,

➢ How was the information to be presented to the user, by a graphical Topic Map, or by a Tree type diagram, or simply by tables of information on a screen,

➢ What additional information was to be captured about an object and the relationship, and how was this to be stored?

At this point in the project there was little thought into what software tools would be used, as this phase was all about gathering what needed to be done rather than how to implement.

The approach to resolve the requirements questions was to conduct meetings in an interview type format with my supervisors, and develop a clearer picture, or a middle ground of what we all meant by the RUI. Several Use Case diagrams and some sample screen mock ups were produced at this time to clarify the requirements.

4.3 System Requirements Specification

A summary of major features that came to light during the requirements analysis are detailed in the sections following. The System Requirement Specification (SRS) can be found in Appendix A for the complete set of requirements.

4.3.1 Major Features

Being a UI there were standard features and requirements that needed to be met, such as what layout to adopt, screen element colours etc. The major features detailed in this section however relate specifically to the RUI features. These features have been extracted from the Requirement Specification that was produced as part of this project, and are not a complete list, but rather a list of the features that were deemed to be most important to the RUI.

1. UI - Relational Mapping: Provide the means to display the files, events and contacts of the system in a relational map.

2. UI – Relationship Traversing: Provide the ability to traverse the relational map as displayed on the screen. The map would either redraw with the central node being the node selected by the user, or the screen would pan to place the node selected in the centre.

3. UI – Session Time Line: Provide a time line that was built by the user actions for the current session, thus allowing quick traversal back to a node that was accessed earlier in the session.

4. Version Tracking Time Line: Provide the ability to roll the system back to the state it was in at any given time. This would provide the user with a read-only look at what the system looked

Page 8 of 69

Page 9: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Final Report

liked at that time. The roll-back would affect the Relational Map as well as files on the system.5. Seamless Local – Intranet – Internet interaction: The system should not place any arbitrary

barriers against accessing and using information regardless of whether it was stored locally, on a network share, or on the Internet. Obvious limitation would exist around the need for network access to enable the wider searching, however when access was available the user should not have to provide any special actions to allow searching of material from non-local sources.

6. Search: Provide a means to search for information. This search shall include Relationships, Nodes, Document Names, Document Content, and Internet based searching.

4.3.2 Desirable Features

The desirable RUI features that were found during the analysis centred around the ability to give weights to the relationships and the ability for the system to automatically add relationships to nodes. As defined in the Major Features section above, this section does not specify standard UI features such as mouse behaviour or keyboard short-cuts, but rather focuses on the RUI specific features.

1. Automatic Relationship Mapping: The system shall provide automatic relationship mapping, where the system is able to determine that a relationship exists. This may include automatically completing a relationship between two people, or a person and an event based on an e-mail.

2. Relationship Ranking: To aide in the displaying of relationships and nodes, the system will provide a mechanism to apply different weights to the relationships. This weighting will not normally have any effect until the drawing of a particular relationship map would result in too many nodes and relationships to be cleanly drawn on the screen. In this situation the relationships with the highest ranking will be drawn first, then the lower rankings until a predetermined amount of nodes has been displayed. Once the limit has been reached the system will indicate that there are more nodes and relationships for that map, and will provide a “Next” button that will display the next set of node and relationships.

3. Filtering: The relational map may have a filter applied. This filter will remove, or only show, any matching element that has been filtered. This will affect both a standard full map and also a search results map.

4. Modular UI: The system shall allow for system components to be added or removed from the main screen, and also the placement of the action bars, Search and Filter, to be moved to a different location. This action corresponds to the ability of most modern operating systems allowing for the changing of the UI layout.

5 DesignThe next phase of the project was to complete the design, with the System Design Document (SDD) being the results of this phase. The completed SDD document can be located in Appendix B.

5.1 Design Overview

The system has been designed to be implemented in the Java language, however the design should lend itself to any object oriented language just as easily. The Java language was chosen as it appeared to already have most of the libraries that were needed for the complete implementation. Figure 1 shows the basic components of the system.

Page 9 of 69

Page 10: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Final Report

The main component is the Panel, this is the main container that all the other system elements are housed in. As shown, the panel contains one instance of the TimeSlider and TimeLine. These may be blank when the system is first launched, but the information contained within these components grows over use.

The Search and Filter components are only instantiated when they are active.

Each of the top level components, TimeLine, TimeSlide, Search and Filter, may contain a Relationship Map. This is the representation of the system given the current filtering, search results or time shifting. The current map is deemed to be a map with a zero time shift.

The Relationship Map is either a blank map, or contains one or more nodes. Each node represents an object that the

system user has an interest in tracking. This object may be a place, time, date, file, web-site, event or another person to name but a few options. Each node may have a relationship with any other node. A node may have at most one relationship with another node, but that relationship may have multiple attributes. The attributes of a node or relationship are what defines the information that is to be captured about that node or relationship.

There are predefined attributes on each node and relationship to capture core information, such as name and creation time. The user is able to create any number of their own attributes against a node or relationship. An attribute may also be linked to multiple nodes and relationships at once. An example of this may be a photograph or a group of people, may be linked to each node that represents each person in the photograph. Once all nodes and relationships linked to the attribute have been removed, the attribute and any information against that attribute will also be removed.

5.2 Process

The project suggested an object oriented design for the final system. The object oriented design was however selected to provide reusable and modular components for the system. The design phase included drawing up a simple system component model, and fleshing out what technologies would be best suited for the implementation. The design also focused on the look and feel of the RUI.

Several small development samples were made during the design phase. These were not built to be part of the final system, but were created more as a proof-of-concept for the component being tested. These proof-of-concepts allowed the design element to be proven before too much effort was expended on the design.

For the UI component it was deemed more appropriate to display the behaviour of the system via a series of tables showing how the system should behave given a particular user action. These tables

Page 10 of 69

Figure 1: System Components

Page 11: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Final Report

are known as Event-Response Tables, and are considered as an effective method for clearly showing system requirements [15]. The resulting Event-Response table is defined in the SDD in Appendix B.

5.3 Issues Resolved

There were several issues surrounding the design of the system. The first issue to be resolved was the components that would be used for the implementation. Whilst a good design should be language independent, the choice was made not to develop everything from scratch if the features were already present in other tools, libraries and applications that could be leverage off. This decision lead the system towards being developed in the Java language. The applications, modules and libraries chosen are detailed in this section, along with a brief rationale of why they were chosen.

5.3.1 Design Choices

The research performed while gathering the requirements and investigating how best to achieve various aspects of the system steered the design and ultimate implementation choices down a particular path.

The first decision was to make the RUI a Free and Open Source Software (FOSS) project. It was believed that this would give the RUI the best chance of ever actually being implemented. This narrowed down the choices of some of the libraries for the features required, but not by a great deal. All of the choices discussed below will, therefore, only touch on the FOSS offerings for that feature set.

5.3.1.1 Development Language

The language that the system has been designed for is the Java language. There are several reasons for choosing Java as the language. Java was originally not considered as it was believed that being an interpreted language it would not be fast enough to be used for a complete UI. This fear has not been completely allayed, although Java is used for the Gnome desktop environment, as shown in Table 1 it is not the prime development language of Gnome or any other major Linux Windowing system.

As the project was ultimately about a new Linux User Interface investigations into the development language for the prototypes focused on other Windows Mangers (WM). With the exception of Gnome, all the other WM predominately used C/C++ and associated libraries for development.

Table 1 lists the Window Managers that were reviewed. Gnome and KDE were only selected as they have the widest user base, although they are very complex and heavy WM's compared to the other offerings. The RUI features aligned it closer with the other light weight WM's, however it was determined that even these light weight WM's also predominately used C/C++ as their primary development language.

The deciding factor for Java as the development language was the availability of the Piccolo2D [22] and Neo4j [23] libraries as detailed below.

Page 11 of 69

Window Manager Primary Language

Gnome [16] Python ­ GTK+

KDE [17] C++ ­ QT4

IceWM [18] C++

Xfce [19] C++

Enlightenment [20] C++

FVWM [21] C/C++

Table 1: X Window Managers

Page 12: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Final Report

5.3.1.2 Relational Mapping Framework

The library, or framework as they class themselves, that was selected for the relational mapping graphic engine was the Java based Piccolo2D library. The Piccolo2D website defines Piccolo2D as a toolkit for developing ZUI's. Piccolo2D is the latest offering from the same team that provided Pad++, the original ZUI [24]. Whilst a ZUI is significantly different to a RUI, there are similarities that make basing a RUI on a ZUI base practical. The Piccolo2D toolkit provides an easy means of representing nodes and relationships in a graphical manner. The drawing panel also inherently allows for zoom and pan operations. The pan operation allows the Relational Map to be easily and quickly re-centred based on the latest selected node.

There were other possible options for the Relational Mapping toolkit, however most of them suffered a similar issue. When a new node was selected the map would be redrawn. Even one of the better commercial offerings, TheBrain [25], suffers from this issue. The problem is that people are not as adept at finding a particular node's new location when the map changes on each selection. It was for this reason that it was decided to pan the map on selection rather than redraw the map each time. This would also allow for simpler code, although the drawing routine would still need to be developed to enable the rendering of search results.

5.3.1.3 Database

A database was needed to store the attribute data, and other details about the nodes and relationships. Given the data was for a relational graphic map, a graph database was the logical choice. A standard relational database of course could manage storing the relational material, however this is the foundation of a graph database, and as this project was about selecting the “best” tools for the job that was the path chosen. Neo4j provided an excellent choice, not only was it open source, it was a Java application, and it was a mature product, having been in “commercial development for 10 years and in production for over 7 years” [23].

5.3.1.4 File System

The requirements of the file system for the RUI are fairly small. Originally the choice of file system was not considered part of the RUI and the versioning feature was to be added using an add-on application on top of whatever file system the user wished to use. This decision seemed to be supported after reviewing some of the other versioning file systems, that is until uncovering ext3cow [26]. The features of ext3cow seemed to perfectly match what was required for the RUI versioning of the file system. Whilst development of ext3cow seems to have stopped, as there have not been any releases since version 0.2 released in March 2008, any shortfalls could be developed using the time that developing the full solution would have entailed, thus helping both the RUI and ext3cow projects.

It is unusual for a Linux distribution to dictate which file system must be used, but ext3cow provides significant advantages over any other file system for the RUI requirement of the TimeSlide. This would allow the file system to take care of the versioning and roll-back for all the file based components, leaving only the trivial, in comparison, relational mapping component's roll-back needing to be developed. There are of course other file systems that have versioning features, however it was ext3cow's ability to allow the user to go back to a specific time rather than version of the file that made it the obvious choice for this implementation.

Ext3cow's claims of low impact on the performance and storage overhead were also attractive. There is little test data available from the ext3cow web site on this, so a limited set of tests comparing several file systems were run, the results of which can be seen in Figure 2 below. The tests were conducted using the IOzone file-system benchmarking tool [27].

All of the tests were conducted on the same physical hard disk, same machine, and the drive had been freshly formatted and mounted with the tested file-system. This was a secondary drive in the machine, and no other applications were running at the time.

Page 12 of 69

Page 13: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Final Report

Whilst these were not exhaustive tests on the merits of each file-system, it did show that the ext3cow file-system can hold its own against those tested. The clear winner in terms of write speed was the XFS file system. Whilst ext and ext3cow did not out perform the other systems tested, coming in 4 th

and 5th out of the six tested, they did perform almost identical to each other. Given that ext3 has been a default standard file-system in many Linux distributions, this shows that the performance of ext3cow should not be a barrier to adoption. The ext4 file-system is relatively new, and has become the default file-system for the Ubuntu [28] distributions and is claimed to perform well [29], although our limited testing showed this performed better than ext3 and ext3cow, it performed similarly to jfs and marginally worse on the test data than xfs. However, while these other systems did perform better, they do not have any of the version control features that are of interest for this project. The complete results of the IOzone tests for the tested file-systems can be found in Appendix C.

6 ImplementationWhilst the project was not to go into the Implementation Phase, there were several areas of implementation that needed to be considered during the design. These areas are discussed in the following sections.

6.1 Process

As the project was only to develop the requirements and design with small proof-of-concept prototypes there was no full-scale implementation. The implementations were designed to provide the proof-of-concept for the module or library that was being tested.

The following sections discuss the issues that the implementation will be likely to face. Some of the issues were found during the proof-of-concept implementations, but they are not specific to these sample implementations.

Page 13 of 69

Figure 2: File System KB/sec Write Speed Comparison

ext3 ext3cow ext4 jfs reiserfs xfs

0

500000

1000000

1500000

2000000

2500000

File Size(MB)

1216

File System

KB

/se

c

Page 14: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Final Report

6.2 Issues

Aside from standard UI implementation issues, such as where to place components and what look to follow, there were other issues that will affect the implementation phase of this project when undertaken.

6.2.1 Relational Mapping Framework

Whilst the Piccolo2D framework is a very good base for the RUI, there are some mild issues around using the framework as it currently stands. The Piccolo2D library is under current development, and as such these issues may have been addressed when the RUI enters the Implementation phase.

Piccolo2D provides a clean and easy way to render the nodes and relationships on the screen, however some areas may need more work to fit the RUI requirements. The development of these features could be undertaken by the RUI development team in conjunction with the Piccolo2D development team. This is a relativity common approach on FOSS projects, therefore, providing a benefit to both projects.

The main area of concern was the lack of ability to easily rename a Node once it has been created. This did not currently seem to be present in the library. It is hoped that this will only require a small addition to the framework, but will provide an enormous benefit to the RUI. The addition of a standard method that will determine if a new node will cover an existing node would also benefit the RUI project, although nodes can be dragged to a new location, the perceived usability of both projects would increase by ensuring the initial creation of a node does not cover an existing node or relationship if possible.

6.2.2 File System

The greatest problem with ext3cow is that, as mentioned, the development seems to have come to a halt. The features that this file-system provides however are of significant value to the RUI project, and therefore rather than focus effort on developing the same features from scratch, it was determined it would be of far better value to bring the ext3cow system up to speed with the latest kernel. From initial investigations it does not appear that there is significant work required to the ext3cow module to allow it to compile against the latest Linux kernel. Further investigation may be warranted to determine if the versioning feature of ext3cow could be added into the newer ext4 file-system to leverage off the speed of the newer file-system.

7 InnovationThis project was about a new means of storing, displaying and interacting with information stored on a personal computer. While the concept of the RUI as a whole may be innovative, the components used have been in existence for many years. The innovative side of this project was to pull all of the components together to form a complete system, rather than them running in isolation as simple applications.

The major components of the RUI were the ZUI, Topic Map concept and the version control file system, as individual applications they have had varying degrees of success, it is hoped that by brining them all under the one system that it will provide the next revolution of personal computing user interfaces. The graphical display of the RUI also lends itself very well to be driven via a touch screen interface, which are becoming more prevalent in user space.

Page 14 of 69

Page 15: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Final Report

8 ConclusionThe project has completed the original goal of producing a set of requirements and a system design for a RUI implementation. Many of the questions that surrounded the project at inception have now been clarified and answered. The major question that remains is, if the designed RUI was to be developed, would it be embraced by users, or would they stay with what they know?

The concept of a RUI is sound, there are many stand-alone applications in use that have the features that are core to the RUI. The way users interact with the modern PC is undergoing changes. Touch screens are becoming increasingly available for the mass market on desktop PC's, they are already second nature on smart phones. The logical step from a touch screen is a ZUI, and by extension the RUI.

As storage capacity of the humble PC is ever increasing, the means of being able to quickly locate the right document when needed is getting harder. This therefore shows that there is a current need to change the way we access the vast amount of data we are gathering, ensuring that the information is controlled by us, not the other way around. The RUI offers a simple yet powerful way of being able to store and access information based on what it is related to, rather than where it happened to be saved.

8.1 Future Work

There remains much ahead in the RUI space. The RUI project can be taken to the implementation phase to successfully implement a working RUI. This may start out as a small stand-alone amalgamation of the applications identified within this report, and hopefully grow to one day being a complete Linux desktop.

Additional effort should also be directed to both the ext3cow and Piccolo2D projects to bring them up to the level that is required for a successful RUI implementation. This will not only help the RUI implementation, but will also help these two very worthwhile FOSS projects along the way. Opening up these two projects to many more uses that just the RUI.

Page 15 of 69

Page 16: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Final Report

9 Glossary

Attribute An attribute is a means of adding some other information to either a Node or a Relationship. Anything can be added as an attribute. An attribute has a Name and Value pair. The name is the common name of the attribute, and the value is whatever the user wishes to store against that attribute. The value may be a simple text or numerical value, a file, a web-site, or a date or place. Attribute names do not need to be unique as the system will handle any duplications of names. A single attribute may be linked to any number of Nodes or Relationships, but the attribute will cease to exist when it is no longer linked to any Node or Relationship.

Node An object of interest. A node can have none or many relationships with other nodes. A node represents any object that the user has an interest in tracking. This may be a person, an event, a time or place, a web-site, or any other object as desired by the user.

Relational Map The graphical representation of the relationships and nodes that exist within the system.

Relationship A link of some kind between two nodes. The link signals that the two nodes have some form of relationship with each other. There could be a single reason for the relationship, such as “Was Born on this Day”, or multiple relationships between the two nodes, such as “Works With”, and “Plays Football With”.

Rui A Relational User Interface, where information is stored as nodes and relationships, and traversal between related objects is possible.

Session The duration of a single user login. The session starts when a user logs into the system, and ends when the user logs out.

Time Line A means for tracking what Nodes a user have selected during a single session. The Time Line allows for the quick selection of a node that had earlier been selected for a single session. The Time Line information is not persistent across sessions.

Time Slide A means for rolling the entire system back to the state it was in during an earlier time. The system is placed into a read-only state during the roll-back. The Time Slide is designed to allow the user to see what the system state was at that earlier time, and to see what relationships and files were present and being worked on during that time. The Time Slide affects both the Relational Map and the file system.

Ui User Interface. The way the user is presented information that allows interaction and or information flow between the user and computer.

Zui A Zoomable User Interface, allows for the information shown to be panned and zoomed in and out to display more or less detail.

Page 16 of 69

Page 17: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Final Report

10 References[1] Wikipedia 2010, Moore's law, http://en.wikipedia.org/wiki/Moore's_law, (Accessed 20 October 2010)[2] Webopedia 2010, Moore's Law, http://www.webopedia.com/TERM/M/Moores_Law.html, (Accessed 20

October 2010)[3] Fekete, G 2009, Operating System Interface Design Between 1981-2009,

http://www.webdesignerdepot.com/2009/03/operating-system-interface-design-between-1981-2009/, (Accessed 15 October 2010)

[4] Bederson, B., Meyer, J. 1998, Implementing a Zooming User Interface: Experience Building Pad++, http://www.cs.umd.edu/hcil/pad++/papers/spe-98-padimplementation/spe-98-padimplementation.ps.gz, (Accessed 18 September 2010)

[5] Wikipedia 2010, Graphical user interface, http://en.wikipedia.org/wiki/Graphical_user_interface, (Accessed 15 October 2010)

[6] KartOO 2010, KartOO visual meta search engine, http://www.kartoo.com/, (Access 20 October 2010)[7] Wikipedia 2010, Kartoo, http://en.wikipedia.org/wiki/Kartoo, (Accessed 20 October 2010)[8] Microsoft 2010, Tafiti, http://tafiti.mslivelabs.com, (Accessed 16 October 2010)[9] APC Magazine 2007, Tafiti showcases latest Microsoft technologies,

http://apcmag.com/tafiti_showcases_latest_microsoft_technologies.htm, (Accessed 16 October 2010)[10] Schlegel, D. 2008, Desktop Relational Search or One Way AI Could Save Us From Our Files,

http://dspace.suny.connect.suny.edu/bitstream/1951/43856/1/Desktop_Relational_Search.pdf, (Accessed 20 September 2010)

[11] International Organisation for Standardization 2010, ISO/IEC 13250:2003 – Information Technology – SGML applications – Topic maps, http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=38068, (Accessed 16 October 2010)

[12] Wikipedia 2010, Topic Maps, http://en.wikipedia.org/wiki/Topic_map, (Accessed 20 October 2010)[13] Wikipedia 2010, Resource Description Framework,

http://en.wikipedia.org/wiki/Resource_Description_Framework, (Accessed 20 October 2010)[14] Wikipedia 2010, Mind Maps, http://en.wikipedia.org/wiki/Mind_map, (Accessed 20 October 2010)[15] Wiegers, K. 2006, More About Software Requirements: Thorny Issues and Practical Advice, Microsoft Press,

Washington[16] Gnome 2010, Gnome, http://www.gnome.org/, (Accessed 15 September 2010)[17] KDE 2010, KDE, http://www.kde.org/, (Accessed 15 September 2010)[18] IceWM 2010, IceWM, http://www.icewm.org/, (Accessed 15 September 2010)[19] Xfce 2010, Xfce, http://www.xfce.org/, (Accessed 15 September 2010)[20] Enlightenment 2010, Enlightenment, http://www.enlightenment.org/, (Accessed 15 September 2010)[21] FVWM 2010, FVWM, http://www.fvwm.org/, (Accessed 15 September 2010)[22] Piccolo2D 2010, Piccolo2d – A Structured 2D Graphics Framework, http://www.piccolo2d.org/, (Accessed 10

September 2010)[23] Neo4j 2010, neo4j open source nosql graph database, http://neo4j.org/, (Accessed 20 September 2010)[24] Pad++ 2010, Pad++: Zooming User Interfaces (ZUIs), http://www.cs.umd.edu/hcil/pad++/, (Accessed 16

September 2010)[25] TheBrain 2010, TheBrain:: Mind Mapping Software, Brainstorming, GTD and Knowledgebase Software,

http://www.thebrain.com, (Accessed 29 August 2010)[26] ext3cow 2010, The ext3cow File System, http://www.ext3cow.com/Welcome.html, (Accessed 10 September

2010)[27] Iozone 2010, Iozone Filesystem Benchmark, http://www.iozone.org/, (Accessed 22 September 2010)[28] Ubuntu 2010, Ubuntu homepage, http://www.ubuntu.com/, (Accessed 19 October 2010)[29] ars rechnica 2009, Super fast Ext4 filesystem arrives in Ubuntu 9.04, http://arstechnica.com/open-

source/news/2009/01/super-fast-ext4-filesystem-arrives-in-ubuntu-9-04.ars, (Accessed 21 October 2010)

Page 17 of 69

Page 18: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Appendix A

System Requirements Specification

Page 19: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Requirements Analysis

Software Engineering Project

26th October 2010

Jeff Stiff (u4689321)

Linux Relational UI Desktop

Page 20: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Jeff Stiff (u4689321) Linux Relational UI Desktop

Version: 1.0 Requirements Analysis Page: ii Date: 26th October 2010 Software Engineering Project Subject ref: COMP8790 c:\documents and settings\jeff\desktop\uni-docs\new\final_versions\project-requirements.doc

Document details Student name Jeff Stiff (u4689321)

Project name Linux Relational UI Desktop

Subject reference COMP8790

Document title Requirements Analysis

Document subtitle Software Engineering Project

Document number 2

Document version 1.0

Version date 26th October 2010

Document file name c:\documents and settings\jeff\desktop\project-requirements.doc

Print date Wednesday, 27 October 2010

Project participants Name

Student Jeff Stiff (u4689321)

Supervisors Shayne Flint

Ramesh Sankaranarayana

Document history

Version Date Author Description

0.1 Draft 15/08/2010 Jeff Stiff Initial draft

0.2 30/08/2010 Jeff Stiff Changes made after review and refocus

0.3 20/09/2010 Jeff Stiff Clarifications and grammar corrections

1.0 26/10/2010 Jeff Stiff Final Release

Page 21: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Jeff Stiff (u4689321) Linux Relational UI Desktop

Page: iii Requirements Analysis Version: 1.0 Subject ref: COMP8790 Software Engineering Project Date: 26th October 2010 c:\documents and settings\jeff\desktop\uni-docs\new\final_versions\project-requirements.doc

Contents

1 Introduction........................................................................................ 1

1.1 Project Background ........................................................................................... 1 1.2 Project Scope .................................................................................................... 1

2 Requirements..................................................................................... 2

2.1 Relationship and Attribute Mapping .................................................................. 2 2.1.1 Automatic Relationships .................................................................................. 2 2.1.2 User Defined Relationships ............................................................................. 2

2.2 Attribute Mapping .............................................................................................. 2 2.2.1 Automatic Relationship Attributes.................................................................... 3 2.2.2 User Defined Relationship Attributes............................................................... 3

2.3 Relationship Ranking ........................................................................................ 3 2.4 User Interface.................................................................................................... 3

2.4.1 Search ............................................................................................................. 3 2.4.2 Relationship Traversing................................................................................... 4 2.4.3 Time Line......................................................................................................... 4 2.4.4 Present a Relationship Orientated User Interface ........................................... 4

2.5 Time Slider ........................................................................................................ 4 2.5.1 Version Control Settings.................................................................................. 4

3 Use Cases........................................................................................... 5

4 Screen Mock Ups............................................................................... 6

4.1 Following Relationships .................................................................................... 6 4.2 Time Line........................................................................................................... 7

Appendix A - Requirements Matrix......................................................... 8

List of tables Table 1: Requirements Matrix ............................................................................................. 8

List of figures Figure 1: System Use Case ................................................................................................ 5 Figure 2: Fix Enrolment Main Node - Example ................................................................... 6 Figure 3: COP8790 with Filtering applied. .......................................................................... 6 Figure 4: COMP8790 without Filtering ................................................................................ 7 Figure 5: Time Line - Example ............................................................................................ 7

Page 22: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a
Page 23: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Jeff Stiff (u4689321) Linux Relational UI Desktop

Page: 1 Requirements Analysis Version: 1.0 Subject ref: COMP8790 Software Engineering Project Date: 26th October 2010 c:\documents and settings\jeff\desktop\uni-docs\new\final_versions\project-requirements.doc

1 Introduction

This document defines the requirements of the Linux Relational User Interface (RUI) Desktop project that has been undertaken as part of the Australian National University (ANU) Master of Computing Software Engineering Project.

1.1 Project Background

Mainstream computer desktop interfaces all behave in a similar fashion. That is, they all treat the system as a group of objects. These objects may be classified into semi-functional groups, or not, depending on the specific desktop involved. These groups may be along the lines of Internet, Office, Games etc., with applications that pertain to those broad areas being part of that group.

What this project aims to achieve, is to provide a new method of interaction between the user and the computer. The focus of this project is to switch the model from Object driven to Relationship driven. Rather than navigating though menus looking for the application to open, the user will navigate through a web of relationship connections between objects. Once at a node of interest then the user may chose what action they wish to take, on the file or links that have been presented.

For example, instead of opening an e-mail application and then closing to send an email to a particular contact, the user would navigate to that contact, via a relationship that they have with the user, they will then have the choice of enhancing the relationship, this may be done in many ways, including by: writing an e-mail; a phone call; or a face to face meeting. If an email was the method of choice, this would open an editor for the e-mail to be written in, and from there the e-mail can be compiled and sent, all without the user expressly opening any e-mail application.

Each document, application and event may be represented as an attribute to any relationship. This is where the “Relational” component of the project comes from. This is not “relational” in the sense of a database relation, but it is to indicate that the relationship between objects are the focal point for the system. These relationships may be automatically set by the system, or may be created or deleted by the users themselves.

The Relationship User Interface (RUI) has several features that lend itself to being an enhancement of a Zoomable User Interface (ZUI) and the Desktop Relational Search tool. A RUI is an interface that presents all the information stored or required by the user in a relational map as nodes and connecting lines on a surface that can be panned and zoomed. This lends itself to easy control via a touch screen or a mouse and keyboard.

1.2 Project Scope

The duration of this project is very limited, as such, the project is focused on delivering the first two phases of the development cycle, that being the requirements analysis and the design document. The requirements identified in this document will be given a priority rating based on how important the feature is to any future implementation. The table within Appendix 1 details the priority of each of the requirements identified. It is the intention that by the end of this project the requirements and design shall be documented, and several small proof-of-concept implementations may have been developed where needed.

Page 24: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Jeff Stiff (u4689321) Linux Relational UI Desktop

Version: 1.0 Requirements Analysis Page: 2 Date: 26th October 2010 Software Engineering Project Subject ref: COMP8790 c:\documents and settings\jeff\desktop\uni-docs\new\final_versions\project-requirements.doc

2 Requirements

The following section defines the requirements of the project. The interaction between user and system, and the linking of relationships throughout the system are the core components of this project.

2.1 Relationship and Attribute Mapping

It is a requirement to be able to provide a mechanism for the manipulation of relationships between objects and tasks within the system, and items outside the system, such as web sites.

2.1.1 Automatic Relationships

The system shall provide automatic relationships where possible. These types of relationships exist around features that the system can determine, such as relationships with any entry in a contacts list.

2.1.2 User Defined Relationships

A User shall be able to create a relationship between any two objects. This relationship will automatically be given a strong weighting. This weighting can be overridden at any time by the user setting a specific weight.

The weighting of relationships is to provide a way to limit the number of relationships that are to be displayed if a particular node has too many relationships to be cleanly displayed at the one time. This mechanism shall provide the means to show the highest weighted relationships first, ensuring that the most important relationships to the user are displayed before lower priority relationships.

It is envisaged that the weight ranks shall only contain Low, Medium and High values, to ensure that the end user is not spending more time fine tuning the weights then using the system.

2.2 Attribute Mapping

It is a requirement to be able to provide a mechanism for the manipulation of specific attributes of a relationship. The attributes of the relationship are the files and contact that has taken place that aid the relationship.

Relationship Attributes Example:

Two people, Fred and Bob, represented by two Nodes, may have a single Relationship. But this relationship may have many facets.

Relationship: Fred Knows Bob

Relationship Attributes:

• Fred works with Bob

• Fred works in the same office with Bob

Page 25: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Jeff Stiff (u4689321) Linux Relational UI Desktop

Page: 3 Requirements Analysis Version: 1.0 Subject ref: COMP8790 Software Engineering Project Date: 26th October 2010 c:\documents and settings\jeff\desktop\uni-docs\new\final_versions\project-requirements.doc

• Fred plays squash with Bob on a Wednesday night

• Fred and Bob had a Work meeting about some Training yesterday

2.2.1 Automatic Relationship Attributes

The system shall provide automatic relationship attributes where possible. These types of attributes exist around features that the system can determine to be similar, such as:

� Emails to the same recipient have a weak relationship to all other emails to that recipient,

� Attributes, a specific e-mail has a strong relationship to other emails of the same subject,

� Time, Files with the same Creation Date, or Last Modified Date, have a strong relationship with each other.

2.2.2 User Defined Relationship Attributes

A User shall be able to add an attribute to any relationship within the system. This will automatically be given a strong weighting. This weighting can be overridden at any time by the user setting a specific weight.

A relationship attribute shall include creation time, modification time and last access time for that attribute. This will provide the ability to map to a version of the relationship attributes based on a date/time selection.

The capturing of the date and time for these attributes shall allow the Time Slider feature detailed in Section 2.5 to roll the system back to any point in time. This will show not only what the state of any files at a given time were, but also what the state of any relationships and what was currently being worked on at that time.

2.3 Relationship Ranking

The system shall provide a mechanism of setting a weight for a relationship. Not all relationships carry the same weight. Some relationships are weak, for example the relationship between two people due to a single meeting. The User has the ability to manipulate any relationship strength regardless of whether the relationship was automatically created by the system or was user created.

2.4 User Interface

The User Interface shall provide a means to navigate through the system. The two main methods of navigating shall be by Search or by Relationship Traversing.

2.4.1 Search

The Search navigation mechanism will provide a means for a user of the system to quickly locate what they are looking for, regardless of this being a person, a file, an application or a web site. Via a full-text search engine the contents of certain types of files will be searchable from the same search interface.

Page 26: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Jeff Stiff (u4689321) Linux Relational UI Desktop

Version: 1.0 Requirements Analysis Page: 4 Date: 26th October 2010 Software Engineering Project Subject ref: COMP8790 c:\documents and settings\jeff\desktop\uni-docs\new\final_versions\project-requirements.doc

2.4.2 Relationship Traversing

Relationship Traversing shall provide a means of navigating through the system based on relationships that exist in the system. Typically these are traversed after a search has been performed, however the initial map shall also show relationships based on frequent use.

2.4.3 Time Line

The third method of navigation of the system will be provided by a time line displayed at the top or bottom of the screen. This is not a primary method of navigation, more a means of being able to jump back to some other task that had been performed earlier during the same session. This time line shall be built as the user navigates around the system on a session by session basis.

2.4.4 Present a Relationship Orientated User Interface

The system shall present a relationship orientated interface to the user. Rather than a cascading menu of applications being grouped together, the user shall be presented with a relationship map providing a web of relationships based on the currently selected node.

2.5 Time Slider

The system shall provide the means to roll back to an earlier time to display the relationships and file versions as at that time. This mechanism, known as a Time Slider, shall provide the means to see the system at any time since the system was installed, or up until the earliest purge.

This component should not be confused with the Time Line detailed in section 2.4.3. The Time Line shows a map of recent activity for the current session, whereas the Time Slider provides the ability to roll the entire system back and forth to another time period.

The roll back of the system using the Time Slider is not to be confused with a restore function as it does not restore the system to that “snapshot”, but rather provides a means to display and interact with the system as it was at that time. Files can be opened, copied, printed etc, without affecting the current version. Relationships can be traversed to see what was related to specific items at that point in time.

This method may be implemented in a similar vein as a standard Version Control System (VCS) for the entire system. All documents, photos, music, relationships, etc, loaded into a file system that provides a VCS type action. This shall provide a form of revision control for the entire system.

2.5.1 Version Control Settings

The system may provide the mechanism to opt-out any file from the version control system. This will be based on a user setting for the specific file or directory.

If the file is not included in the version control system, then this will mean that the various versions of the file will not be accessible via the time slider, and new versions will replace any earlier version.

Page 27: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Jeff Stiff (u4689321) Linux Relational UI Desktop

Page: 5 Requirements Analysis Version: 1.0 Subject ref: COMP8790 Software Engineering Project Date: 26th October 2010 c:\documents and settings\jeff\desktop\uni-docs\new\final_versions\project-requirements.doc

3 Use Cases

The interactions that the User has with the system is predominately based on what task the user wishes to perform to a relationship. The User may choose to create or delate a relationship, or my wish to enhance a relationship by adding another relationship attribute. The Use Case below makes up the major functional sections of the main system “menu”.

Figure 1: System Use Case

Page 28: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Jeff Stiff (u4689321) Linux Relational UI Desktop

Version: 1.0 Requirements Analysis Page: 6 Date: 26th October 2010 Software Engineering Project Subject ref: COMP8790 c:\documents and settings\jeff\desktop\uni-docs\new\final_versions\project-requirements.doc

4 Screen Mock Ups

This section defines some sample screens that the user may be presented with when first logging into the system. These screens have been created following the Use Case defined in the previous section.

These screen mock-ups have been produced using TheBrain Personal Edition, a freely available tool from www.thebrain.com, and are designed to convey the intent of the system rather that the actual look and feel that the system will have.

4.1 Following Relationships

The following screen samples show a typical relationship map. This shows the ability to traverse a particular relationship based on a specific event, the event in this example is the fixing of a student enrolment in the COMP8790 subject at the ANU. These sample screens are not intended to show what the system will look like, but more give an overview of how the system may behave. A series of samples are shown, to show how the map state changes based on the user selection.

Figure 2: Fix Enrolment Main Node - Example

Selecting the COMP8790 node changes the map to display that node as the focus, and all of the associated nodes for COMP8790 and filtered to Fix Enrolment.

Figure 3: COP8790 with Filtering applied.

The filter has been removed from Figure 4, showing all the relationships that have been created for this user to the COMP8790 node.

Page 29: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Jeff Stiff (u4689321) Linux Relational UI Desktop

Page: 7 Requirements Analysis Version: 1.0 Subject ref: COMP8790 Software Engineering Project Date: 26th October 2010 c:\documents and settings\jeff\desktop\uni-docs\new\final_versions\project-requirements.doc

Figure 4: COMP8790 without Filtering

4.2 Time Line

The figure below shows an example of what the Time Line may look like.

Figure 5: Time Line - Example

The items that are able to be selected here are directly based on the last few selections by the user. This is a similar concept to “Recent Documents” in most systems, however this shows recent nodes or files selected.

Page 30: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Jeff Stiff (u4689321) Linux Relational UI Desktop

Version: 1.0 Requirements Analysis Page: 8 Date: 26th October 2010 Software Engineering Project Subject ref: COMP8790 c:\documents and settings\jeff\desktop\uni-docs\new\final_versions\project-requirements.doc

Appendix A - Requirements Matrix

The table below lists each requirement and the priority that has been placed on it.

Table 1: Requirements Matrix

Requirement Priority

2.1 Relationship and Attribute Mapping 1

2.1.1 Automatic Relationships 2

2.1.2 User Defined Relationships 1

2.2 Attribute Mapping 1

2.2.1 Automatic Relationship Attributes 2

2.2.2 User Defined Relationship Attributes 1

2.3 Relationship Ranking 2

2.4 User Interface 1

2.4.1 Search 1

2.4.2 Relationship Traversing 1

2.4.3 Time Line 2

2.4.4 Present a Relationship Orientated User Interface

2

2.5 Time Slider 3

2.5.1 Version Control Settings 3

Page 31: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Appendix B

System Design Document

Page 32: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Design

Software Engineering Project

26th October 2010

Jeff Stiff (u4689321)

Linux Relational UI Desktop

Page 33: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Jeff Stiff (u4689321) Linux Relational UI Desktop

Version: 1.0 Design Page: ii Date: 26th October 2010 Software Engineering Project Subject ref: COMP8790 c:\documents and settings\jeff\desktop\uni-docs\new\final_versions\project-design.doc

Document details Student name Jeff Stiff (u4689321)

Project name Linux Relational UI Desktop

Subject reference COMP8790

Document title Design

Document subtitle Software Engineering Project

Document number 3

Document version 1.0

Version date 26th October 2010

Document file name c:\documents and settings\jeff\desktop\uni-docs\project-design.doc

Print date Wednesday, 27 October 2010

Project participants Name

Student Jeff Stiff (u4689321)

Supervisors Shayne Flint

Ramesh Sankaranarayana

Document history

Version Date Author Description

0.1 Draft 20/09/2010 Jeff Stiff Initial draft

1.0 26/10/2010 Jeff Stiff Updates from Review, Final Release

Page 34: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Jeff Stiff (u4689321) Linux Relational UI Desktop

Page: iii Design Version: 1.0 Subject ref: COMP8790 Software Engineering Project Date: 26th October 2010 c:\documents and settings\jeff\desktop\uni-docs\new\final_versions\project-design.doc

Contents

1 Introduction....................................... ................................................. 1

1.1 Project Background ........................................................................................... 1 1.2 Project Scope .................................................................................................... 1 1.3 Reference Documentation ................................................................................ 1

2 Design............................................. .................................................... 2

3 System Components .................................. ....................................... 3

3.1 Core Components ............................................................................................. 3 3.1.1 Database ......................................................................................................... 3 3.1.2 Relationships, Nodes and Attributes................................................................ 4 3.1.3 Search ............................................................................................................. 4 3.1.4 Filtering............................................................................................................ 4 3.1.5 User Interface.................................................................................................. 4 3.1.6 Relationship Traversing................................................................................... 4

3.2 Non-Core Components ..................................................................................... 4 3.2.1 Relationship Ranking....................................................................................... 4 3.2.2 Time Line......................................................................................................... 5 3.2.3 Time Slider ...................................................................................................... 5 3.2.4 Automatic Relationships .................................................................................. 5 3.2.5 Automatic Relationship Attributes.................................................................... 5 3.2.6 Version Control System................................................................................... 5

4 Component Details .................................. .......................................... 6

4.1 Database Engine............................................................................................... 6 4.2 Relationships, Nodes and Attributes ................................................................. 6

4.2.1 Nodes .............................................................................................................. 7 4.2.2 Relationships................................................................................................... 8 4.2.3 Relationship Attributes..................................................................................... 8

4.3 Search ............................................................................................................. 10 4.3.1 Database Search – Nodes, Relationships and Relationship Attributes ......... 10 4.3.2 Full-Text Search ............................................................................................ 10 4.3.3 File-System Search ....................................................................................... 11 4.3.4 Internet Search.............................................................................................. 11 4.3.5 Searching Priority .......................................................................................... 11

4.4 Filtering............................................................................................................ 11 4.5 User Interface.................................................................................................. 12

4.5.1 Interface layout .............................................................................................. 13 4.5.2 Relationship Map........................................................................................... 14 4.5.3 Relationship Traversing................................................................................. 15 4.5.4 Relationship Ranking..................................................................................... 15 4.5.5 Time Line....................................................................................................... 16 4.5.6 Time Slider .................................................................................................... 16 4.5.7 UI Event-Response Table ............................................................................. 17

4.6 Automatic Relationships.................................................................................. 19 4.7 Automatic Relationship Attributes ................................................................... 19 4.8 Version Control System................................................................................... 19

Appendix A – System Icon Samples ................... ................................. 20

Appendix B - Software Selection .................... ...................................... 21

Page 35: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Jeff Stiff (u4689321) Linux Relational UI Desktop

Version: 1.0 Design Page: iv Date: 26th October 2010 Software Engineering Project Subject ref: COMP8790 c:\documents and settings\jeff\desktop\uni-docs\new\final_versions\project-design.doc

List of tables Table 1: Node Attributes ..................................................................................................... 7 Table 2: Relationship Attributes .......................................................................................... 8 Table 3: Relationship Attribute Attributes............................................................................ 9 Table 4: UI Event-Response Table ................................................................................... 17 Table 5: System Icon Samples ......................................................................................... 20 Table 6: Software Selection .............................................................................................. 21

List of figures Figure 1: Relational Engine Component Diagram ............................................................. 3 Figure 2: Nodes and Relationships ..................................................................................... 6 Figure 3: Sample Nodes and Relationships........................................................................ 7 Figure 4: Search UI ........................................................................................................... 10 Figure 5: Filter UI............................................................................................................... 12 Figure 6: Screen Layout - All Expanded ........................................................................... 13 Figure 7: Screen layout - All Iconised ............................................................................... 14 Figure 8: Sample Relationship Map .................................................................................. 15 Figure 9: Relationship Traversal ....................................................................................... 15 Figure 10: Time Line Sample ............................................................................................ 16 Figure 11: Time Slider Sample.......................................................................................... 17

Page 36: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Jeff Stiff (u4689321) Linux Relational UI Desktop

Page: 1 Design Version: 1.0 Subject ref: COMP8790 Software Engineering Project Date: 26th October 2010 c:\documents and settings\jeff\desktop\uni-docs\new\final_versions\project-design.doc

1 Introduction

This document defines the system design for the Linux Relational User Interface (RUI) Desktop project that has been undertaken as part of the Australian National University (ANU) Master of Computing Software Engineering Project.

1.1 Project Background

Mainstream computer desktop interfaces all behave in a similar fashion. That is, they all treat the system as a group of objects. These objects may be classified into semi-functional groups, or not, depending on the specific desktop involved. These groups may be along the lines of Internet, Office, Games etc., with applications that pertain to those broad areas being part of that group.

What this project aims to achieve, is to provide a new method of interaction between the user and the computer. The focus of this project is to switch the model from Object driven to Relationship driven. Rather than navigating though menus looking for the application to open, the user will navigate through a web of relationship connections between objects. Once at a node of interest then the user may chose what action they wish to take, on the file or links that have been presented.

Each document, application and event may be represented as an attribute to any relationship. This is where the “Relational” component of the project comes from. This is not “relational” in the sense of a database relation, but it is to indicate that the relationship between objects are the focal point for the system. These relationships may be automatically set by the system, or may be created or deleted by the users themselves.

The Relationship User Interface (RUI) has several features that lend itself to being an enhancement of a Zoomable User Interface (ZUI) and the Desktop Relational Search tool. A RUI is an interface that presents all the information stored or required by the user in a relational map as nodes and connecting lines on a surface that can be panned and zoomed. This lends itself to easy control via a touch screen or a mouse and keyboard.

1.2 Project Scope

The duration of this project is very limited, as such the project is focused on delivering the first two phases of the development cycle, that being the requirements analysis and the design document. It is the intention that by the end of this project the requirements and design shall be documented, and several small proof-of-concept implementations may have been developed where needed.

1.3 Reference Documentation

This document should be read in conjunction with the Requirements Analysis for the Software Engineering Project, version 1.0, dated 26th October 2010.

Page 37: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Jeff Stiff (u4689321) Linux Relational UI Desktop

Version: 1.0 Design Page: 2 Date: 26th October 2010 Software Engineering Project Subject ref: COMP8790 c:\documents and settings\jeff\desktop\uni-docs\new\final_versions\project-design.doc

2 Design

The following section defines the design of the project. The interaction between user and system, and the linking of relationships throughout the system are the core components of this project.

It is expected that the system will be developed in the Java language, however this design does not go down to the actual coding level and as such remains at a high enough level to not preclude any language that a developer may deem more appropriate for the task. The deciding factor for Java as the development language was the availability of the Piccolo2D and Neo4j libraries as detailed below.

It is deemed that this shall be a FOSS (Free and Open Source Software) project, and as such each component that will make up the system needs to also be under a FOSS Licence. The preferred FOSS Licence is GPLv3, however any of the other FOSS licences will be considered if the need to use that product is justified.

Page 38: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Jeff Stiff (u4689321) Linux Relational UI Desktop

Page: 3 Design Version: 1.0 Subject ref: COMP8790 Software Engineering Project Date: 26th October 2010 c:\documents and settings\jeff\desktop\uni-docs\new\final_versions\project-design.doc

3 System Components

3.1 Core Components

This section defines the core components of the system. Each component will be detailed more thoroughly in the subsequent sections. The major components are the Interface and the placement of specific elements within the interface, and the background components driving the system behind the scenes.

Figure 1: Relational Engine Component Diagram

3.1.1 Database

The system employs a database to keep track of all the relationships that are defined. It is envisaged that a Graph Database shall be used to take advantage of the speed and efficiency of a these types of databases for the data being managed.

Page 39: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Jeff Stiff (u4689321) Linux Relational UI Desktop

Version: 1.0 Design Page: 4 Date: 26th October 2010 Software Engineering Project Subject ref: COMP8790 c:\documents and settings\jeff\desktop\uni-docs\new\final_versions\project-design.doc

3.1.2 Relationships, Nodes and Attributes

At the centre of the system is the ability to create and maintain a group of Relationships. These Relationships are relationships between Nodes within the system. A Node is a representation of any object. Attributes are the features of the relationship between the two connected Nodes.

3.1.3 Search

The System shall provide a search mechanism (Requirements 2.4.1). This search mechanism shall in the background consist of several disparate search engines. These will be a Relationship/Attribute database search; a Full-Text file content search; a File System search; and an Internet based search.

3.1.4 Filtering

In a similar vein to the search mechanism, the user shall also be able to apply filters over the system. These filters will go across the entire system, regardless of whether a search is performed, or a straight Relationship Traversal is enacted.

3.1.5 User Interface

The User Interface (UI) shall be broken into several on-screen sections. These sections shall be configurable by the user as to where they will be displayed, or in some instances if they are displayed at all. The individual components of the UI are detailed in the Component Details section below. These components cover the requirements detailed in Section 2.4 of the Requirements Analysis.

3.1.6 Relationship Traversing

As part of the UI the system will allow the traversal of relationships (Requirements 2.4.2). This is core to the system. The graphical system will adjust the map of the relationships presented based on the newly selected node being the central node. This will be the main method of navigating through the system.

3.2 Non-Core Components

This section defines modules that should be implemented to give the complete system experience, but are not core features of the system.

3.2.1 Relationship Ranking

Each relationship shall be able to be given a weighting (Requirements 2.3). This allows the displaying of a limited set of relationships should a specific node have too many relationships to be comfortably displayed on one screen. The highest ranking relationships would be displayed prior to any lower ranking, thus keeping the screen relatively clutter free.

Page 40: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Jeff Stiff (u4689321) Linux Relational UI Desktop

Page: 5 Design Version: 1.0 Subject ref: COMP8790 Software Engineering Project Date: 26th October 2010 c:\documents and settings\jeff\desktop\uni-docs\new\final_versions\project-design.doc

3.2.2 Time Line

A Time Line of what Nodes the user has selected during the session shall be built by the system and displayed as another means of navigating back to nodes previously selected (Requirement 2.4.3).

3.2.3 Time Slider

The Time Slider provides the mechanism to roll the system back to an earlier desired time. This should not be confused with the Time Line described in Section 3.2.2 above. This is not a session based history, but a look at the system state at an earlier time via a VCS type system (Requirement 2.5).

3.2.4 Automatic Relationships

The system shall provide the means for relationships to be automatically added between nodes where possible (Requirement 2.1.1).

3.2.5 Automatic Relationship Attributes

The system shall provide the means for Relationship Attributes to be automatically created on a relationship where possible (Requirement 2.2.1).

3.2.6 Version Control System

The system shall employ a Version Control System (VCS) file system to maintain revision history of all files on the system. This shall allow the effective management of the files, and provides the ability of the Time Slider feature to work on files under the systems control (Requirement 2.5.1).

Page 41: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Jeff Stiff (u4689321) Linux Relational UI Desktop

Version: 1.0 Design Page: 6 Date: 26th October 2010 Software Engineering Project Subject ref: COMP8790 c:\documents and settings\jeff\desktop\uni-docs\new\final_versions\project-design.doc

4 Component Details

This section provides a more detailed view of how each of the features of the Relational UI Desktop are to be implemented and how these features are expected to behave.

4.1 Database Engine

There are several Graph Databases that would be suitable for this application; however the Neo4j database, http://neo4j.org, has been selected for several reasons.

Selection Reasons:

� Neo4j is distributed under the AGPLv3 licence (http://www.gnu.org/licenses/agpl-3.0.html). This licence has a mutual compatibility agreement with the GPLv3 licence (http://www.gnu.org/licenses/gpl.html). Each licence specifies the compatibility with the other in their respective Section 13.

� Neo4j is a very mature Graph Database. According to the Neo4j website (http://neo4j.org), the database has been under development for more than 10 years, and has been in commercial use for at least 7 years.

� Provides an embedded database engine, which would allow for the system to be delivered without the need for additional installation and configuration, as it would all be embedded within the system.

� Is itself developed in Java. There are several advantages in having the database engine developed in the same language as the main system. These include the ability to combine any run-time libraries that need to be distributed, and an overall ability to maintain a simpler system by minimising the amount of run-time libraries that need to be distributed.

4.2 Relationships, Nodes and Attributes

At the core of the system is the requirement to be able to map relationships and their attributes between a set of nodes. Each node in the system will have a zero to one mapping to any other node. The link between the nodes is the relationship. Each relationship has one to many attributes.

Figure 2: Nodes and Relationships

0,1 0,1

0,1 0,1

0,1

0,1

0,1

0,1 0,1 Node A

Node B

Node D

Node C

Page 42: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Jeff Stiff (u4689321) Linux Relational UI Desktop

Page: 7 Design Version: 1.0 Subject ref: COMP8790 Software Engineering Project Date: 26th October 2010 c:\documents and settings\jeff\desktop\uni-docs\new\final_versions\project-design.doc

Figure 3: Sample Nodes and Relationships

4.2.1 Nodes

A Node is the representation within the system of a specific object. This object may be a person, a file, an event, etc. Anything that the user deems to be an object of significance shall be represented as a Node. Nodes by themselves reflect very little information, however, when a node is linked to another node via a relationship, the information that the node conveys instantly increases. The Node may have unlimited information attached to it, in the form of a key, value pair. The Node will have as a minimum several attributes of its own, these are detailed in Table 1 below.

Table 1: Node Attributes

Attribute

Man

dato

ry

Typ

e

Siz

e

Uni

que

Description

Name Yes String 255 Yes Node Name, this is name displayed to the User

ID Auto Number - Yes System generated ID for the Node

Creation Date Auto Date/Time - No Date the Node was created, set by the system

Active Date No Date/Time - No A Date the Node is considered “active” from.

Example: Start Date of an Event

De-Activated Date

No Date/Time - No A Date the Node is no longer considered active.

Example: End Date of an Event

Running Attended Attended

Knows Node A Name: Fred

Node B Name: Bob

Node D Name: Training Start: 20-10-2010 End: 22-10-2010

Node C Name: Floriade Start: 11-09-2010 End: 10-10-2010

Page 43: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Jeff Stiff (u4689321) Linux Relational UI Desktop

Version: 1.0 Design Page: 8 Date: 26th October 2010 Software Engineering Project Subject ref: COMP8790 c:\documents and settings\jeff\desktop\uni-docs\new\final_versions\project-design.doc

4.2.2 Relationships

A Relationship is the representation of a link between two Nodes. A Relationship signals that the two nodes “have a relationship”, that is, they are connected in some way. Two nodes can have either:

• No relationship to each other, and therefore will not be linked, or

• Will have a single relationship to each other, and will therefore be linked. The specifics of the relationship will be defined by the Attributes on the Relationship.

Table 2: Relationship Attributes

Attribute

Man

dato

ry

Typ

e

Siz

e

Uni

que

Description

Type Yes Lookup String

255 No Type of Relationship. Example: Knows, Attends, Runs, Child.

Default = Knows

ID Auto Number - Yes System generated ID for the Relationship

Node 1 ID Yes Number - No ID of first Node being related

Node 2 ID Yes Number - No ID of second Node being related

Creation Date Auto Date/Time - No Date the Relationship was created, set by the system

Active Date No Date/Time - No A Date the Relationship is considered “active” from.

Example: Start Date of an Event

De-Activated Date

No Date/Time - No A Date the Relationship is no longer considered active.

Example: End Date of an Event

Rank No Lookup 1 No Ranking of the Relationship. L/M/H for Low/Medium/High

Default: Medium

4.2.3 Relationship Attributes

Each relationship may have zero or more attributes that help to describe or define the relationship. These are separate from the attributes defined in section 4.2.2 above. The attributes here are the attributes that form part of the relationship.

Relationship Attributes Example:

Two people, Fred and Bob, represented by two Nodes, may have a single Relationship. But this relationship may have many facets.

Page 44: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Jeff Stiff (u4689321) Linux Relational UI Desktop

Page: 9 Design Version: 1.0 Subject ref: COMP8790 Software Engineering Project Date: 26th October 2010 c:\documents and settings\jeff\desktop\uni-docs\new\final_versions\project-design.doc

Relationship: Fred Knows Bob

Relationship Attributes:

• Fred works with Bob

• Fred works in the same office with Bob

• Fred plays squash with Bob on a Wednesday night

• Fred and Bob had a Work meeting about some Training yesterday

There is no limit to the number of attributes that a relationship may have. An attribute may just be keywords that help define the relationship, or they may be other objects such as file, web pages or events that represent interaction between the two linked nodes.

A Relationship Attribute may actually exist on more than one relationship. This would be evident of a meeting between several people. They would each be a participant in the meeting, and therefore would each have their relationships “enhanced” by the attribute of the meeting. This may be represented by different Relationship Attributes across the different relationships; however this poses the issue of keeping these all in synchronisation when they are all referring to the same event. It is therefore recommended that they are defined as the same attribute that exists on different relationships.

Table 3: Relationship Attribute Attributes

Attribute

Man

dato

ry

Typ

e

Siz

e

Uni

que

Description

Type Yes Lookup String

25 No Type of Attribute.

Example: Text, File, Web

ID Auto Number - Yes System generated ID for the Attribute

Relationship ID

Yes Number List

- No ID of any Relationship this Attribute is associated with

Creation Date Auto Date/Time - No Date the Attribute was created, set by the system

Active Date No Date/Time - No A Date the Attribute is considered “active” from.

Example: Sister-in-Law is wedding date

De-Activated Date

No Date/Time - No A Date the Attribute is no longer considered active.

Example: Sister-in-Law is divorce date

File/Web No String 255 No A link to a file on the system, or accessible to the system such as a

network file share, or via the Internet

The File/Web attribute would be filled if the attribute is a reference to a file that is accessible from the system, either a local file, a network file or a file accessed via the

Page 45: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Jeff Stiff (u4689321) Linux Relational UI Desktop

Version: 1.0 Design Page: 10 Date: 26th October 2010 Software Engineering Project Subject ref: COMP8790 c:\documents and settings\jeff\desktop\uni-docs\new\final_versions\project-design.doc

Internet. This also includes a simple website, as this is just a special type of file. Based on the file type that is stored, the system will take different actions if the link is clicked. If the attribute links to a file that has a handler application installed then that application will launch with the file opened. If the attribute links to a website, then the site will be opened in the default system Web Browser. This behaviour will be determined by standard Mime-types as used in most current operating systems.

4.3 Search

The Search component of the system will be based on four different search methods. These methods will be employed based on a user selectable search criteria, or based on the system default behaviour.

The Search box, as shown in Figure 4 below, shall be displayed in the UI at one of the edges. This shall be user defined, but will default to the lower left corner of the screen. The search box will consist of a single text box, where the search criteria will be entered, and the Search Button, and a smaller button to bring up an “Advanced Search” screen. The Advanced Search screen shall provide the user with the ability to select or de-select various search engines, or more advanced features of a search, such as Date, File Type etc.

Figure 4: Search UI

The Search UI can be iconified. This will then only display the Search Icon in one corner of the screen until the icon is selected. Once selected the Search interface will expand to display in the same corner of the screen.

4.3.1 Database Search – Nodes, Relationships and Re lationship Attributes

This search method will perform a search against the database looking for any matches to the search criteria specified within the Names and attributes of the Nodes, Relationships or the Relationship Attributes.

This will be the fasted search method, and will return a map of all the matching results within the Relational UI. The Search Node will be the central node, and all the results shall be returned as being related to the Search Node. Any inter-relationships between the returned nodes shall also be presented in the Relational Map.

4.3.2 Full-Text Search

The system shall also employ a full-text search engine for the searching of document content. The default setting will be that all non-binary files within the system shall be full-text indexed.

The user may however, override the system-wide setting of this feature and exclude particular directories, or change the behaviour to only full-text index specific directories and their child directories. This may be set for example to only index the User’s Home directory.

Page 46: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Jeff Stiff (u4689321) Linux Relational UI Desktop

Page: 11 Design Version: 1.0 Subject ref: COMP8790 Software Engineering Project Date: 26th October 2010 c:\documents and settings\jeff\desktop\uni-docs\new\final_versions\project-design.doc

The results of this search will be displayed, as per any search, as a Relational Map with the search node displayed as the central node and all matches presented on the Relational Map as related nodes.

4.3.3 File-System Search

The File-System Search shall perform a search for any files or directories accessible by the system that match the search criteria. The default method for this search will be to just search for any file or directories that have a name matching the search criteria within the User’s Home directory. Advanced searching via this method may include additional criteria such as the File Creation or Last Access dates.

Again, the results shall be presented as a Relational Map.

4.3.4 Internet Search

The final search method shall perform an Internet based search. This will use a standard available Internet Search Engine, such as Google (www.google.com), but shall be easily replaced with any other Internet Search Engine by the user.

The Search Relational Map shall be the result of this search.

4.3.5 Searching Priority

Searching shall be performed on the different systems based on user selection. However the default behaviour shall be to perform the search against the database searching for Nodes, Relationships or Relationship Attributes that match the search criteria. If there are no results found, the search mechanism shall automatically move onto a Full-Text search of the document content of all documents contained in the system. If there are again no results, the search will move onto the File System Search, and finally the Internet Search shall be performed.

The user will be able to change this behaviour based on an Advanced Search, where they will be able to specify which search method, including all methods, that should be performed, regardless of if the prior search returns any results.

4.4 Filtering

The system shall provide the mechanism to filter results to searches and relationship traversals. This method will aid the ability to limit the amount of data that is returned to the user when they are navigating through the system. Regardless of what action the user performs, if a filter has been applied that filter will apply all actions until the filter is removed.

The Filter box, as shown in Figure 5 below, shall be displayed in the UI at one of the edges. This shall be user defined, but will default to the lower left corner of the screen, just to the right of the Search field. The filter box will consist of a single text box, where the filter criteria will be entered and three buttons; Filter, Clear, and Advanced. The Filter button will apply the filter as defined in the text box. The Clear button shall clear any filter that has been applied to the system, and clear any text that is currently displayed in the filter text box field. The Advanced button shall present the Advanced Filter dialog to the user. The Advanced screen shall provide the user with the ability to select or de-

Page 47: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Jeff Stiff (u4689321) Linux Relational UI Desktop

Version: 1.0 Design Page: 12 Date: 26th October 2010 Software Engineering Project Subject ref: COMP8790 c:\documents and settings\jeff\desktop\uni-docs\new\final_versions\project-design.doc

select various additional filtering features, such as applying only to Relationships, Specific File Types etc.

Figure 5: Filter UI

The Filter UI can be iconified. This will then only display the Filter Icon in one corner of the screen until the icon is selected. Once selected the Filter interface will expand to display in the same corner of the screen. If a filter has been applied and the Filter interface is iconified again, the icon will appear depressed so as to alert the user that the results the system is returning are currently being filtered.

4.5 User Interface

The User Interface shall be built in a modular fashion so components can be moved around the screen or iconified to clear screen real estate. Appendix A provides a sample of the intended icons for each feature that may be reduced to a simple icon on the interface.

The library, or framework, that has been selected for the relational mapping graphic engine is the Java based Piccolo2D library, http://www.piccolo2d.org. The Piccolo2D website defines Piccolo2D as a toolkit for developing ZUI's. A ZUI is a Zoomable User Interface. Piccolo2D is the latest offering from the same team that provided Pad++, the original ZUI. Whilst a ZUI is significantly different to a RUI, there are similarities that make basing a RUI on a ZUI base practical. The Piccolo2D toolkit provides an easy means of representing nodes and relationships in a graphical manner. The drawing panel also inherently allows for zoom and pan operations. The pan operation allows the Relational Map to be easily and quickly re-centred based on the latest selected node.

There were other possible options for the Relational Mapping toolkit, however most of them suffered a similar issue, the map is redrawn on each selection. This requires the user to search for the nodes new location after each selection. It was for this reason that it was decided to pan the map on selection rather than redraw the map each time. This would also allow for simpler code, although the drawing routine would still need to be developed to enable the rendering of search results.

The distinction between these two options, Pan or Redraw the screen, must be made. The first option redraws the map, nodes and links, on each selection, which requires a complex graphic algorithm to ensure the resulting map does not have overlapping nodes and links do not cross each other unless required. The second option does not change the placement of any nodes, and keeps the map as defined by the user, with the only change being the drawing surface pans to centre the newly selected node. Panning would allow the user to set where they wish a particular node to live on the panel, and it would not move relative to the rest of the nodes based on any selection. This helps to ensure easy selection of a node if its location on the panel is known, as the user can pan and zoom directly to the location. If the map was to redraw each time, the searching of nodes would become the primary means of locating even frequently accessed nodes.

Page 48: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Jeff Stiff (u4689321) Linux Relational UI Desktop

Page: 13 Design Version: 1.0 Subject ref: COMP8790 Software Engineering Project Date: 26th October 2010 c:\documents and settings\jeff\desktop\uni-docs\new\final_versions\project-design.doc

4.5.1 Interface layout

The screen layout shall provide the most screen real estate to the centre of the screen for the Relationship Map to be displayed. Several areas of the interface shall be configurable by the user, such as the ability to move where the default Search Area is displayed from the bottom of the screen to the top.

Figure 6: Screen Layout - All Expanded

Figure 6 shows the sample layout of the screen when all the features are expanded. This does not show the Time Slider area, as this is only present when the system has been rolled back. The Time Slider icon would be present by default in the far right of the Time Line Area. This figure shows the default position of the on-screen features when they are expanded.

Figure 7 shows the sample screen layout when all on-screen features have been reduced to icons. By selecting the specific icon the feature will be expanded to take its last on-screen position. The default is as shown above, but may be reset by the user to another location on the screen top or bottom edge.

Page 49: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Jeff Stiff (u4689321) Linux Relational UI Desktop

Version: 1.0 Design Page: 14 Date: 26th October 2010 Software Engineering Project Subject ref: COMP8790 c:\documents and settings\jeff\desktop\uni-docs\new\final_versions\project-design.doc

Figure 7: Screen layout - All Iconised

The Relational Mapping Canvas is the location that the relationships and nodes are displayed on the screen. This area will be the largest are of the screen as the graphical area needed to display even a small set of nodes and relationships is relatively large if the display is to remain clearly readable.

4.5.2 Relationship Map

The relationship map is the main feature of the system. This is where the nodes and relationships defined in the system are displayed in a graphical web to the user. The system shall draw a central node on the screen represented by a box with the node’s name appearing as text within the box. All relationships that are linked to the node shall be drawn as lines coming out of the node. These relationships shall not have any text drawn on them, however the name of the relationship shall be displayed when the mouse is held over each relationship. At the end of each relationship drawn, the end node for that relationship shall be displayed, once again represented by a box with the node’s name appearing as text within the box.

A right-click of the relationship will display the Relationship Attribute page. This page will display all the current attributes that are associated with this relationship. From this screen the user will have the ability to create new attributes, edit existing attributes or remove selected attributes.

The sample Relationship Map shown in Figure 8 has been produced using TheBrain Personal Edition available from www.thebrain.com, and is not intended to be the exact display of the system but only as an indication of how this feature should look.

Page 50: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Jeff Stiff (u4689321) Linux Relational UI Desktop

Page: 15 Design Version: 1.0 Subject ref: COMP8790 Software Engineering Project Date: 26th October 2010 c:\documents and settings\jeff\desktop\uni-docs\new\final_versions\project-design.doc

Figure 8: Sample Relationship Map

4.5.3 Relationship Traversing

The system shall provide the means to traverse the relationships by way of clicking on a node that is displayed, but not as the central node. This will have the effect of moving the selected node to the central node position and redrawing the relationship map based on the newly selected node.

The new central node will be drawn. Any relationships to or from this node and the related node shall also be drawn. Unless the system currently has a filter applied, or the number of related nodes is above the drawing threshold, all related nodes shall be displayed around the central node.

Clicking on a specific node shall have the additional effect of adding a reference to that node into the last position of the Time Line, and moving all existing Time Line entries down the chain one position.

Figure 9 shows a sample of what the relationship map could look like as the result of the COMP8790 node being selected from the original map displayed in Figure 8 above. The figures show a sample of the relationship mapping behaviour as different nodes are selected, and the way that the system redraws the relation web. These figures have once again been produced from within the desktop application TheBrain, and are indicative only of the way the system shall behave with regards to the relationship mapping and redrawing of the relationship web on each traversal.

Figure 9: Relationship Traversal

4.5.4 Relationship Ranking

The system shall employ the ability to provide a weighting rank for each relationship. The purpose of this ranking is only to provide a mechanism to reduce the amount of results that may need to be displayed on the screen for very active nodes where they have

Page 51: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Jeff Stiff (u4689321) Linux Relational UI Desktop

Version: 1.0 Design Page: 16 Date: 26th October 2010 Software Engineering Project Subject ref: COMP8790 c:\documents and settings\jeff\desktop\uni-docs\new\final_versions\project-design.doc

a large number of in/out-bound relationships. To ensure that the most appropriate relationships are always displayed first, the highest ranking relationships shall be displayed until either all the relationships have been displayed or the limit of relationships to display has been reached. If the number to display has been reached the system shall display to the user clearly that there are more relationships that match the search or traversal. The user shall then have the option to display the next group of relationships or to refine their search criteria to return fewer results.

To ensure that the user is not burdened with having to give meaningless rankings to each relationship there will only be three levels. These will be Low, Medium and High. The system will by default apply a weight of Medium to any relationship created unless the user selects a different weight. The weight may be changed at any time by the user.

4.5.5 Time Line

The Time Line shall be a non-persistent history of what nodes the user has selected during the current session only. There shall be no mechanism to save or restore a Time Line across sessions.

The Time Line shall be displayed by default at the bottom right of the screen. The position of the Time Line shall be user selectable between the top and bottom right of the screen.

The Time Line may also be iconified by the user. This will not stop the Time Line from being built, and when restored to display state the Time Line shall reflect the current selections as if it had never been iconified.

Each entry in the Time Line shall be selectable. If the user selects an entry, the Node that the entry represents shall be returned to the central node position.

Figure 10: Time Line Sample

4.5.6 Time Slider

The Time Slider shall display a selectable timeline for the purpose of providing a read-only view of the state of the system, including files, nodes, relationships and relationship attributes.

The user shall be presented a method of selecting the date and time that they wish to view. This will be achieved by a Calendar slider, similar to setting or searching for a date in most Personal Information Management software. The interface shall also provide a “Now” button to return the user to the current system state.

Page 52: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Jeff Stiff (u4689321) Linux Relational UI Desktop

Page: 17 Design Version: 1.0 Subject ref: COMP8790 Software Engineering Project Date: 26th October 2010 c:\documents and settings\jeff\desktop\uni-docs\new\final_versions\project-design.doc

Figure 11: Time Slider Sample

The underlying system for this feature shall be a combination of a database search for the effective start and end dates of the Nodes, Relationships and Relationship Attributes and a Version Control System (VCS) style file system for the actual files on the system. See Section 3.2.6 for more information regarding the VCS.

The roll-back will only provide a read-only view of the system at the earlier state. This is design to prevent the user being able to adversely affect the system by changing something during a roll-back that would break the system once returned to the current state.

It is proposed to distinguish the fact that they system is in the roll-back state by changing the screen outline. This would provide a coloured border of approximately two pixels wide around the screen to give a subtle indication to the user that they are not looking at the current system state without overly interfering with the display.

4.5.7 UI Event-Response Table

This section defines the default behaviour of the system based on user action. The table shows what response the system will take for any given event. This shows how the RUI components of the system behave, all other actions are as expected and are not listed in the table.

Table 4: UI Event-Response Table

Event State Response

First Start System displays a blank Relational Map System Start

Previous Session System loads and displays the Relational Map as saved on exit of the previous session

System Shut-Down

Any State Save Relational Map and shutdown the PC

On a Node Display the attributes of the Node Mouse Hover

On a Relationship Display the Attributes of the Relationship

On a Node Select the Node, centre the node in the Relational Panel Mouse Left-Click

On a Relationship Select the Relationship

Page 53: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Jeff Stiff (u4689321) Linux Relational UI Desktop

Version: 1.0 Design Page: 18 Date: 26th October 2010 Software Engineering Project Subject ref: COMP8790 c:\documents and settings\jeff\desktop\uni-docs\new\final_versions\project-design.doc

Event State Response

On clear panel space

De-select any selected item if one selected.

No Action otherwise

On a Node Display the Edit node & Attributes Screen. This screen allows for the editing of the selected node, the deletion of the selected node and the manipulation of the attributes for the node.

On a Relationship Display the Edit Relationship & Attributes Screen. This screen allows for the editing of the selected relationship, the deletion of the relationship and the manipulation of the attributes for the relationship.

On clear panel space

Display the Node Creation Screen

On Search Field Minimise the Search Area

Mouse Right-Click

On Filter Field Minimise the Filter Area

Mouse Scroll Wheel – Up

On the panel Zoom the panel in

Mouse Scroll Wheel – Down

On the panel Zoom the Panel Out

On a Node Move the Node, all relationships move with the node. Left-Click and Drag

On clear panel space

Pan the Panel

With a Node Selected

The node is deleted, after confirmation. All documents, websites and any other information directly attached to the node is deleted along with the node.

Delete Key

With a Relationship selected

The relationship is deleted, after confirmation. All documents, websites and any other information directly attached to the relationships deleted along with the relationship.

Page 54: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Jeff Stiff (u4689321) Linux Relational UI Desktop

Page: 19 Design Version: 1.0 Subject ref: COMP8790 Software Engineering Project Date: 26th October 2010 c:\documents and settings\jeff\desktop\uni-docs\new\final_versions\project-design.doc

4.6 Automatic Relationships

The system shall provide automatic relationship mapping where the system is able to automatically determine the existence of such a relationship.

There are several examples of where this behaviour may be possible.

Examples:

1 This type of relationship may be as simple as linking two nodes that represent people that work for the same company. The relationship would exist between the two nodes based on Employer of the contacts.

2 The second example of an automatic relationship would be to related two events that are held in the same town. An example would be that the Canberra Floriade is related to the Summer Nationals, as both events are located in Canberra.

4.7 Automatic Relationship Attributes

The system shall provide the mechanism to add automatic relationship attributes to a relationship where the system is able to automatically determine that such a relationship attribute exists. Automatic Relationship Attributes shall be added with a weight of Low so as the automatic relationships do not swamp those created by the user. The user may at any stage modify the rank of any relationship attribute, including automatic ones.

An example of an Automatic Relationship Attribute is the adding of an attribute to multiple relationships based on an email being sent to the multiple contacts. Emails with the same subject shall also be added to as an attribute of a relationship if existing emails of that title exist in the attributes.

4.8 Version Control System

The system shall provide the means to maintain a version history of all the files on the system. This feature shall be provided by the file system itself. There are several options available for the Linux environment, with the preferred choice being ext3cow, http://www.ext3cow.com/Welcome.html. The main factors in choosing this file system is that it runs on the newer kernels, whereas a lot of the other offerings have been designed to operate more effectively under the 2.4 kernel. However the main reason for the selection of this file system is that it provides the Time Slider functionality out of the box. Under the ext3cow system the Time Slider functionality is known as time-shifting.

The default behaviour shall be that all files on the system are under a VCS control. The user shall have the option of Opting Out any files or directories that they do not wish to have version controlled.

The VCS file system is designed to be almost transparent to the user. They will not need to know how to control a typical VCS to be able to operate with the file system. There is no requirement to check files in and out of the system for editing, as the versioning happens automatically when the file is written to without the need for any specific action from the user.

Page 55: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Jeff Stiff (u4689321) Linux Relational UI Desktop

Version: 1.0 Design Page: 20 Date: 26th October 2010 Software Engineering Project Subject ref: COMP8790 c:\documents and settings\jeff\desktop\uni-docs\new\final_versions\project-design.doc

Appendix A – System Icon Samples

Sample Icons for this document have been sourced from IconsPedia at http://www.iconspedia.com. At the time of writing all these icons were listed as being released under the GNU Lesser General Public License. If these specific icons are to be used for the system then the usage agreements should be checked.

Table 5: System Icon Samples

Icon Name Icon Source

Advanced

http://www.iconspedia.com/icon/advanced-3-86.html

Filter

http://www.iconspedia.com/icon/filter-4084.html

Search

http://www.iconspedia.com/icon/find-4085.html

Time Line

http://www.iconspedia.com/icon/rebuild-4161.html

Time Slider

http://www.iconspedia.com/icon/appointment-4027.html

Page 56: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Jeff Stiff (u4689321) Linux Relational UI Desktop

Page: 21 Design Version: 1.0 Subject ref: COMP8790 Software Engineering Project Date: 26th October 2010 c:\documents and settings\jeff\desktop\uni-docs\new\final_versions\project-design.doc

Appendix B - Software Selection

The table below lists the software that has been selected as the preferred software for the particular role. For the justification of why the particular software has been chosen review the appropriate section above.

Table 6: Software Selection

Software Feature

Ext3cow Versioning File System

Java Development language

Neo4j Graph Database

Piccolo2D ZUI Framework

Page 57: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Appendix C

IOzone File-System Test Results

Page 58: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

IOzone – ext3 Test ResultsWriter Report

4 8 16 32 64 128 256 512 1024 2048 4096 8192 1638464 752329 889431 863676 874936 926260

128 927549 1007629 1057236 1030846 1057236 1007629256 1003679 1089202 1117543 1122215 1108314 1126926 1093639512 1036527 1108203 1155924 1188552 1207261 1163439 1069035 1100818

1024 1083546 1085737 1183902 1204487 1189476 1200447 1091809 1089317 11084342048 1099890 1112425 1164293 1206823 1197736 1190763 1181103 1130283 1107691 10975014096 1070009 1144119 1172943 1185161 1192069 1187208 1149554 1076176 1097558 1060040 10261048192 1042885 1097691 1137935 1130856 1166444 1170816 1124344 1089201 1083739 1060164 1021583 993463

16384 1029400 1091169 1113266 1128291 1125040 1134624 1114855 1060587 1076689 1052223 1003499 991826 99660132768 0 0 0 0 1115885 1115242 1110664 1049618 1073340 1038734 1008616 977247 98137165536 0 0 0 0 1111611 1127307 1072812 1076054 1067205 1032111 1012610 1011231 1012684

131072 0 0 0 0 562786 1127626 1055297 1064958 1080809 1073023 1019102 1013468 1014691262144 0 0 0 0 1080070 1127335 1113355 1084937 1085580 1067335 1025085 1020758 1006048524288 0 0 0 0 928099 1129570 1105292 1071856 1074094 1059758 1005255 1002596 1018511

1048576 0 0 0 0 212556 164738 164055 163684 167877 155301 165018 170052 1571932097152 0 0 0 0 96139 97758 97896 98028 96868 96793 92424 85815 92285

Re-writer Report4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384

64 2561267 1679761 3057153 2662899 2444640128 2558895 3657016 3468030 2969325 3895854 3867787256 3465855 3879045 4132864 3667079 3368013 3557725 3087188512 2995907 3158966 3481620 3459188 3550700 3393590 3264616 2739816

1024 2942149 3281592 3655895 3506651 3447541 3379719 3170172 2592318 25222882048 3094573 3117032 3502085 3358321 3057127 3430751 2980747 2691246 2645657 24096504096 2582737 2834585 2854365 2892815 2952980 2923832 2782252 2531363 2496056 2446645 22755378192 2455704 2646965 2862165 2786495 2807212 2808359 2666686 2443132 2423658 2286410 2138288 2109149

16384 2374483 2570797 2657180 2734798 2721153 2735669 2590274 2429468 2402291 2305960 2086847 2071310 211758532768 0 0 0 0 2642609 2656913 2580780 2390292 2406025 2347425 2142802 2006853 201167065536 0 0 0 0 2658321 2711367 2479777 2403308 2376812 2235419 2130360 2118245 2137234

131072 0 0 0 0 2697674 2725884 2400242 2391648 2460144 2418531 2183912 2147804 2174350262144 0 0 0 0 2697567 2803197 2680246 2482142 2477991 2417344 2184332 2196594 2134013524288 0 0 0 0 2765538 2815727 2680232 2475892 2489487 2363456 2167403 2168217 2200495

1048576 0 0 0 0 165800 218046 197114 163000 199440 206557 203490 161932 1911352097152 0 0 0 0 104582 98053 107136 97860 98099 96519 92571 91928 102054

Page 59: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Reader Report4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384

64 6421025 7940539 7940539 7100397 2278628128 7082197 7082197 7582312 8036304 6727225 6406138256 7314033 7314033 7518900 7120034 6554972 6249745 5687020512 5115422 5509113 6472112 6736026 5951911 5639315 4973263 4375425

1024 5652717 6355328 6280976 6609617 5885083 5652717 4783849 3970183 37781012048 5596757 6225466 6340344 6075753 5785224 5406535 4957240 3960675 3757946 33040674096 4423462 4664886 4982841 5204750 4571782 4864330 3927001 3680502 3477139 3445064 31803938192 4017834 4126896 4118980 4116513 4383287 4031505 3754421 3497955 3380930 3426446 2932017 2985257

16384 4179557 4322848 4318501 4334572 4216227 4258027 3838904 3534078 3528091 3385728 2961177 2802153 296654632768 0 0 0 0 4373720 4224756 4093392 3597331 3584291 3488935 2977846 2688776 267360765536 0 0 0 0 4337816 4544202 3819138 3642320 3549935 3272402 3013126 2925203 2928975

131072 0 0 0 0 4494597 4602901 3660626 3542473 3710559 3631896 3058143 2982570 2983315262144 0 0 0 0 4551113 4761835 4370515 3734566 3767633 3660818 3102697 3022082 2856966524288 0 0 0 0 4738551 4860194 4402010 3768388 3820867 3693157 3044238 2969611 3067877

1048576 0 0 0 0 4806871 4935941 4427637 3559791 3847773 3747199 3120547 3016555 30742002097152 0 0 0 0 4820374 4501323 4424901 3802121 3819162 3557238 2844826 2719018 3004881

Re-reader Report4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384

64 10402178 12902017 12902017 12310336 9318832128 9129573 10567140 8548124 11720614 9795896 9129573256 9868433 9518507 6595234 9778562 9114515 8024634 7518900512 7647578 8528336 8265729 7435738 7211022 6821616 5822804 3659616

1024 6172653 6650556 6692005 6519323 6128613 6025439 4265934 4265934 39997622048 5689430 6696208 6670210 6563185 6075753 5754221 4490751 4122233 3999400 40541394096 5674032 6030551 6254490 6160296 5640500 5490871 4812550 3915366 3889659 3682869 31780408192 4196965 4692154 4699856 4676190 4304757 4558925 4192356 3631030 3484475 3512617 2978787 2933018

16384 4377090 4548607 4499761 4570084 4443604 4464099 4013564 3576381 3426925 3424023 2979537 2797363 294569232768 0 0 0 0 4401877 4239613 4126328 3572180 3576084 3520843 2943345 2711479 271683965536 0 0 0 0 4422685 4585210 3903306 3648992 3583534 3326176 3018420 2984338 2993862

131072 0 0 0 0 4577643 4683484 3678285 3545283 3748433 3635018 3074579 3010730 3010516262144 0 0 0 0 4624561 4830729 4433214 3739519 3813170 3674570 3124439 3049363 2922097524288 0 0 0 0 4807818 4941305 4463437 3785285 3833830 3704168 3061053 3005066 3087046

1048576 0 0 0 0 4845345 5006451 4486388 3566196 3850006 3765693 3133641 3042692 30924882097152 0 0 0 0 4869001 4552228 4483143 3821544 3827826 3555537 2858288 2733766 3032302

Page 60: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

IOzone – ext3cow Test Results

Writer Report4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384

64 752577 889704 863796 875036 926405128 927606 1007784 1057351 1031028 1057313 1007820256 1003879 1089266 1117751 1122507 1108368 1127036 1093892512 1036770 1108431 1156044 1188611 1207470 1163733 1069219 1100996

1024 1083549 1085997 1183969 1204532 1189519 1200558 1091916 1089461 11084882048 1100142 1112588 1164559 1207044 1197867 1190887 1181303 1130372 1107919 10976334096 1070069 1144349 1173023 1185177 1192317 1187265 1149621 1076349 1097716 1060255 10261728192 1043145 1097948 1137976 1130920 1166627 1171112 1124492 1089220 1083999 1060309 1021635 993605

16384 1029674 1091191 1113409 1128478 1125084 1134800 1115064 1060845 1076933 1052425 1003558 991831 99689432768 0 0 0 0 1115896 1115413 1110683 1049690 1073477 1038955 1008803 977526 98138765536 0 0 0 0 1111864 1127507 1073092 1076063 1067327 1032114 1012692 1011411 1012708

131072 0 0 0 0 562921 1127916 1055460 1065117 1080841 1073063 1019175 1013622 1014903262144 0 0 0 0 1080324 1127536 1113444 1085076 1085596 1067487 1025305 1020939 1006211524288 0 0 0 0 928171 1129639 1105471 1072087 1074129 1059961 1005405 1002793 1018686

1048576 0 0 0 0 212755 164962 164268 163886 167947 155321 165171 170261 1573782097152 0 0 0 0 96192 97804 97936 98308 96951 96850 92697 86050 92396

Re-writer Report4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384

64 2561551 1679935 3057157 2663132 2444873128 2558950 3657074 3468289 2969605 3895945 3867840256 3466100 3879144 4132985 3667186 3368114 3557982 3087457512 2996132 3159034 3481759 3459283 3550814 3393829 3264755 2739949

1024 2942286 3281755 3656077 3506663 3447815 3379893 3170188 2592492 25225642048 3094796 3117065 3502271 3358445 3057204 3430956 2980911 2691361 2645946 24098884096 2582804 2834605 2854641 2893063 2953175 2924124 2782491 2531530 2496167 2446931 22757858192 2455844 2647120 2862248 2786551 2807315 2808395 2666743 2443223 2423852 2286545 2138493 2109320

16384 2374685 2570843 2657309 2734960 2721197 2735886 2590493 2429534 2402586 2306170 2086882 2071513 211758832768 0 0 0 0 2642666 2657164 2580788 2390565 2406099 2347677 2143092 2007119 201185165536 0 0 0 0 2658390 2711476 2480040 2403574 2376856 2235542 2130515 2118373 2137445

131072 0 0 0 0 2697883 2726062 2400393 2391937 2460395 2418788 2183928 2148061 2174397262144 0 0 0 0 2697800 2803422 2680502 2482192 2478272 2417400 2184379 2196826 2134181524288 0 0 0 0 2765788 2815805 2680441 2475997 2489544 2363722 2167690 2168513 2200659

1048576 0 0 0 0 166047 218186 197129 163146 199575 206728 203743 161986 1912502097152 0 0 0 0 104747 98211 107321 98074 98339 96617 92642 91940 102165

Page 61: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Reader Report4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384

64 6421080 7940560 7940593 7100329 2278609128 7082163 7082293 7582360 8036395 6727375 6406251256 7314033 7314079 7518807 7120045 6554982 6249705 5686951512 5115444 5509020 6472192 6736164 5952011 5639221 4973403 4375391

1024 5652642 6355434 6280995 6609626 5885003 5652862 4783992 3970256 37780752048 5596878 6225534 6340264 6075684 5785358 5406439 4957180 3960678 3758087 33041464096 4423375 4664957 4982865 5204844 4571691 4864414 3927049 3680589 3477279 3445129 31803148192 4017928 4127002 4118940 4116590 4383346 4031526 3754329 3497970 3380898 3426517 2932130 2985385

16384 4179649 4322816 4318540 4334599 4216142 4258119 3839049 3534149 3528040 3385720 2961260 2802226 296668232768 0 0 0 0 4373824 4224724 4093351 3597395 3584437 3489083 2977870 2688841 267361465536 0 0 0 0 4337877 4544330 3819044 3642302 3549938 3272394 3013053 2925307 2929100

131072 0 0 0 0 4494746 4603019 3660560 3542544 3710524 3632023 3058081 2982621 2983284262144 0 0 0 0 4551053 4761735 4370430 3734600 3767638 3660946 3102680 3021991 2856978524288 0 0 0 0 4738658 4860314 4402019 3768519 3820977 3693152 3044143 2969544 3067966

1048576 0 0 0 0 4806873 4935989 4427644 3559693 3847901 3747178 3120662 3016573 30741302097152 0 0 0 0 4820347 4501304 4424964 3802124 3819239 3557355 2844938 2719056 3004796

Re-reader Report4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384

64 10402253 12902188 12902077 12310307 9318974128 9129523 10567213 8548085 11720806 9795808 9129741256 9868534 9518490 6595140 9778638 9114646 8024642 7518851512 7647515 8528511 8265750 7435716 7211214 6821556 5822774 3659696

1024 6172814 6650463 6691954 6519394 6128542 6025381 4266063 4265847 39998602048 5689619 6696287 6670126 6563159 6075873 5754297 4490930 4122182 3999400 40540724096 5673942 6030650 6254680 6160264 5640627 5490990 4812522 3915431 3889761 3682917 31779868192 4197034 4692344 4699992 4676268 4304658 4559110 4192444 3630960 3484613 3512536 2978748 2933079

16384 4377177 4548514 4499934 4570227 4443764 4464016 4013504 3576569 3426967 3424143 2979639 2797431 294576732768 0 0 0 0 4401838 4239752 4126269 3572267 3576264 3520889 2943529 2711511 271674965536 0 0 0 0 4422855 4585132 3903284 3649191 3583672 3326201 3018442 2984535 2994056

131072 0 0 0 0 4577733 4683652 3678485 3545289 3748394 3635054 3074531 3010720 3010542262144 0 0 0 0 4624721 4830748 4433334 3739635 3813220 3674693 3124590 3049388 2922282524288 0 0 0 0 4807896 4941233 4463507 3785261 3833997 3704361 3061227 3005055 3086979

1048576 0 0 0 0 4845336 5006429 4486317 3566263 3850058 3765685 3133580 3042689 30925692097152 0 0 0 0 4868931 4552188 4483133 3821701 3828014 3555444 2858243 2733702 3032444

Page 62: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

IOzone – ext4 Test Results

Writer Report4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384

64 1105556 1226821 1304314 1330167 1336792128 1373754 1440082 1539168 1539168 1521718 1637771256 1497953 1523457 1649865 1814348 1662639 1729594 1729594512 1565443 1736314 1795846 1783912 1917728 1797349 1695195 1696534

1024 1689730 1762539 1747480 1893052 1886400 1741104 1917562 1703807 17119562048 1759581 1722187 1804302 1761024 1782215 1948800 1830057 1662201 1368956 16241724096 1592526 1894600 1886694 1605624 1860943 1962560 1780148 1693965 1784030 1708113 15975618192 1748159 1795666 1878525 1923858 1933384 1913999 1814729 1751903 1685969 1636738 1584215 1488091

16384 1696785 1804617 1874364 1850441 1909998 1945360 1818033 1765124 1761188 1663514 1574156 1530200 154770732768 0 0 0 0 1864772 1933994 1779425 1760214 1769619 1633012 1652212 1616571 164126165536 0 0 0 0 1899826 1789280 1859962 1730328 1778261 1681695 1633496 1408916 1593663

131072 0 0 0 0 1883649 1892409 1861208 1772486 1746882 1707959 1574668 1608640 1586121262144 0 0 0 0 1847372 1909236 1836950 1725994 1713481 1729227 1516256 1598885 1592913524288 0 0 0 0 1837074 1809767 1802414 1719811 1760905 1715534 1356695 1422295 1558016

1048576 0 0 0 0 385536 415653 416550 448344 423589 419717 391772 424703 4682312097152 0 0 0 0 147083 142855 152174 147102 124913 140784 149144 147301 149174

Re-writer Report4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384

64 2662899 2133730 2561267 2467108 2467108128 2420455 2985839 3036502 3124872 2608629 2714132256 3017775 2935279 3043436 3511189 3236056 3935921 3245838512 3239989 3029721 3710197 2942541 3012719 2638816 3104171 2736325

1024 3092561 2632033 3055164 3366474 2844715 3210456 3335105 2236023 25341942048 3189957 2712491 3298992 2989045 3089009 2972495 3051697 2525110 2337520 24827794096 2355405 2729213 2741845 2972395 2794017 2959594 2737912 2556602 2324492 2416362 22139568192 2564962 2702765 2884511 2811347 2796929 2955217 2667514 2441743 2364938 2327926 2141620 2128881

16384 2531868 2644297 2740250 2740797 2848380 2870870 2701364 2512888 2563604 2315829 2066638 2061122 218686032768 0 0 0 0 2694944 2856123 2580586 2569634 2524325 2252403 2239192 2193169 223900965536 0 0 0 0 2787587 2636622 2706641 2494812 2525179 2412420 2257764 1848269 2208975

131072 0 0 0 0 2797642 2827266 2760403 2550730 2499233 2372133 2181658 2237637 2011143262144 0 0 0 0 2733656 2791617 2712299 2453955 2395341 2462673 2005321 2213544 2219958524288 0 0 0 0 2669531 2750911 2726024 2412215 2530947 2417901 1841274 1989843 2165601

1048576 0 0 0 0 254908 258917 267943 273901 254818 247618 251388 262429 2639052097152 0 0 0 0 131153 131641 129308 123168 120874 125648 132654 131707 134115

Page 63: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Reader Report4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384

64 7100397 4643754 7293312 4564786 5860307128 5122535 7082197 7476717 5325799 6330599 4557257256 5455847 7073132 5810112 7518900 4404088 5428265 2081678512 6491676 4411377 6571132 6931711 5684095 6414119 4701087 4000485

1024 5958564 3271594 5789881 5690162 6128613 4531485 5144870 3684119 38630552048 4376355 4552633 4550221 4864597 3982711 3690142 4414590 3637020 3304067 35250794096 4023571 3923414 4284464 4344048 4520059 4231697 3608605 3558525 3524939 3234889 32330638192 4124914 4295608 4293461 4368796 4246763 4430195 4037189 3466546 3460959 3471099 2879434 2651867

16384 4195634 4436718 4570084 4291264 4544696 4374861 3948985 3544651 3525014 3221305 2774548 2733818 291730532768 0 0 0 0 4156779 4496787 3760422 3651425 3688863 3215713 3069354 2907296 289547565536 0 0 0 0 4732517 3791481 4338364 3630390 3633845 3452381 3066129 2339310 2913761

131072 0 0 0 0 4702151 4548593 4345009 3679023 3645431 3546038 2943651 2936262 2856975262144 0 0 0 0 4378486 4672950 4271046 3550639 3451486 3584684 2672727 3024967 3018771524288 0 0 0 0 4611109 4672501 4401939 3672746 3744007 3661689 2349391 2594366 3007080

1048576 0 0 0 0 4423602 4653905 3919429 3760441 3769078 3578050 3067797 2974058 27958522097152 0 0 0 0 4273483 4745459 4332698 3632091 3691869 3530826 2788258 3028011 2707455

Re-reader Report4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384

64 7100397 7100397 6421025 7100397 7100397128 6406138 7582312 7917784 7582312 6406138 7176872256 6073004 7314033 7120034 7735574 6936061 7518900 5569035512 6086873 5019764 6319739 5822804 6319739 6909408 5384786 4271001

1024 5390231 3579719 4674510 6208343 5120336 5983467 3390391 3818408 35066512048 5416763 5238385 6058611 5131978 4276140 4751580 4751580 3690142 3757946 35869024096 4288742 4556020 4780411 4413235 4676314 4214051 4270618 3558525 3377339 3524939 30204738192 4196452 4418801 4751197 4304757 4430195 4399563 4093951 3636025 3588182 3327237 3071726 2787400

16384 4291264 4581357 4637628 4403173 4552524 4377090 4092928 3483028 3603953 3421295 2779711 2799186 285382132768 0 0 0 0 4222679 4576446 3875143 3725763 3653464 3236690 3084578 2940637 305815365536 0 0 0 0 4752400 3952018 4453425 3668227 3708061 3518896 3075632 2334324 2948612

131072 0 0 0 0 4759839 4647297 4422892 3710985 3546701 3569870 2983461 2976934 2882667262144 0 0 0 0 4436272 4742017 4366003 3548760 3489629 3633418 2691221 3046947 3043413524288 0 0 0 0 4742761 4724217 4478107 3690374 3770927 3656836 2368637 2608265 3028165

1048576 0 0 0 0 4467385 4703839 3957309 3781474 3789522 3606079 3088190 3003886 28152562097152 0 0 0 0 4308159 4811746 4405262 3624652 3694484 3532164 2805726 3044839 2719713

Page 64: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

IOzone – jfs Test Results

Writer Report4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384

64 1304314 1285575 1518251 1518251 1484662128 1526043 1622919 1618028 1684006 1521718 1618028256 1600674 1696795 1675612 1775350 1868008 1766587 1694118512 1650887 1689859 1741948 1895721 1791352 1565443 1772135 1383861

1024 1649496 1812371 1845071 1774922 1925298 1738989 1735476 1695065 16897302048 1634370 1754908 1823840 1980705 1969352 1954120 1806199 1756343 1771556 16189684096 1768603 1853514 1954077 1945007 1956971 2007977 1972927 1819553 1790911 1805213 16410538192 1721705 1857202 1926555 1988893 1774339 1991775 1967370 1722050 1780130 1740015 1648992 1579336

16384 1717737 1796502 1859252 1786508 1769897 1930278 1929357 1760962 1792005 1545202 1349032 1628624 157070132768 0 0 0 0 1100481 1930029 1907793 1756524 1770577 1691352 1621224 1603744 156097665536 0 0 0 0 1706491 1920077 1897177 1737338 1756331 1731189 1603368 1600427 1577312

131072 0 0 0 0 1900994 1927900 1884217 1768967 1762219 1722342 1601484 1593348 1301736262144 0 0 0 0 1903966 1915836 1897365 1759427 1756243 1725382 1598106 1591297 1598320524288 0 0 0 0 852375 1366899 1314475 1262979 1276114 1257547 1230613 1270917 1197800

1048576 0 0 0 0 239383 249983 234732 266528 285448 246876 280850 279691 2485202097152 0 0 0 0 138850 141491 141837 140091 140809 142628 142564 142272 141517

Re-writer Report4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384

64 3363612 3541098 4564786 4564786 4897948128 3982553 4267461 4759253 4889281 4407601 4717434256 4117018 4572895 4840911 4907284 5117791 4734192 5117791512 4163357 4660280 4784885 4916336 4660280 4061007 4305250 3259661

1024 3955557 4609294 4949226 4396951 4634161 4178773 4064103 3304314 31795592048 3931669 4257067 4481379 4971585 4611288 4550221 4031308 3292669 3210223 30387424096 3124291 3699523 4404184 3938705 3901141 3839243 3474326 3093350 2915397 3253882 30204738192 3047479 3414868 3532479 3650318 3053437 3686744 3660429 3077228 3060236 3030545 2777036 2750802

16384 3062391 3299251 3369129 3175164 3063620 3605654 3637720 3073348 3105992 2502912 1986410 2687209 268941732768 0 0 0 0 3492659 3573759 3537517 3050483 3060128 2972693 2678244 2646221 263920965536 0 0 0 0 2967168 3566794 3518536 3034782 3050037 2947284 2639280 2607682 2635055

131072 0 0 0 0 3489387 3529034 3494311 3041259 3041058 2945433 2627270 2610887 1867974262144 0 0 0 0 3486000 3515031 3476619 3027074 3038258 2929704 2611562 2605781 2597336524288 0 0 0 0 3374469 3444165 3428619 3014711 3009928 2907188 2557102 2565299 2562564

1048576 0 0 0 0 292444 283317 278035 280342 280457 272525 279284 270375 2713562097152 0 0 0 0 139903 137762 140233 140311 140419 138696 140138 140313 138924

Page 65: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Reader Report4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384

64 6421025 7940539 7940539 7940539 7940539128 6727225 7476717 7917784 8036304 6114306 6330599256 6936061 7518900 7571923 7314033 5687020 6107548 6936061512 6174377 6571132 6821616 6931711 4532414 5227492 3012719 4195896

1024 6208343 6355328 6280976 6208343 5885083 4215688 4995276 3281592 37095752048 6003564 6498636 6588354 6261772 5582208 5345969 4493100 3953383 3848872 37432074096 5490871 5728903 5818150 5818150 4899008 5025108 4735608 3800178 3806915 3631489 35220488192 4033398 4427912 4348340 4568624 3532479 5022761 4341197 3637565 3855097 3686744 3361415 3327237

16384 4754420 4547403 4844242 4263310 3768175 4860001 4572821 3853326 3834405 2990298 2224881 3144076 318694532768 0 0 0 0 4988382 4913481 4816030 3869687 3723643 3799195 2934046 3166956 318693065536 0 0 0 0 3695697 5098091 4822012 3872621 3894237 3771402 3179514 3129986 3086372

131072 0 0 0 0 4909419 5003338 4958660 3873516 3900587 3773908 3166599 3131034 2118782262144 0 0 0 0 5049496 5031173 4897867 3872367 3898800 3799518 3170285 3138585 3100571524288 0 0 0 0 4875506 5064262 4959638 3845617 3888485 3687781 3170833 3126740 3126940

1048576 0 0 0 0 4969017 3887140 4923679 3484059 3589477 3665503 2133784 3124396 31391572097152 0 0 0 0 4989774 4242849 4838391 3824199 3849878 3746425 3179454 3121616 3115555

Re-reader Report4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384

64 10402178 7100397 7940539 9318832 8182586128 9129573 10779307 11470204 3468030 6406138 6727225256 7120034 7518900 10245071 10245071 9778562 8534922 7735574512 6843354 4927617 7410080 6551087 6319739 5344582 6086873 4411377

1024 6093831 6609617 7008693 6393168 5853003 5479632 5417427 4228138 40034902048 6024617 6397004 6845629 6780783 6220958 5785224 5032754 4122233 3984558 33847884096 6049663 6468797 6703539 7249484 5835938 5704175 5461198 4047268 3540193 3571100 32275968192 4689593 5110162 5094251 4875931 3750733 5078440 4721816 3919746 3771731 3740932 2710013 3250744

16384 4747523 4979742 4882098 4543494 3806792 5136059 4939296 3808480 3838904 3066354 2195033 3189459 315446832768 0 0 0 0 4941038 5204482 5012762 3916330 3886979 3585506 3182576 3128247 318626565536 0 0 0 0 3761235 5122030 4947601 3871694 3899320 3817759 3198605 3134948 3115123

131072 0 0 0 0 4995336 5139691 5044936 3905380 3898761 3799731 3224888 3160046 2141696262144 0 0 0 0 5187677 5130621 5014514 3899906 3925133 3812561 3188516 3159917 3160607524288 0 0 0 0 4932339 5124759 5030687 3877610 3888279 3806746 3202465 3153590 3145304

1048576 0 0 0 0 5048901 3931391 5007072 3458182 3597926 3729807 2141069 3161083 31466922097152 0 0 0 0 5027092 4258599 4907984 3845656 3874932 3810288 3200463 3131648 3150257

Page 66: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

IOzone – reiserfs Test Results

Writer Report4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384

64 712397 771797 855419 809014 842003128 883293 831319 889145 969421 955616 969421256 954602 934659 1044693 995306 1062263 1057034 1040643512 982467 1003588 1046631 1082507 1096322 1082507 1086890 1042566

1024 984676 1050164 1065535 1078919 1083546 1038483 1004951 1023145 10178112048 964207 1014422 1034333 1034333 1047577 1047067 1030239 993652 990787 9106444096 846807 888914 917149 904212 918179 846974 874079 859087 904593 876353 7543368192 821496 856449 878859 880391 891793 877827 871503 854936 854490 840547 828069 713097

16384 791035 823403 844532 819984 812413 865138 839088 829226 831886 822201 795688 790735 77896632768 0 0 0 0 843883 852404 828605 815856 817583 808684 784429 784295 78377165536 0 0 0 0 822252 821448 814890 807939 805734 797652 770560 771520 695121

131072 0 0 0 0 748447 822232 806865 790857 791234 719646 751814 679703 758632262144 0 0 0 0 756653 801521 797483 780834 787758 778972 743554 750941 750911524288 0 0 0 0 582984 792978 786217 774915 765972 767753 740447 722443 730928

1048576 0 0 0 0 233118 234104 232695 229013 219538 231794 226849 228464 2275482097152 0 0 0 0 112397 111941 113151 111540 112702 107762 105076 104275 111345

Re-writer Report4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384

64 2203800 4274062 4018152 4018152 4274062128 3657016 3759450 4135958 4267461 4135958 4135958256 4132864 4332998 4572895 4819184 4264168 3654598 4350555512 3913012 3795443 4742616 4742616 4571003 4305250 3941742 3029721

1024 3712781 4451639 4507705 4762630 4433259 4570058 3579719 2993413 31701722048 4008732 4207028 4293237 4046500 4229816 3407614 4016229 3146720 3126106 25758424096 2786313 3424463 3453374 3160500 3531460 3436794 2938334 2553562 3000952 3005151 21113778192 2982148 3190080 3380930 3435010 3386595 3512617 3370979 3007468 2975692 2818958 2606405 1872383

16384 2845432 3092991 3096614 2912236 2841901 3332207 3295296 2900803 2869911 2783539 2507112 2491478 248697032768 0 0 0 0 3225221 3255936 3144422 2840246 2842243 2755678 2508430 2483905 249930765536 0 0 0 0 3137488 3197823 3107762 2811883 2824683 2698828 2478011 2471372 1835532

131072 0 0 0 0 3125302 3157523 3118389 2807400 2778427 2235463 2437187 1810540 2439631262144 0 0 0 0 3076806 3108109 3122177 2812497 2810865 2709639 2477288 2465312 2465870524288 0 0 0 0 3069007 3144009 3070593 2690078 2780983 2704161 2424395 2303590 2412781

1048576 0 0 0 0 192962 207960 202276 205183 204217 178183 188630 175321 2015352097152 0 0 0 0 107406 110141 110594 108863 100891 102053 96763 96780 105195

Page 67: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Reader Report4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384

64 7100397 9006179 7100397 4274062 6271021128 6727225 7476717 7476717 7476717 3657016 6727225256 6936061 7735574 7791708 7735574 5717301 6595234 4054829512 6174377 6931711 6909408 6821616 6414119 6086873 5439343 4305250

1024 6025439 6963241 6819511 6599461 6093831 5652717 3314514 4029784 36189302048 5900467 6563185 6867521 6670210 5800851 4162181 5319484 3871422 3624742 34417484096 4718699 6041154 6058196 5044289 4751325 4231697 4180214 3558525 3800178 3592757 24631328192 4222755 4387765 4486305 4543853 4418801 4710810 4576535 3869860 3893540 3549264 3249514 2187430

16384 4425860 4566440 4661221 4273385 3721041 4749163 4600988 3794390 3803000 3766522 3195540 3177660 318871932768 0 0 0 0 4849507 4886404 4676574 3848665 3844682 3754874 3188483 3125757 279399665536 0 0 0 0 4773196 4974642 4750018 3868696 3848493 3731063 3176574 3104954 2128562

131072 0 0 0 0 4785403 4917367 4862780 3751452 3835519 3027426 3134944 2111985 3124699262144 0 0 0 0 4852089 5030114 4709054 3845726 3885971 3781264 3163654 3118122 3109251524288 0 0 0 0 4890611 4997259 4866777 3821730 3878814 3775278 3169914 2904255 3101545

1048576 0 0 0 0 4859984 5010061 4752041 3880165 3808255 3645889 3068632 2218870 29913252097152 0 0 0 0 4887270 4329587 4728086 3823215 3867065 3730253 3069363 3132807 3139274

Re-reader Report4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384

64 9006179 12902017 12902017 10821524 10821524128 9129573 10567140 10567140 10779307 11720614 10567140256 8815202 10148242 10651598 10245071 7120034 9518507 10245071512 9145790 10694336 9510316 9145790 7647578 7211022 6156675 4271001

1024 6364746 6918376 7008693 6918376 5983467 6208343 5018624 4339202 37781012048 6359119 6873016 7311791 6939647 6202989 6225466 5884299 4213218 4112366 40162294096 6339889 6897314 7149920 6532752 6169144 5461198 5075585 3956848 4184286 3904688 25187448192 4521133 4454894 5312425 5295233 5110922 4943985 4768340 3865941 3858561 3843884 3268991 2220079

16384 4720131 4987331 4924783 4533603 3821824 5066012 4861720 3822674 3920597 3834405 3264458 3108943 309591732768 0 0 0 0 5057587 5118424 4836707 3811522 3910758 3821803 3126397 3162292 315503365536 0 0 0 0 4855573 5083101 4755853 3897274 3892142 3800288 3188143 3138384 2154590

131072 0 0 0 0 4902982 5087796 4964257 3837018 3736485 3005266 3153195 2138205 3161718262144 0 0 0 0 4960803 4985637 4736807 3905419 3905960 3812178 3181854 3143736 3153310524288 0 0 0 0 4962257 5080114 4873605 3878814 3896374 3794299 3190435 2922306 3103322

1048576 0 0 0 0 4934380 5081223 4889745 3905456 3742283 3684502 3087189 2227755 30028812097152 0 0 0 0 4939170 4364211 4799105 3875627 3868856 3738119 3087248 3147751 3147459

Page 68: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

IOzone – xfs Test Results

Writer Report4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384

64 1210227 1357066 1421755 1421755 1484662128 1373754 1598754 1455701 1637771 1749872 1732927256 1598292 1504249 1707589 1911233 1871263 1956506 1924938512 1668848 1882427 1931527 1945526 2032051 2081286 1902438 1875849

1024 1765437 1768345 2086145 2039583 2160657 2124322 2089189 1940083 19357112048 1630647 2031771 2074960 2174223 2155672 2195338 1936062 1959916 1946592 19635004096 1828656 2046975 2094134 2153727 2100535 2174170 2116840 1891055 1952300 1865186 17838458192 1794073 2008424 2094109 2150197 2207527 2225976 2092578 1967370 1959739 1890618 1768130 1735620

16384 1752117 1963087 2077321 2064776 2088750 2077321 2018204 1904440 1906237 1893891 1792566 1767621 172044632768 0 0 0 0 2118591 2049651 1953845 1869159 1881184 1815794 1621300 1615545 175370065536 0 0 0 0 2115636 2128546 2065946 1948565 1904116 1850359 1779907 1780726 1770244

131072 0 0 0 0 2109983 2125417 2060431 1940688 1961040 1914106 1753585 1763734 1768876262144 0 0 0 0 2109456 2118336 2059018 1952334 1947493 1909614 1773412 1767564 1769066524288 0 0 0 0 1977384 1987950 1865474 1695051 1694510 1795691 1711145 1692943 1696006

1048576 0 0 0 0 272816 276002 273442 269185 271083 274602 270898 268341 2723882097152 0 0 0 0 141150 139923 142279 140469 139057 140699 140545 138213 140042

Re-writer Report4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384

64 3203069 3363612 3738358 3958892 4018152128 3359523 3124872 4557257 4012317 3277486 4759253256 3654598 4197489 4477549 4652146 3935921 4332998 4332998512 3610395 2926501 4571003 4650188 2926501 4571003 3556580 2613128

1024 3631168 3646583 4694950 4410497 4228138 4654248 3103735 3220084 30551642048 3413030 4023754 3871422 4016229 4112366 3363581 3357009 3093459 2905140 27900214096 2617364 3107900 3214912 3192212 3263773 3207709 3105091 2907010 2854365 2632201 26342198192 2718805 2857404 3040737 3229054 3270236 3198692 3130212 2757425 2771437 2717945 2468229 2496020

16384 2612728 2854888 3061300 3047588 2996819 3027315 2881947 2684584 2695219 2687629 2433425 2418694 241300432768 0 0 0 0 3153440 2970573 2813903 2613662 2616001 2479379 2154390 2137071 236662565536 0 0 0 0 3172724 3171370 3070170 2807403 2725211 2615249 2443276 2436173 2441822

131072 0 0 0 0 3198527 3192750 3086005 2811075 2840927 2745939 2485852 2458494 2463198262144 0 0 0 0 3195866 3245648 3092635 2814455 2836257 2758628 2488687 2482635 2472402524288 0 0 0 0 3135786 3191741 2800312 2406457 2400476 2633936 2461217 2437031 2458526

1048576 0 0 0 0 272807 272717 277575 267622 273573 269866 272636 272277 2672802097152 0 0 0 0 139015 141948 142278 141435 140053 141917 140027 140737 142203

Page 69: Relational User Interfacecourses.cecs.anu.edu.au/courses/CS_PROJECTS/10S2/… ·  · 2012-01-03The main objective of this project was to provide the requirements and design for a

Reader Report4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384

64 7100397 7100397 7100397 7940539 6421025128 4267461 7082197 7476717 7582312 7476717 6727225256 6249745 7518900 7120034 7735574 7120034 4652146 6595234512 6491676 6821616 6821616 6999490 6821616 6571132 5509113 4262523

1024 6208343 6830356 6963241 4654248 6290174 5782087 5310258 4064103 37386362048 5447681 4559883 5056455 5920802 5290001 5416763 4321315 3542524 3696494 35675364096 4275933 4171080 4352854 4447510 4209920 3965067 3989004 3589754 3555579 3232454 32982358192 4003788 4566196 4108146 4112571 4124419 4075498 3897515 3322090 3398990 3575487 3153193 3168020

16384 4008882 4299318 4367909 4201020 4064604 4235718 3993274 3328173 3311972 3475454 3032927 3001793 308784832768 0 0 0 0 4690620 4035461 3850067 3385128 3381297 3318274 2551838 2546872 293724465536 0 0 0 0 4684768 4702963 4335832 3671657 3520428 3481899 3068182 3031971 3028196

131072 0 0 0 0 4733528 4775136 4322122 3741596 3779798 3595835 3106547 2965772 3033724262144 0 0 0 0 4875930 4777269 4431695 3768537 3794234 3698935 3138325 3079443 3078322524288 0 0 0 0 4856673 4906816 3956445 3195823 3199334 3585659 3152609 3057622 3109584

1048576 0 0 0 0 3689636 4913640 4429474 3828077 3859158 3525240 3089672 2806321 31238012097152 0 0 0 0 4876553 4400114 4474976 3829030 3848725 3776270 3174598 2624822 2788899

Re-reader Report4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384

64 6421025 7100397 4564786 8182586 7940539128 6727225 6045455 5784891 7582312 7476717 7082197256 5938650 6398720 8024634 7965107 7735574 5687020 6761355512 5566231 6035551 6652558 6319739 6156675 6736026 5886650 4228947

1024 6093831 5660167 6599461 6963241 5983467 6364746 5564829 4178773 39701832048 5820505 6097316 6359119 6207471 5670651 5489457 4330028 3960675 3864455 35854054096 4696769 4910209 5151685 4675041 4801789 4734303 4192455 3430618 3618486 3534366 31339798192 4118980 4421075 4740709 4757117 4540851 4643957 4255705 3660429 3456781 3327560 3120830 3098317

16384 4159319 4570084 4799246 4482736 4253283 4310375 4035484 3396942 3460054 3563954 3043134 3026249 305341132768 0 0 0 0 4626358 4176992 3893476 3410496 3367379 3327754 2612023 2582186 300894465536 0 0 0 0 4745180 4798359 4452487 3718797 3463473 3499364 3097187 3067292 3042811

131072 0 0 0 0 4792579 4879829 4452336 3791476 3774245 3715826 3158975 3098179 3085728262144 0 0 0 0 4935307 4929842 4459375 3796816 3722000 3732550 3162817 3112349 3103398524288 0 0 0 0 4920629 4968378 3994361 3193994 3200255 3584700 3167098 3087822 3125598

1048576 0 0 0 0 3712444 4961886 4488174 3856292 3867799 3531736 3104538 2828233 31312922097152 0 0 0 0 4916556 4441942 4536639 3841739 3856589 3779579 3188523 2648584 2801862


Recommended