B.2. Relationship Service Conceptual Design

Section 1 Goal

Enable the explicit representation of entities and relationships.

Section 2 Conceptual Overview

The Relationship Service allows entities and relationships to be explicitly represented. Entities are objects. Roles represent objects in a Relationship.

The Relationship Service contains a list of relationship factory objects, each of which contains relationships of a particular type. Relationships are between object instances and are dynamically created from Roles. Roles are defined as part of the description of a relationship and also contain a reference to an object instance and a name for the role instance within a particular relationship. Relationships are typically the result of dynamic system processes versus class attributes, which are part of the object's definition. Relationship types are defined by the processes occurring within a domain model. Typical relationships include owned-by, responsible-for, part-of, and member-of.

The Relationship Service introduces the concept of RelationshipFactory, which is the universe of relationship instances that share the same relationship type. A RelationshipFactory is analogous to a table, where each row constitutes a relationship instance, and every column can be regarded as a Role. Figure B.2. exemplifies this analogy.

• Type

  Related entities and the relationships themselves are typed. In the example, the Patient-Doctor relation is a relationship among two persons. The Patient and Doctor roles constrain their associated object types to the object type Person.

• The roles of entities in relationships

  A RelationshipFactory is defined by a set of roles that entities have. In the example, a person plays the role of Patient, and another one plays the role of Doctor. A single entity (i.e., Ms. Robinson) can have different roles in distinct relationships.

• Degree

  Degree refers to the number of required roles in a relationship. In the example, the Patient-Doctor relation is a degree-two relationship.

• Cardinality

  For each role in a relation, the cardinality specifies the maximum and minimum number of relationships that may involve that role. In the example, the Patient role may have a minimum cardinality of one and a maximum cardinality not specified (a doctor may take care of one or many patients). The Doctor role may have a minimum and maximum cardinality of one (if a patient can have only one primary doctor assigned).

  Figure B.2. The Patient-Doctor RelationshipFactory Analogy. Relationships can be characterized along a number of dimensions

  

• Uniqueness

  Uniqueness describes a constraint among roles in a relation that determines whether the same object name may exist in multiple roles for a single relationship. In the example, the object Dr. Garfunkel is unique with respect to a single relationship because a patient of Dr. Garfunkel cannot assume the role of a doctor and treat Dr. Garfunkel as a patient.

Section 3 Responsibilities

The Relationship Service is responsible for:

• Representing entities and relationships

• Managing the life cycle of RelationshipFactories

• Managing the life cycle of Relationships

• Providing a way to traverse to the related entities

Section 4 Architectural Level

• Foundation

Section 5 Classes and Objects, Class Semantics, and Class Relationships

The following classes support the use of the Relationship Service:

• RelationshipFactoryFactory

• RelationshipFactory

• Relationship

Relation: Contains all the Relationship instances of the relationship type that it defines. Manages the life cycle of a Relationship. Holds the constraints that a set of objects has to meet in order to participate in the relationship type.

Relation Factory: Manages the life cycle of a RelationshipFactory.

Relationship: References the related objects.

Role: Holds the constraints that an object has to meet in order to assume the role.

Role Factory: Manages the life cycle of a Role.

The following structure supports the use of the Relationship Service:

Named Object: Contains the name of the role that the object wants to assume and a reference to the object.

The scenario shown in Figure B.3 depicts the Relation Creation Process, to illustrate the interactions among the different classes in the system.

The Create Relation BPO repeats steps 1–3 for every role in the relation.

The scenario shown in Figure B.4 depicts the Relationship Establishment Process that creates a relationship instance between two objects.

Section 6 Description of Features, Data Types, and Constraints

Features

• Ability to represent entities as objects.

• Ability to represent different types of Relationships.

• Ability to represent entities participating in a Relationship as Roles.

• Ability to characterize Role constraints within a Relationship.

• Create/Delete RelationshipFactories.

• Create/Delete Relationships.

• Traverse to related objects through Relationship objects and Role constructs.

Data Types

The Roles for a Relationship are defined as a structure to decrease the overall number of objects which need to be created per relationship. Also, the definition of Role, including their constraints, and the definition of the Relationship are also modeled as structures. This is to support the expected usage pattern of retrieving descriptive information to display a set of related characteristics, as most of the values make little sense in isolation, i.e., Maximum Cardinality.

struct RoleDef {
        string roleName;
        InterfaceDefSeq allowedTypes;
        long minCardinality;
        long maxCardinality;
        boolean uniqueObjectName;
};
typedef sequence <RoleDef> RoleDefSeq;

struct RelationshipDef {
        string relationshipName;
        string relationshipDesc;
        RoleDefSeq roleDefs;
};
typedef sequence <RelationshipDef> RelationshipDefSeq;

struct Role {
        string roleName;
        string objectName;
        CORBA::Object relatedObject;
};
typedef sequence <Role> RoleSeq;

Constraints

An object must be a CORBA::Object in order to participate in a Relationship.

Section 7 How the Design Addresses Relevant Use Cases and Requirements

The design supports the following requirements stated in the Virtual Hub Requirements document.