Relations

In C++, pointers are not appropriate to describe relations among objects. To be more specific, they do not convey semantics and do not allow you to invert a relation automatically —that is, they do not allow you to access the origin of a relation starting from its target. Server makes it possible to define in C++ the idea of a relation as supported by the object-oriented methodologies, by extending the idea of a C++ pointer as a data member. You can invert such relations. Moreover, Server lets you set cardinalities to automatically manage the minimum and maximum number of target objects in a relation.

In Server, an object can have two kinds of relations with other objects:

  • Ownership relations

  • Use relations

In either case, these relations can be one-to-one relations or one-to-many relations, also referred to as list relations. Cardinalities can be set for one-to-many relations. For example, an object can own 0 to n objects.

Ownership Relation

An ownership relation is a relation in which an object, called the owner, owns one or several other objects, called owned objects. Owned objects, or target objects, belong to one and only one owner, or origin-object.

For example, a domain owns a set of nodes. Each node belongs to a single domain. The object Domain is called the owner of the object Node.

Use Relation

A use relation is a relation in which an object, called the user, uses one or several other objects, called used objects. Used objects, or target objects, can be used by several user objects, or origin-object.

For example, a line uses two nodes (an input node and an output node). A single node can be used by multiple lines. The object Line is called the user of the object Node, that is, it makes use of the node.

Class Templates for Relations

Server provides several class templates to define relations between the objects of your model. Here are some of the class templates you can use to establish relations between objects.

For a description of these class templates, see the Server Reference Manual.

Example

The following code defines the relations between a domain and its lines and nodes, as illustrated in Model of the Network Information System with Components.

class Domain:

public IlsObject

{

public:

   ...

private:

   ...

   IlsOwnsList<Domain,Line> lines;

   IlsOwnsList<Domain,Node> nodes;

};

The following code defines the relations between lines and nodes, as illustrated in Model of the Network Information System with Components.

class Line:

public IlsObject

{

public:

   ...

private:

 

   IlsUses<Line,Node> input,output;

};

These declarations have the following meanings:

  • A domain owns nodes and lines.

  • A line uses an input node and an output node.

Class Typologies

Server objects can be classified in two categories:

  • Entities

  • Basic objects

Entities are the roots of the information system. They can be used but can never be owned by other objects. Entities have a name and can be stored in a dictionary. In our example, the object Network is an entity. Entities derive from the class .

Basic objects can be both used and owned by other objects. In our example, the objects Line and Node are basic objects. Basic objects derive from the class .

For more information on IlsEntity and IlsObject, see the Server Reference Manual.

The Importance of Relations

Relations are linked to several features implemented by Server.

  • Relation inversion: You can access the origin of a relation starting from its target.
    Relation inversion is described later in this chapter.

  • Smart pointers: Smart pointers allow for implicit deletion of objects that are no longer referenced (that is, objects that are no longer pointed to by a smart pointer). They help maintain the referential integrity of a model. Relations are implemented using smart pointers. Smart pointers and referential integrity are described later in this chapter.

  • Derived members: Creation, modification, and destruction of relations are taken into account when recalculating derived data members that depend on these relations. Derived members are described in the next section.

  • Notification: Creation, modification, and deletion of relations are events that trigger
    notification. Notification is described in the next chapter.