Accessing and Updating Instances of Classes in Other Schemas

At run time, an application can access instances of classes defined in schemas other than the current schema of the application, or one of its superschemas. See also "Controlling the Use of Elements in Other Schemas", later in this chapter.

This applies only to applications at run time. In the JADE development environment, methods and properties refer only to classes defined in the currently set schema or one of its superschemas.

Typically, you would use this feature to build common or generic applications in a schema that can operate on subclass instances defined in subschemas. For example, assume that we have the following schemas, classes, and relationships (shown in pseudo schema syntax).

Schema TreatmentCentreSchema
    Class TreatmentCentre subclassOf Object
        allDepartments: DepartmentDict inverseOf Department::myTreatmentCentre
    Class Department subclassOf Object
        myTreatmentCentre: TreatmentCentre inverseOf
                    TreatmentCentre::allDepartments
        allPatients: PatientDict inverseOf Patient::myDepartment
    Class Patient subclassOf Object
        myDepartment: Department inverseOf Department::allPatients
        allDetails: PatientDetailDict inverseOf PatientDetail::myPatient
    Class PatientDetail subclassOf Object
        myPatient: Patient inverseOf Patient::allDetails
    Class DepartmentDict subclassOf MemberKeyDictionary membership Department
    Class PatientDict subclassOf MemberKeyDictionary membership Patient
    Class PatientDetailDict subclassOf MemberKeyDictionary membership
                    PatientDetail

Schema XRaySchema subschemaOf TreatmentCentreSchema
    SubschemaCopyClass Department
        Class XRayDepartment
    SubschemaCopyClass PatientDetail
        Class XRayPatientDetail

Schema OncologySchema subschemaOf TreatmentCentreSchema
    SubschemaCopyClass Department
        Class OncologyDepartment
    SubschemaCopyClass PatientDetail
        Class OncologyPatientDetail

The definitions of a root class and a subschema copy class are as follows.

A root class is the uppermost definition of a class.
A subschema copy class is any copy of a class in a subschema of the schema in which the root class is defined. Subschema copy classes are added to a subschema whenever a superschema class is subclassed in the subschema or has methods added to it in the subschema.

In the above example, TreatmentCentreSchema defines the common classes and applications to run a medical treatment centre, which may comprise many departments. Each department can have many patients and each patient can have many PatientDetail objects, which are used to record department-specific treatment details and history. TreatmentCentreSchema is used to encapsulate common applications that can operate on any department and any patient; for example, billing, producing patient lists and histories, or departmental statistics. There is only ever one instance of TreatmentCentre, with each department in the centre included in the allDepartments dictionary.

TreatmentCentreSchema has two subschemas (XRaySchema and OncologySchema), which implement X-Ray and Oncology department applications, respectively. Each of these schemas has a Department and PatientDetail subclass to which department-specific properties and methods can be added. There will be one instance each of XRayDepartment and OncologyDepartment, both of which will be included in the allDepartments dictionary on the singleton TreatmentCentre object.

As inverse references cannot span schemas, all relationships between TreatmentCentre, Department, Patient, and PatientDetail are defined in the uppermost schema; that is, in TreatmentCentreSchema. You could not, for example, define an inverse from OncologyDepartment to TreatmentCentre, or the reverse. With this structure, the implementation of each department can be encapsulated in its own schema. This is useful for both development (to aid encapsulation) and deployment (where each schema could be deployed or sold separately).

The common applications that run from TreatmentCentreSchema can process any department in the allDepartments dictionary of the TreatmentCentre object, even if it is an instance of a subschema department. Typically, these applications will access only Department properties and methods, where some methods may be reimplemented in subschema departments.

If a method has been reimplemented for a particular subschema department, the appropriate reimplementation will be called (provided that the reimplementation is not on a subschema copy class).

When an application accesses an instance of a class that is not visible to its current schema, it is able to access the instance as though it can see the root class branch for that class (that is, the uppermost definition of the class and its superclasses). This means that all attributes and references are available, as well as all root class methods.

The only things that are not available are methods defined on subschema copies of the class or any of its superclasses. In our example, the XRaySchema Department class is a subschema copy of the TreatmentCentreSchema Department class. Any methods added to the Department subschema copy class in XRaySchema are not available to applications running from TreatmentCentreSchema that access XRayDepartment instances.

Any methods on a class (either new methods or reimplementations of superclass methods) that are to be invoked from superschema applications should avoid calling subschema copy class methods entirely.

If you are reimplementing a superclass method that is to be invoked from superschema applications, do not reimplement the method on a subschema copy class, as it will not be visible to the superschema. Instead, reimplement the method on a root subclass; that is, a subclass whose uppermost definition is in the current schema.