| Prev | Next | Start of Chapter | End of Chapter | Contents | Glossary | Index | Comments | (7 out of 8)

Representing Compound Objects and Workspace Hierarchies

 Physical systems typically consist of numerous systems and subsystems. For example, an assembly line might consist of several subsystems, such as the assembly subsystem, the painting subsystem, and the finishing subsystem. A robot is also a physical system that consists of subsystems, such as the arm and the sensors. Thus, your physical systems are often "part of" a larger system that represents the whole system. In object-oriented terms, an object that contains another object is called a compound object.

You represent "part of" relationships in G2 by:

This figure illustrates how you might store a list of values, text, or items, in an attribute of an object to create a subobject:


Objects with an icon representation might contain details on a subworkspace of the icon, as this figure shows:


In most applications, you have numerous workspaces, which you organize hierarchically. To do this, you create a top-level workspace that contains navigation buttons, which display subworkspaces of the application when selected, as this figure shows:


Creating Subobjects

You can create a subobject interactively in an individual instance of a class or in the class definition itself. In general, you should always create a subobject in the class definition rather than in the instance; otherwise, you will need to create a subobject each time you create a new instance.

To create an attribute of a class that contains an object:

For detailed information on creating subobjects, see the G2 Reference Manual.

Guidelines for Creating Subobjects

Numerous uses and misuses of subobjects exist, some of which are elaborated below.

Restrict the Class of Subobjects

Suppose you have a class that declares an attribute with a subobject, and you create a subclass of this class. If the class of the subobject is too broad in the subclass, you might want to restrict its class in the Attribute-initializations of the subclass.

Use Subobjects When an Object Contains but Does Not Define Another Object

Be sure you recognize the difference between subobjects and subclasses. If an object contains another object, create a subobject. In contrast, if a class inherits its definition from one or more objects, define a subclass.

The characteristics and behaviors of the resulting objects differ in important ways. For example, suppose you create a subobject and a subclass, each with the same set of attributes and methods. The difference between these objects is:

Thus, an object-subobject relationship is more limited in its knowledge than a class-subclass relationship.

Do Not Embed External Variables in Subobjects

Suppose you have a sensor on a piece of equipment and you represent the piece of equipment as a class. You might consider creating an attribute of the equipment class that contains the sensor object, thereby creating a subobject. While this approach is one way to represent reality, it does not allow you to create truly generic objects, which you can reuse throughout a large organization.

Some disadvantages of embedding sensors directly in the class definition are:

Instead, you should think of sensors as objects in their own right with relationships to equipment that you can express in a variety of ways, including:

Thus, you should describe the equipment to which sensors are attached at the class level in the most generic way possible, and you should describe the sensors on specific pieces of equipment at the instance level. To do this, you would create a simple typed attribute in the equipment class and update the attribute value based on the requirements of the specific instance. This approach provides much more flexibility for configuring individual pieces of equipment within a large application or organization.

Creating Subworkspaces

You create subworkspaces by creating a workspace for an object. You can create a subworkspace interactively or programmatically. You always create subworkspaces for an instance of a class. You use subworkspaces to implement a workspace hierarchy, described in Creating Workspace Hierarchies.

To create a subworkspace for an object:

  1. Create a master object with a subworkspace, which you create interactively.

  2. Use the create by cloning action to clone the master object with the subworkspace.

For detailed information on creating subworkspaces, see the G2 Reference Manual.

Guidelines for Creating Subworkspaces

Numerous uses of subworkspaces exist, some of which are elaborated below. We recommend using some or all of these techniques to create well-organized and well-encapsulated applications.

Create Hierarchical Views to Hide Information

One technique that supports the object-oriented principle of information hiding is to create hierarchical views of objects in your application, which are detailed views of objects. In some applications, the detail view might simply be a repository for additional information about the object. In some applications, the detail view might include a schematic that represents the physical objects that connect the higher-level objects. In this type of application, graphical connections can link objects on superior and inferior workspaces.

To support hierarchical views in which objects on the subworkspace are connected to superior objects, you can use subworkspace connection posts, which are a connection between workspaces.

To create subworkspace connection posts:

  1. Create a class definition and specify the Instance-configuration of the class follows:

  2. Create an instance of the class with stubs or connections.

    For example, to declare default stubs for the class, specify the Stubs system attribute in the Attribute-initializations. Alternatively, interactively create a connection for the instance.

  3. Create a subworkspace for the instance.

    The subworkspace contains default connection posts for each connection on the instance.

  4. Connect objects to the connection posts on the subworkspace.

Create Subworkspaces to Store Adjunct Information

 You often need a place to put adjunct information about an object. For example, you might want to:

You can create a subworkspace for any object that has an icon representation.

To create a subworkspace for an object:

Tip: To aid navigation, change the icon color of objects that define a subworkspace so that it is immediately apparent that an object has adjunct information.

Use Activatable Subworkspaces to Control Which Parts of Your Application are Active

G2 supports the ability to enable and disable entire portions of your application by using activatable subworkspaces. You can declare a subworkspace to be activatable and then activate it programmatically to control when the item on the subworkspace is enabled. For example, you might activate and deactivate a subworkspace that contains rules to implement conditional scanning.

To declare a subworkspace to be activatable:

To activate and deactivate a subworkspace:

  1. Name the object whose subworkspace is to be activated and deactivated.

  2. Use the activate the subworkspace of and deactivate the subworkspace of actions.

For more information on conditional scanning, see Avoid Scanning Rules.

Creating Workspace Hierarchies

You can create a workspace hierarchy to organize your application. A workspace hierarchy is a nested set of workspaces that allow navigation between the various parts of the application. Typically, you have a single top-level workspace per module, and you access the rest of the application from that top-level workspace.

To create a workspace hierarchy:

  1. Merge in uilroot.kb from the /utils directory.

  2. Create and name a top-level workspace.

  3. Choose KB Workspace > New Object > uil-navigation-button-template to display a submenu of button classes.

  4. Choose uil-goto-workspace-button-template to create a button that displays a subworkspace.

  5. In uil-build mode, specify the Label attribute for the button.

  6. Define a user mode anywhere in the application.

    For information on creating user modes, see Using Configurations and User Modes to Enforce Encapsulation.

    The first time you select the button in any mode except uil-build mode or administrator mode, UIL creates a subworkspace of the button object. Thereafter, selecting the button displays the subworkspace.

    You do not typically name the subworkspaces; instead, you provide labels.

  7. To create a workspace hierarchy, create as many "go to workspace" buttons as you need, on both the top-level workspace and on any subworkspaces.

  8. Create buttons of other types as needed to create a workspace hierarchy.

You typically provide close buttons (uil-hide button-template) and buttons that go to the superior workspace (uil-goto-superior-button-template) on subworkspaces of the hierarchy.

Guidelines for Creating Workspace Hierarchies

When you create a workspace hierarchy, you should try and follow these conventions.

For more information on creating workspaces, see Organizing Workspaces within Modules.

Create Only One or Two Workspace Hierarchies

Create a minimum number of top-level workspaces. If possible, organize all workspaces in a module into a single hierarchy by providing access to private workspaces from the top-level public workspace. For example, you can use the subworkspace of the version information object, or some other item, as the home for private items. Restrict the item to prevent the user from moving it, deleting it, or accessing its subworkspace.

Alternatively, you can create separate top-level workspaces and workspace hierarchies for the public and private knowledge in your module.

Name as Few Workspaces as Possible

It is good practice to name only the top-level workspace, if at all. Name other workspaces only if they need to be quickly accessible via the Main Menu > Get Workspace menu choice. Keep in mind that naming too many workspaces quickly causes the Get Workspace selection menu to get unwieldy.

Do Not Create a Large Number of Subworkspaces

You should not create an excessive number of subworkspaces or "go to subworkspace" buttons. Too many workspaces can hinder, rather than help, navigation. Also, too many buttons wastes memory.

If the number of items is too large to fit on one workspace such that the developer cannot see the entire workspace in one window, create a navigation button to access the additional features.

Identify the Top-Level Workspace

Put the module name and, optionally, version information on the top-level workspace. Use GFR's version information objects to store and present this information.

Consider Creating a Top-Level Palette

If you are creating a toolkit with a limited set of items to clone, consider using the top-level workspace as a palette. Use GFR palette tools to create palette items.

However, be aware that if you create a palette as the top-level workspace in a module that does not separate the GUI from the core, you will not be able to replace this palette with some other implementation.

For more information on separating the user interface from the core, see Separating the GUI from the Core.

| Prev | Next | Start of Chapter | End of Chapter | Contents | Glossary | Index | Comments | (7 out of 8)

Copyright © 1997 Gensym Corporation, Inc.