1 SCOPE
1.1 PURPOSE
1.2 DEFINITIONS, ACRONYMS, AND ABBREVIATIONS
1.3 REFERENCE DOCUMENTS
1.4 DOCUMENT OVERVIEW
2 OVERALL DESCRIPTION
2.1 SYSTEM PERSPECTIVE
2.2 SYSTEM FUNCTIONS
2.2.1 CLIENT-SERVER ARCHITECTURE
2.3 USER CHARACTERISTICS
2.4 CONSTRANTS
2.5 ASSUMPTIONS AND DEPENDENCIES
3 SPECIFIC REQUIREMENTS
3.1 EXTERNAL INTERFACE REQUIREMENTS
3.1.1 USER INTERFACES
3.1.2 HARDWARE INTERFACES
3.1.3 SOFTWARE INTERFACES
3.1.4 COMMUNICATION INTERFACES
3.2 FUNCTIONAL REQUIREMENTS
3.2.1 ADMINISTRATION, SESSION AND DATA MANAGER (ASDM) CSCI
3.2.2 COLLABORATIVE VISUALIZATION ENVIRONMENT INTERFACE (CVEI) CSCI
3.2.3 INTERACTION AND COLLABORATIVE MANAGEMENT (ICM) CSCI
3.2.4 SCIENTIFIC VISUALIZATION ALGORITHMS (SVA) CSCI
3.3 PERFORMANCE REQUIREMENTS
3.4 DESIGN CONSTRAINTS
3.4.1 STANDARDS COMPLIANCE
3.5 SOFTWARE SYSTEM ATTRIBUTES
3.5.1 RELIABILITY
3.5.2 AVAILABILITY
3.5.3 SECURITY AND PRIVACY
3.5.4 MAINTAINABILITY
3.5.5 PORTABILITY
3.5.6 SAFETY
3.5.7 TRAINING-RELATED REQUIREMENTS
3.5.8 PACKAGING REQUIREMENTS
3.5.9 LEGAL REQUIREMENTS
3.6 OTHER REQUIREMENTS
This specification establishes the functional, performance, and development requirements for Release 1 of the Collaborative Visualization Environment (CVE).
Scientific visualization is the process of using computer graphics to view or explore 3D objects, natural phenomenon, or complex data. It has proven to be very useful to many areas of science and engineering. Collaborative visualization enhances the traditional visualization by bringing together many experts so that each can contribute towards the common goal of the understanding of the object, phenomenon, or data under investigation. There are many applications in science, technology and engineering which can benefit from collaborative visualization. Medical consulting is one such application. Similarly, geographically scattered engineers may be able to collaborate, design, analyze, and evaluate a prototype through a common engineering data visualization system.
There are several generalizable reasons why a collaborative visualization environment is compelling. First, at any given time, the input of an expert in the field of science where guidance of the visualization process is necessary can be accessed. Second, a side effect of the previous point is that this expertise is transferred to others, improving the local level of knowledge. Third, with the input of remote colleagues readily accessible, visualization products can be reviewed and modified as they are produced, reducing turn around time. Finally, access to remote expertise can help to minimize the need for physically relocating that expertise locally.
Due to the nature of the collaborative visualization process, we feel that any system developed for it should contain the following features:
CVE Collaborative Visualization Environment
CSCI Computer Software Configuration Item
SRS Software Requirements Specification
GUI Graphical User Interface
Administration, Session and Data Manager (ASDM) CSCI
Collaborative Visualization Environment Interface (CVEI) CSCI
Interaction and Collaboration Management (ICM) CSCI
Scientific Visualization Algorithms (SVA) CSCI
The following standards apply:
Section 1 identifies the scope of this document, the purpose of the software, and the lists of definitions, acronyms and reference documents. Section 2 provides an overview of the system, and a description of the functional architecture. Section 3 identifies the two main Computer Software Configuration Items (CSCIs) that comprise the system, and gives the functional requirements and constraints for each CSCI. Section 3 also describes the quality requirements for the software. There are no appendices.
Traditionally, the visualization process consists of a cyclic progression of filtering raw data to select the desired resolution and region of interest, mapping the result into a graphical form, and producing an image, animation, or other product. The result is evaluated, the visualization parameters tweaked, and the process run again. The CVE application should provide visualization capabilities in a collaborative context. This environment will provide a level of shared control over the visualization process.
Figure 1: A simple collaborative visualization environment in which an image product is viewed by multiple participants.
In its simplest form, a collaborative visualization environment consists of image data rebroadcast to all participants, as shown in Figure 1. Only the individual creating the image(s) has direct interaction with the visualization process. The other participants are limited to passive viewing of the results. Feedback might be exchanged between participants via a telephone conference call, or by means of audio, video, and whiteboard teleconferencing software.
A more complex variation is represented by environments in which participants can share data from any step in the visualization process. Direct interaction and control over the visualization process occurs locally, but raw, partially, or fully processed data can be shared.
Figure 2: Colormap data is intercepted by the collaborative module share colormap, which propagates the data to the respective share module of other participants.
These modules are designed to augment the capabilities of an existing visualization sytem to support collaborative behavior in a flexible manner. One characteristic of the modules is their ability to intercept data at key points as shown in Figure 2, and broadcast the data to the respective modules on the hosts of the participants.
Another category is represented by applications in which participants can share the viewpoints of others, and insert items into this shared view. Cooperative control of the visualization process is primarily limited to annotation of the resulting visual elements, and control of the view position.
Other collaborative visualization environments are those that provide shared control over the parameters associated with a given visualization. These parameters may affect how a dataset is filtered, mapped to graphical elements, viewed, and aspects of the products output. Thus the work of steering any aspect of the visualization process can be a shared activity.
Figure 3: The collaborative module share geometry shares the value of the isolevel dial widget in the menu of the isosurface module connected to it, with the respective isosurface module of other participants.
In this context, a change in the value of any parameter in the module directly upstream of a collaborative module (see Figure 3) is broadcast to the respective modules in the AVS networks on the hosts of the participants. There it is used to update the respective upstream parameter.
Collaborative visualization environments can be further categorized by the way in which they evolved. Some begin life as visualization packages, and are later extended to support collaborative behavior. Developmental issues including limited access to the underlying event model of the original visualization software can restrict the scope of the collaborative behavior available in these environments.
Other environments are built from scratch with collaboration in mind. This type of system often provides focused visualization capabilities as a result of limited development resources, or targeting a specific audience. Thus one challenge to the user is to find a system with suitable collaborative and visualization capabilities.
Further, fundamental collaborative capabilities are often insufficient to enable participants to carry on a natural level of interaction with one another. In many cases traditional audio, video, and whiteboard teleconferencing software provide an indispensable component of the collaborative session.
Developers of Collaborative Visualization Environments are confronted by challenges resulting from necessarily coordinating the activities of multiple simultaneous users. Throughout development, all instances of the environment in a given collaborative session must be treated as a coherent whole. For this reason, many of these challenges are akin to those faced by programmers of multiprocessor computers. Three of the most significant include maintaining the coherency of shared data across multiple users, synchronizing the activities of these users, and optimizing for network bandwidth and latency.
Shared memory multiprocessor computers are systems in which main memory is globally addressable by all processors. Often each CPU is also equipped with a small amount of local cache memory. Thus one issue is how a given processor can guarantee that a cached value of a global variable is current, since at any time another processor could update this variable in main memory. In other words, the problem is how to guarantee that everyone has the same value of a global variable.
This issue is similar to the problem of maintaining the coherency of data shared across multiple participants in a collaborative session. Many environments handle this by tracking the current state of the shared data, and initializing new participants with this state. An order of execution is then enforced that prevents an update from overwriting the current state until previous updates have been propagated to all participants.
The actions of multiple processors in a parallel computer must be coordinated to avoid contention for shared resources. So too, developers of collaborative environments must synchronize the activities of multiple participants to avoid contention for shared items.
Synchronization can take the form of explicitly regulated access to shared parameters and data. Often visual cues are provided to each participant to denote local control or lack thereof over a shared item. For example, explicit synchronization to share control over the view position in a coordinated manner. Keyboard commands are used to gain and release control of the view. Only the participant currently in control can release the view. All participants are notified of changes in the state of their access.
Synchronization can also occur implicitly on a first-come first-served basis, relying on the assumption that participants will conduct themselves in a civilized manner. Parameter changes are sequentially serviced by the collaboration server in the order in which they are received.
Just as the overhead of interprocessor communication can reduce the efficiency of applications on parallel computers, so network bandwidth and latency limitations reduce the ability of physically remote users to interoperate effectively. Responsiveness in a collaborative environment is often no better than the slowest participant's link to the collaboration server.
The developer can do little directly to improve bandwidth. However the effects of limited bandwidth can be ameliorated by carefully selecting the type of data to share between collaborators. For example, broadcasting changes in the parameters that control how a dataset is visualized generally requires considerably less bandwidth than broadcasting changes to the actual dataset.
Alternatively, bandwidth requirements can be reduced by compressing, downsampling, or cropping the shared dataset.
Finally, prediction and culling schemes can help to reduce the aggregate number of messages sent between collaborative servers and clients. In the case of prediction schemes, the sending client attempts to predict the value of a rapidly changing variable (based on the range of values, rate, and number of changes), periodically updating the current state of shared data based on these predictions.
In the case of culling, either the sending client, or the server itself may regulate the propagation of a given message based on the degree to which it changes the current state of shared data. When a participant makes a change to the local user interface, the scope of the change is examined. Based on this analysis, no message, a small message containing an incremental update, or a larger message containing a full update of a shared entity is sent to the session manager for rebroadcast.
The similarities between the issues associated with developing collaborative environments and programming multiprocessor systems suggest that innovative solutions might be borrowed from the body of work already done in the area of parallel computation.
This specification describes essentially a network-based interactive scientific visualization viewer that allows collaboration between multiple users. The architecture described here includes a client-server model that allows for more than one colleague to collaborate over a network.
There are essentially four main functional areas, which correspond to the four CSCIs in section 3:
Figure 6: Example representations of 2D scientific visualization algorithms.
The architecture is summarized in Figure 7.
Figure 7: The System Architecture.
The client-server model allows the collaborative visualization environment to be used over the network, with collaborators and colleagues distributed on different systems. For each session, there would be one server, and one or more clients.
Implementation of the client-server architecture is independent of the implementation of the CSCIs, and should be considered an integration issue. Each CSCI provides a set of functions to be used by the other CSCIs. Integration of the CSCIs into client-server architecture can be achieved by providing a wrapper for the CSCIs that adds a communication protocol to connect the functional interfaces provided by the CSCIs.
No special knowledge or skills should be assumed on the part of the users. Users should not be expected to learn a set of commands in order to start using the CVE. Users shall not be expected to remember a list of commands while using the software – these shall be provided via menus, tool palettes, or help screens. Users shall be protected from data loss.
Users should not be allowed to make invalid moves, but should not be restricted in looking at the visual images.
No special constraints have been identified.
It is assumed that the requirements described in this document have different levels of priority. Although no specific priorities have been documented, it is assumed that software contractors may need to scrub low priority requirements in the face of schedule and resource pressures. Requirements should only be scrubbed by agreement with the customer, and only if it can be clearly demonstrated that there is no other high priority (non-scrubbed) requirement that depends upon the scrubbed requirements.
No other special assumptions or dependencies have been identified.
All interaction with the user is via the Client CSCI. The interface provided by the Client may be graphical or textual, but must give a display of the entire view after each move. A user starts by running CSCI, which makes contact with the server to request a viewing. The Client keeps the user informed of the moves and of users who have joined the conference, and coordinates which user has control at what time. If the user enters a badly formed command, then the system shall report that the command was not understood. If the user attempts to make a move out of turn, then the system shall report that they currently do not have control. The system should provide another method of communication to enhance collaboration.
All interaction with the user shall be via the CVEI CSCI. The interface provided by the CVEI may be graphical ortextual. The interface shall always give a view of the current visual image. If the current visual image is too large to display on the screen, the CVEI shall display part of it, and provide controls for scrolling to the hidden parts. The CVEI shall also provide a mechanism for zooming out, to allow the user to see the entire visual image in a single view (without necessarily seeing all the detail). The CVEI shall also provide an interface for saving and printing visual images. It shall also provide a warning if the user attempts to overwrite an existing file. For ease of use, the CVEI shall allow the user to browse the file system when saving files, and the CVEI shall remember the name and location of the last file opened.
None.
The system shall make use of the operating system calls to the file management system to store and retrieve files containing visualization data and images. Platform independence and portability requirements are described in section 3.5.5.
The client-server architecture provides a network interface and communication protocol, allowing the user interface to be run remotely from the server. None of the CSCIs provide any direct access to the network. This is an integration issue.
This section describes the functional requirements for each of the four CSCIs: Administration, Session and Data Manager (ASDM), Collaborative Visualization Environment Interface (CVEI), Interaction and Collaboration Management (ICM), and Scientific Visualization Algorithms (SVA).
This CSCI shall provide a web session manager and a data manager for CVE, which shall be used by the other CSCIs. The administration manager will provide a web based interface to creating user accounts, sessions, and access rights. The session manager will provide a method of starting, stopping, joining, leaving, and browsing the collaborative visualization environment. The data manager will provide a web based interface for the storage and retrieval of remote visualization data. The ASDM will provide the other CSCIs with functions to authenticate users and access visualization data.
The main internal data used by the ASDM shall be the session identification number, the visualization data associated with this session, and a list of those authorized to this session.
The ASDM CSCI provides the following functions for external use by other CSCIs:
This CSCI shall provide a Graphical User Interface (GUI), to allow the user to monitor/steer visualizations and collaborate with participants. If the visualization to be displayed contains layout information from the collaborative process, the CVEI shall use this information to arrange the visualization on the screen; otherwise CVEI shall provide a new layout. The GUI shall provide functions to the user to rotate, transpose, scale visualizations. It shall call the ICM to request floor control, moderation, and instruction modes. It shall also provide access to general commands such as saving a visualization as an image, or printing a visualization.
The main internal data used by the CVEI shall be the floor, control mode, moderator, visualization states, and GUI states.
The CVEI CSCI provides the following functions for external use by other CSCIs:
This CSCI shall provide a collaborative tool like a whiteboard and/or a chat tool and the management of the collaboration, which shall be used by the other CSCIs. A collaborative visualization environment must address many issues such as synchronization, latecomers, management or moderation, floor control, and awareness. Among these, floor control is perhaps the most primary issue without which a collaborative session won’t function properly. In short, floor control ensures that only one person at a time controls the collaborative visualization environment. Without floor control, there will be collisions of events, which leads to unwanted results in the shared application. For a specific environment, most developers prefer an “intuitive” implementation of the floor control capability; i.e., as soon as the user tries to interact with the application, the client automatically asks for floor control and allows or disallows its user to interact. After the user is finished, the client releases the lock automatically. This approach is in contrast to the “direct” approach, where a client must specifically ask for control, for example by pressing a "control-request" button. Although floor control addresses the issue of event collisions, it works on a firstcome-first-serve basis. This in turn leads to the possibility of a participant to abuse or disrupt the session by feeding unwanted events into the session. There is therefore a need to have a moderator in order for a session to be more productive, for example, a teacher moderating a distance learning session. The moderator is usually the person who calls for a collaborative session and starts the server. Finally, we may not want participants to have any floor control, for example, an instructor giving a lecture.
The main internal data used by the ICM shall be the floor, control mode, moderator, and collaborative states.
The ICM CSCI provides the following functions for external use by other CSCIs:
This CSCI shall provide the methods for visualizing and manipulating the data. This CSCI will provide funjctions to be called by the CVEI to produce the vtkPanel that CVEI will place in the CVE. For example, contours, raised surfaces, and deformed sheets.
Figure 8: Example representations of 2D scientific visualization algorithms.
The main internal data used by the SVA shall be the visualation method, visualization states, and visualization data.
The SVA CSCI provides the following functions for external use by other CSCIs:
The system should respond to each user input within 2 seconds. In case of use over a network, the user should be informed of any network delays. If the visualization will take more than a few seconds, the user shall be warned of this, and given a progress indicator. There are no other performance requirements.
All images used should comply with current University of Alaska guidelines for decency and equal opportunities. Usage of the CVE on University of Alaska equipment shall be governed by the current guidelines of computer usage.
The system should never crash or hang, other than as a result of an operating system error. The system should provide graceful degradation in the face of network delays and failures.
There are no specific availability requirements.
Data security should be well taken care of via passwords, query restrictions and data encryption etc to make sure only authorized people can access data. Additionally, the requirements of those governing student login accounts at the University of Alaska computer equipment must be observed.
All code shall be fully documented. Each function shall be commented with pre- and post-conditions. All program files shall include comments concerning authorship and date of last change. The code should be modular, to permit future modifications.
The software shall be designed to run on at least one of the following four platforms:
No other specific portability requirements have been identified.
The system should warn the user to take a break after two hours of continuous use to prevent eyestrain and repetitive strain injury. No other safety requirements have been identified.
No specific training should be necessary for a user to begin to use the viewer. The collaborative visualization environment should provide a brief guide on use the system when first invoked, before the first command prompt.
The system shall be packaged along with source code and all documentation, and shall be available for electronic transfer as a single compressed file. The uncompressed set of files shall include a README file containing a minimal guidance for installing and running the software, including recompilation if needed. If recompilation is necessary during installation, the system shall include a makefile.
Copyright laws and license agreements must be respected for any third party software used in the creation of this system.
There are no other requirements.