When the Facilities Manager updates the floor layout in the site editor and commits the updated layout to the database, the database will announce (via the notification sytem) that the layout has been altered. The Visualization subsystem, for example, will react to that notification by retrieving a new copy of the layout and rebuilding its VRML model.

In addition, the Database group will provide a minor subsystem which will retrieve weather forecast data from the Internet and store it for later retrieval. This subsystem will behave as a client in two client/server relationships. The first relationship is between a weather information server and the subsystem. The subsystem will query that server and retrieve a weather forecast. The second relationship is between the subsystem and the database server. The subsystem will store the retrieved weather forecast in the database by calling a public method on the Database Subsystem.

Summary of Communication Relationships

Figure 2.1.1: Communication Relationships between the subsystems. The tail represents the client side of the relationship and the head the server side. A two-headed arrow indicates a peer-to-peer relationship

2.1.1 Layers & Partitions

Figure 2.1.1.1: Control Subsystem Structure

The Control Subsystem depends on the Database Subsystem for the default and user defined lighting levels. The Facility Management subsystem depends on the Control Subsystem for maintaining the required levels. The Control Subsystem depends on the User Interface Subsystem for the new lighting levels. The Database Subsystem depends on the Control Subsystem for providing it with the new lighting levels that originated from the User Interface Subsystem.

The Database team is responsible for two subsystems, the Database Subsystem and the Weather Forecast subsystem. The layering of the Database Subsystem is as follows:

• The Interface Layer (light blue) consists of all public methods on the Database Subsystem. This object uses CORBA to interface with the rest of the OWL system. This includes accepting requests as well as providing notifications of data triggers.
• The Implementation Layer (green) consists of implementations of the public methods and a Bridge Object to interface with the database engine. This layer is subdivided into two layers and four partitions.
• Method partitions are not strictly partitions, but a combination of partitions and layers which enable the desired functionality of the subsystem.
• The Query partition implements the query method of the subsystem. It may return tags of the data items which match the query, or it may read each data item and return the items directly.
• The Read partition handles a read of a specific data item as described by a unique identifier.
• The Write partition handles a write of a specific data item as described by a unique identifier or a new data item. It must go through the Lock Mechanism first.
• Lock Mechanism partition implements write locks to maintain consistency on very specific data items under special circumstances.
• The Bridge Object is a design pattern which allows the underlying implementation of the database engine to change without effecting any other part of the database system. In the future, if mSQL is found to have insufficient performance, a different database could be added or used instead. The only subsystem modifications would occur in the Bridge Object.
• The Database Engine Layer (red) includes the chosen database engine an any support code required to keep it running properly.

The layering of the Weather Forecast subsystem is as follows:

• The Interface Layer (light blue) consists of a CORBA interface which allows the subsystem to write to the database.
• The Implementation Layer (green) consists of a Bridge Object to interface with any weather information service.
• The Weather Information Service Layer (dashed grey) is any specific weather information server. A specific example is sprl.umich.edu.

Figure 2.1.1.3: Facility Management Subsystem Structure

The FMS depends on the existance of the database server, and will await the return of the database server, should that server ever be unreachable.

Figure 2.1.1.4: Notification Subsystem Structure

The Notification Subsystem does not depend on any other subsystem. However, if there are no other subsystems then Notification has nothing to do. It is a basic service for all other subsystems.

This subsystem is simply an interface added on top of existing code. It has yet to be determined whether that existing code will be an implementation of the COSS Event Server created by Iona or a notification subsystem used for the JEWEL System.

Figure 2.1.1.5: Simulation Subsystem Structure

The Simulation subsystem is an interface to external simulators. Currently there are only two existing simulators (called NODEM and CASCADE). The only subsystems which are depended on by the Simulation Subsystem are the Site Editor which allows changes to be made to the model that is used in the simulation and Database which provides the models for the simulation.

Figure 2.1.1.6: Site Editor Subsystem Structure

The Site Editor Subsystem depends on both Simulation and Facility Management. The models which are edited through Microstation are provided through those two subsystems.

Figure 2.1.1.7: User Interface Subsystem Structure

The User Interface Subsystem depends on Visualization to determine the location of the user when they are using the 3 Dimensional Interface.

Figure 2.1.1.8: Visualization Subsystem Structure

The visualization subsystem dempends on two other subsystems. It depends on the Database Subsystem for the object model of the Intellegent Workplace, and User Interface subsystem for user input. At the same time, the User Interface Subsystem depends on visualization to tell it when a user enters/leaves a room.

2.1.2 System Topology

Data Flow Diagram

Example Scenario:
The Liquid Reality browser sits upon a graphics library and the java virtual machine. Inside when the user requests to view the three dimensional model, several stubs are called. One will be dedicated to the walls, one to the furnature, etc., decomposing the system by parts of the Intellegent Workplace model. Each of these stubs connect to a geometry server which keeps a cached copy of the current model in memory. The geometry server checks the database periodically and re-caches the model if it has changed. If the model has changed in the database, the geometry server calls a thread to generate the VRML text for the objects requested by the client. If the model hasn't changed, the geometry server sends the cached VRML representation of the requested objects back to the client.