Schemas
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.
JADE provides the RootSchema, which is always at the top of the schema hierarchy. The RootSchema provides essential system classes; for example, the
You can add subschemas 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.
For details about defining user-defined schemas, see "Defining Your Own Schema", in Chapter 3. See also "Controlling the Use of Elements in Other Schemas", later in this chapter.
A sample schema hierarchy is shown in the following diagram.
The schema hierarchy is analogous to a class hierarchy, and similar terminology is used. For example, A1 and A2 are subschemas of A, while A is a superschema of A1 and A2, in the above example.
Subschemas inherit all of the classes, methods, and properties that are defined in their superschemas. Thus, in the above example, schema A1 would have access not only to its own classes but also to those defined in A and the RootSchema. However, schemas on separate branches of the hierarchy (for example, A1 and A2) cannot "see" each other at all unless you use packages to expose functionality across the schema hierarchy. If you do not use imported packages, no part of A1 is directly accessible to A2, nor any part of A2 to A1. (See also "Packages", later in this chapter.)
As well as adding entirely new classes to a schema, you can also add methods or constants to an existing class defined in a superschema. For example, schema A might add methods to the
When you begin developing a system using JADE, you would normally begin by adding a subschema to the RootSchema and you would then define all your classes, properties, and methods within that schema. (For details, see "Defining Your Own Schema", in Chapter 3.) 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.