Defining Your Own Schema

The Schema Browser is displayed by default when you first sign on to the JADE development environment.

A schema is the highest-level organizational structure in JADE, and represents the object model for a particular domain. A schema is a logical grouping of classes, together with their associated methods and properties. These effectively define the object model upon which your applications are based.

For details about importing packages of common frameworks, see Chapter 8 of your JADE Developer’s Reference, "Using Packages".

The appearance and functionality of applications in a schema can differ, but they all share the underlying object model defined by the schema. The RootSchema is provided by JADE, and is always at the top of the schema hierarchy.

The RootSchema provides essential system classes; for example, the Object class (the root of the class hierarchy), Collection classes, and the File, Exception, and Form classes. Because these classes are defined in the RootSchema, they can be accessed from all subschemas.

When you begin developing a system using JADE, you would normally begin by adding a schema to the RootSchema and you would then define all of your classes, properties, and methods within that schema. This ensures that your object model (class hierarchy) is clearly packaged and is kept distinct from the system classes.

For larger and more-complex development efforts, a hierarchy of user schemas may be necessary to adequately represent the object model. You can add a subschema to the RootSchema. You can also add new classes to a schema, methods, properties, and constants to a schema class, or methods and constants to an existing class defined in a superschema.

In addition, you can define an interface, which provides a set of methods that are guaranteed to be available on any implementing class. When a class implements an interface, it agrees to implement all of the methods defined by the interface. With this contract in place, the implementing classes can participate in useful type-safe callback mechanisms.

Classes that implement an interface can be grouped by that interface type (for example, a collection can have a membership of a specified interface), to capture the similarities of non-related classes without the need to artificially force a class relationship; that is, you allow a class to perform multiple roles outside of the role dictated by its class hierarchy. For details, see Chapter 14, "Adding and Maintaining Interfaces".

For details about grouping methods from any class in any schema into a named workspace, see Chapter 13, "Using Method Views to Bookmark Workflows".