The starting point of our association elimination procedure is an information design model with various kinds of unidirectional and bidirectional associations, such as the model shown in Figure 1.1 above. If the model still contains any non-directed associations, we first have to turn them into directed ones by making a decision on the ownership of their ends, which is typically based on navigability requirements.

Notice that both associations in the Publisher-Book-Author information design model, publisher-publishedBooks and authoredBooks-authors (or Authorship), are bidirectional as indicated by the ownership dots at both association ends. For eliminating all explicit associations from an information design model, we have to perform the following steps:

A unidirectional association connecting a source with a target class is replaced with a corresponding reference property in its source class having the target class as its range. Its multiplicity is the same as the multiplicity of the target association end. Its name is the name of the association end, if there is any, otherwise it is set to the name of the target class (possibly pluralized, if the reference property is multi-valued).

A bidirectional association, such as the authorship association between the classes Book and Author in the model shown in Figure 1.1 above, is replaced with a pair of mutually inverse reference properties, such as Book::authors and Author::authoredBooks. Since both reference properties represent the same information (the same set of binary relationships), it's an option to consider one of them being the "master" and the other one the "slave", which is derived from the master. We discuss the two cases of a one-to-one and a many-to-many association

After replacing both bidirectional associations with reference properties, we obtain the following OO design model:

Figure 1.4. The OO design model

Compared to the unidirectional association app discussed in a previous tutorial, we have to deal with a number of new technical issues:

These six steps are discussed in more detail in the following sections.

For instance, the Publisher class from the JavaScript class model is coded in the following way:

function Publisher( slots) {
  // set the default values for the parameter-free default constructor
  this.name = "";            // String
  this.address = "";         // String, optional
  // derived inverse reference property (map of Book objects)
  this.publishedBooks = {};  // inverse of Book::publisher

  // constructor invocation with arguments
  if (arguments.length > 0) {
    this.setName( slots.name);
    this.setAddress( slots.address);
  }
};

Notice that we have added the (derived) multi-valued reference property publishedBooks, but we do not assign it in the constructor function because it will be assigned when the inverse reference property Book::publisher will be assigned.

The property checks from the unidirectional association app do not need to be changed in any way.

Any setter for a reference property that is coupled to a derived inverse reference property (implementing a bidirectional association), now also needs to assign/add/remove inverse references to/from the corresponding value (set) of the inverse property. An example of such a setter is the following setPublisher method:

Book.prototype.setPublisher = function (p) {
  var constraintViolation = null;
  var publisherIdRef = "";
  // a publisher can be given as ...
  if (typeof(p) !== "object") {  // an ID reference or 
    publisherIdRef = p;
  } else {                       // an object reference
    publisherIdRef = p.name;
  }
  constraintViolation = Book.checkPublisher( publisherIdRef);
  if (constraintViolation instanceof NoConstraintViolation) {
    if (this.publisher) {  // update existing book record
      // delete the obsolete inverse reference in Publisher::publishedBooks
      delete this.publisher.publishedBooks[ this.isbn];  
    }
    // assign the new publisher reference 
    this.publisher = Publisher.instances[ publisherIdRef];
    // add the inverse reference to publisher.publishedBooks
    this.publisher.publishedBooks[ this.isbn] = this;
  } else {
    throw constraintViolation;
  }
};

For any multi-valued reference property that is coupled to a derived inverse reference property, both the add and the remove method also have to assign/add/remove corresponding references to/from (the value set of) the inverse property.

For instance, for the multi-valued reference property Book::authors that is coupled to the derived inverse reference property Author:authoredBooks for implementing the bidirectional authorship association between Book and Author, the addAuthor method is coded in the following way:

Book.prototype.addAuthor = function( a) {
  var constraintViolation=null, authorIdRef=0, authorIdRefStr="";
  // an author can be given as ...
  if (typeof( a) !== "object") {  // an ID reference or
    authorIdRef = parseInt( a);
  } else {                       // an object reference
    authorIdRef = a.authorId;
  }
  constraintViolation = Book.checkAuthor( authorIdRef);
  if (authorIdRef && constraintViolation instanceof NoConstraintViolation) {
    authorIdRefStr = String( authorIdRef);
    // add the new author reference
    this.authors[ authorIdRefStr] = Author.instances[ authorIdRefStr];
    // automatically add the derived inverse reference
    this.authors[ authorIdRefStr].authoredBooks[ this.isbn] = this;
  }
};

For the remove operation removeAuthor we obtain the following code:

Book.prototype.removeAuthor = function( a) {
  var constraintViolation=null, authorIdRef=0, authorIdRefStr="";
  // an author can be given as an ID reference or an object reference
  if (typeof(a) !== "object") {
    authorIdRef = parseInt( a);
  } else {
    authorIdRef = a.authorId;
  }
  constraintViolation = Book.checkAuthor( authorIdRef);
  if (authorIdRef && constraintViolation instanceof NoConstraintViolation) {
    authorIdRefStr = String( authorIdRef);
    // automatically delete the derived inverse reference 
    delete this.authors[ authorIdRefStr].authoredBooks[ this.isbn];
    // delete the author reference
    delete this.authors[ authorIdRefStr];
  }
};

When a Book instance b, with a single reference b.publisher to a Publisher instance p and multiple references b.authors to Author instances, is destroyed, the derived inverse references have to be removed first (e.g., by removing b from p.publishedBooks).

Book.deleteRow = function (isbn) {
  var book = Book.instances[isbn], keys=[], i=0;
  if (book) {
    console.log( book.toString() + " deleted!");
    if (book.publisher) {
      // remove inverse reference from book.publisher
      delete book.publisher.publishedBooks[isbn];      
    }
    // remove inverse references from all book.authors
    keys = Object.keys( book.authors);
    for (i=0; i < keys.length; i++) {
      delete book.authors[keys[i]].authoredBooks[isbn];
    }
    // finally, delete book from Book.instances
    delete Book.instances[isbn];
  } else {
    console.log("There is no book with ISBN " + isbn + " in the database!");
  }
};

For showing information about published books in the list publishers use case, we can now exploit the derived inverse reference property publishedBooks:

pl.v.publishers.list = {
  setupUserInterface: function () {
    var tableBodyEl = document.querySelector("div#listPublishers>table>tbody");
    var pKeys = Object.keys( Publisher.instances);
    var row=null, publisher=null, listEl=null;
    tableBodyEl.innerHTML = "";
    for (var i=0; i < pKeys.length; i++) {
      publisher = Publisher.instances[pKeys[i]];
      row = tableBodyEl.insertRow(-1);
      row.insertCell(-1).textContent = publisher.name;      
      row.insertCell(-1).textContent = publisher.address;
      // create list of books published by this publisher
      listEl = util.createListFromAssocArray( publisher.publishedBooks, "title");
      row.insertCell(-1).appendChild( listEl);
    }
    document.getElementById("managePublishers").style.display = "none";
    document.getElementById("listPublishers").style.display = "block";
  }
};