Definition: One concept inherits all the properties of another concept, similar to Java, where a subclass inherits all the properties of the superclass that it extends. You can define a hierarchy of inheritance, where each concept in the hierarchy extends the concept above it.
Concepts that are related to each other directly or indirectly by inheritance cannot have distinct properties that share a common name. Therefore, the following restrictions apply:
Also, BusinessEvents does not allow you to create an inheritance loop; for example, if Concept A inherits from Concept B, Concept B cannot inherit from Concept A.
At runtime, a rule on a parent concept also affects all its child concepts. For example, suppose the concept Coupe inherits from the concept Car. A rule on Car is therefore also a rule on Coupe.
Definition: One concept is contained inside another concept. You can define a hierarchy of containment, where each concept in the hierarchy is contained by the concept above it.
The relationship is defined using a ContainedConcept property in the container concept.
See Table 9, Containment and Reference Concept Relationship Rules for rules governing the behavior of concepts linked by containment or reference. The table also helps you to choose which is the appropriate type of relationship for your needs.
The following example illustrates some of the rules that are listed in Table 9. To configure a concept Car to contain a concept Wheel, you add a
ContainedConcept property, Wheels for example, whose value is an instance of the concept Wheel. The Wheels property provides the link between the container and contained concept:
Car (Concept)—Wheels (property)—Wheel (Concept)
However, the contained concepts—Wheel, Door, and Engine—cannot be contained by any other concept type. They can only be contained by the Car concept. For example, the concept Wheel cannot be contained in the concept Motorbike, if it is already contained by the concept Car.
Definition: One concept references another concept. A concept that is the target of a reference can itself refer to one or more other concepts. Reference relationships are not, however, hierarchical.
The relationship is defined by a ConceptReference property in the referring concept.
See Table 9, Containment and Reference Concept Relationship Rules for rules governing the behavior of concepts linked by containment or reference. The table also helps you to choose which is the appropriate type of relationship for your needs.
To configure a concept Order to reference a concept SalesRep, you add a ConceptReference property, Rep for example, whose value is the ID of concept SalesRep. The Rep property provides the link between the referring and referenced concepts:
Order (Concept)—Rep (property)—SalesRep (Concept)
Order (Concept)—BackupRep (property)—SalesRep (Concept)
Order (Concept)—Lines (property array)—LineItem (Concept)
Order (Concept)—Cust (property)—Customer (Concept)
Customer (Concept)—Orders (property)—SalesRep (Concept)
This section presents the rules governing designtime and runtime use of containment and reference relationships. By comparing the rules, you can decide which type of relationship to use an a particular case.
|
|
|
One referring concept (that is, the concept that has the ConceptReference property) can have a reference relationship with multiple referenced concepts, and a referenced concept can also refer to other concepts.
|
A container concept can link to a contained concept using only one ContainedConcept p roperty. (Some other object oriented languages do allow you to reuse object types in parent object properties.)
|
A referring concept link to a referenced concept using multiple ConceptReference properties. (That is, multiple ConceptReference properties can reference the same referenced concept.)
|
|
|
|
When one contained instance is replaced with another, BusinessEvents deletes the instance that it replaced automatically. You do not have to delete the replaced instance explicitly.
|
When one referenced instance is replaced with another, BusinessEvents does not delete the instance that it replaced automatically. It may not be appropriate to delete the referenced instance. If you want to delete the referenced instance, do so explicitly.
|
When a contained instance is modified, the container instance is also considered to be modified. The reasoning can be seen by a simple example: a change to the wheel of a car is also a change to the car. Rules that test for modified instances would return the Car concept instance as well as the Wheel concept instance.
|
When a referenced instance is modified, the referring instance is not considered to be modified. The reasoning can be seen by a simple example: a change to the support contract for a customer is not a change to an order that references that customer.
|
When a container instance is asserted or deleted, the contained instance is also asserted or deleted, along with any other contained instances at lower levels of the containment hierarchy.
|
When a referring instance is asserted or deleted, the referenced instance is not also asserted or deleted.
|
This section highlights an important difference in behavior when history is tracked for an array property, and when history is not tracked, or the property is not an array.