Case study -- perspectives in visualization

Instructor's Guide

intro, components, case study, crossing boundaries, styles, platform, summary, Q/A, literature
To determine which architectural style to use, or which mix of styles, is to a large extent determined by practical experience. Nevertheless, at the end of this section, we will discuss some rules of thumb that may guide you in the choice of a particular style. However, first we will look at an example that illustrates the consequences of the choice of a particular style. The example comes from the distributed visualization architecture (DIVA) that is explained in more detail in section DIVA. DIVA is being developed in cooperation with ASZ/GAK, the largest social security provider in the Netherlands, for experimenting with business visualization to support decision making. Our case study focuses on how to support the sharing of perspectives in visualizing shared information. For example, one of the users discovers a new way to display information, uncovering aspects that would otherwise remain hidden. This new perspective must then be shared with other users to coerce them, so to speak, to this new point of view. What we will look at, here, is how the choice of a particular style affects the solution for the sharing of perspectives problem.
slide: Exchanging perspectives

Distributed objects style

New functionality can be added by creating a new object at the server. In this case, slide Perspectives(a), the user discovering a new perspective acts as the server. Then, assuming that the discovery of a new perspective is somehow announced to the other users, a user can connect to the server and request for that particular perspective (1). Then, a new visualization object is created (2), which is made accessible to the user requesting for the new perspective (3).

Downloadable code style

When a new visualization perspective is discovered, a class is created that can be downloaded by the interested user, slide Perspectives(b). The user connects to the server that contains the new visualization class (1), downloads the class, and instantiates a new visualization object (2). Finally, the information is retrieved from the shared information server and accordingly visualized (3).

Mobile objects style

Similar as in the downloadable code style, the new visualization perspective is downloaded from a server to the client, slide Perspectives(c). However, in this case, when a user requests for a new perspective (1), it is not a class, but an object, actually a clone of the object residing at the server, that is transferred to the client's machine (2). The clone, which contains all relevant information, does not have to contact the shared information server to update the user's visualization with a fresh viewpoint.

Guidelines for selecting a style

 In the DIVA system, we have experimented with all these styles. In our system, we eventually made a choice of the mobile object style for sharing perspectives, since it turned out to provide the most flexible solution. It was also the most natural solution to create display agents for managing perspectives. See section DIVA.

Nevertheless, for other parts of the system we were forced to choose a different solution. For example, since we use a C++ simulation library for obtaining the information, we had to use distributed objects (read CORBA) for making the information available. And for developing control applets, agent technology seemed to be a bit of an overkill so we restricted ourselves to plain Java technology, that is the downloadable code style.

Generalizing, from our experience we can formulate the following rules of thumb, listed in slide Guidelines.

Rules of thumb -- selecting an architectural style
slide: Rules of thumb
 Because interoperability is a key feature of distributed objects, the distributed objects style is particularly recommended for wrapping dedicated hardware or legacy software systems. Additionally, distributed objects only expose the interface and do not give away the implementation. This may be necessary for strategic or security reasons.

When a large amount of clients is running an application on a server, the server can easily become overloaded. In this case, moving the processing to the client, by deploying dynamically downloadable classes, is a natural solution. Additionally, when (parts of) an application are updated often, for example because of changing legislation, architectures based on downloadable code are much easier to keep up-to-date. Clients are then automatically using the latest version of the available software.

The latter guidelines hold for the mobile objects style as well. However, agent technology is much more complex. And there is, generally, an efficiency price to pay. So, it is reasonable to introduce agent technology only when real benefits can be expected from the migration of objects, for example when the communication and negotiation with local objects is substantial.

Concluding, we may state that the adoption of a style will often be dictated by the technological constraints a system must satisfy. Nevertheless, a word of warning is in place here. Choosing a style may well have consequences for the overall complexity of the system. Minimalism is to be strived for, in this respect. For example, adopting the mobile object style, that is the use of agents, may significantly complicate the semantics of the system, and consequently induce an increased verification and validation effort.