We design the model classes of our example app with the help of a JS class model that we derive from the design model by essentially leaving the generalization arrows as they are and just adding get/set methods and static check functions to each class. However, in the case of our example app, it is natural to apply the Class Hierarchy Merge design pattern (discussed in Section 5) to the single-subclass-segmentation of Employee for simplifying the class model by eliminating the Manager subclass. This leads to the model shown in Figure 17.2 below. Notice that a Person may be an Employee or an Author or both.

Figure 17.2. The JS class model of the Person roles class hierarchy

Since we use the browsers' Local Storage as the persistent storage technology for our example app, we have to deal with simple key-value storage. For each design model class with a singular (capitalized) name Entity, we use its pluralized lowercase name entities as the corresponding table name.

We design a set of suitable JS entity tables in the form of a JS entity table model that we derive from the information design model. We have to make certain choices how to organize our data store and how to derive a corresponding entity table model.

The first choice to make concerns using either the Single Table Inheritance (STI), the Table per Class Inheritance (TCI) or the Joined Tables Inheritance (JTI) approach, which are introduced in Section 6.4. In the STI approach, a segmentation (or an entire class hierarchy) is represented with a single table, containing columns for all attributes of all classes involved, as shown in the example model of Figure 17.3.

Figure 17.3. An STI model of the Person roles class hierarchy

Since the given segmentation is non-disjoint, a multi-valued enumeration attribute categories is used for representing the information to which subclasses an instance belongs.

Using the STI approach is feasible for the given example, since the role hierarchy does not have many levels and the segment subclasses do not add many attributes. But, in a more realistic example, we would have a lot more attributes in the segment subclasses of the given role hierarchy. The STI approach is not really an option for representing a multi-level role hierarchy. However, we may choose it for representing the single-segment class hierarchy Manager-is-subclass-of-Employee.

For simplicity, and because the browsers' Local Storage does not support foreign keys as required by JTI, we choose the TCI approach, where we obtain a separate table for each class of the Person segmentation, but without foreign keys. Our choices result in the model shown in Figure 17.4 below, which has been derived from the design model shown in Figure Figure 16.8 by

Figure 17.4. A TCI model of the Person roles class hierarchy

In the case of using the JTI approach, we would also take the steps 1-5 above, but instead of step 6, we would

Compared to the model of our first case study, shown in Figure 17.1 above, we have to deal with a number of new issues in the model code:

The JS class model shown in Figure 17.2 above can be directly coded for getting the code of the model classes Person, Employee and Author as well as for the enumeration type EmployeeCategoryEL.

class Person {...}
Person.subtypes = [];

class Author extends Person {
  constructor ({personId, name, biography}) {
    super({personId, name});  // invoke Person constructor
    // assign additional properties
    this.biography = biography;
  }
  get biography() {return this._biography;}
  set biography( b) {this._biography = b;}  /***SIMPLIFIED CODE: no validation ***/
  toString() {...}
}
// add Author to the list of Person subtypes
Person.subtypes.push( Author);

Person.retrieveAll = function () {
  var people = {};
  if (!localStorage["people"]) localStorage["people"] = "{}";
  try {
    people = JSON.parse( localStorage["people"]);
  } catch (e) {
    console.log("Error when reading from Local Storage\n" + e);
  }
  for (const key of Object.keys( people)) {
    try {  // convert record to (typed) object
      Person.instances[key] = new Person( people[key]);
    } catch (e) {
      console.log(`${e.constructor.name} ...`);
    }
  }
  // add all instances of all subtypes to Person.instances
  for (const Subtype of Person.subtypes) {
    Subtype.retrieveAll();
    for (const key of Object.keys( Subtype.instances)) {
      Person.instances[key] = Subtype.instances[key];
    }
  }
  console.log(`${Object.keys( Person.instances).length} records loaded`);
}

// save data when leaving the page
window.addEventListener("beforeunload", function () {
  Person.saveAll();
  // save all subtypes for persisting changes of supertype attributes
  for (const Subtype of Person.subtypes) {
    Subtype.saveAll();
  }
});

The view table created in the use case "Retrieve/list all people" is to show the roles "author" or "employee" of each person in a special column "Role(s)".

document.getElementById("RetrieveAndListAll")
    .addEventListener("click", function () {
  ...
  for (const key of Object.keys(Person.instances)) {
    const person = Person.instances[key];
    const row = tableBodyEl.insertRow();
    const roles = [];
    row.insertCell().textContent = person.personId;
    row.insertCell().textContent = person.name;
    for (const Subtype of Person.subtypes) {
      if (person.personId in Subtype.instances) roles.push( Subtype.name);
    }
    row.insertCell().textContent = roles.toString();
  }
});

Notice that since the class Employee has the subtype Manager, it would be desirable to see the role "manager" for any person being an instance of Employee with a category value of EmployeeCategoryEL.MANAGER. However, for simplicity, this is not implemented in the model app.