Types as Objects

Typically a domain model has two layers: the T-Box or meta-layer and the A-Box or base-layer. The T-Box describes the domain types and relationships, while the A-Box describes the domain members (entities, events, roles) and assertions about them. Of course the base-layer must conform to the meta-layer.

Main

Note that the base layer depends on the meta-layer, but not vice-versa.

Normally, the meta-layer consists of one or more UML class diagrams, while the base-layer consists of one or more object diagrams. However, if we apply the Types as Objects pattern, then the class diagrams of the meta-layer can be replaced by object diagrams. In this case the objects in the meta-layer are instances of more general classes like Type and Rule. This has the benefit that changes to domain types and rules can be made dynamically.

Inventory

T-Box Model

An inventory has a collection of products and has withdraw and deposit methods. The deposit method simply adds a product to the inventory:

void deposit(Product p) ...

The withdraw method removes products from the inventory:

Product withdraw(ProductDescription pd) throws ProductNotFoundException ...

A product has a unique product ID number and a product description.

A product description contains the product description and price as well as a reference to the supplier.

A supplier contains the name and phone number of the supplier.

Create a T-Box model for inventory.

A-Box Model

The Phonz-Ltd inventory consists of 3 iPhones ($700 each) and 2 Samsung Galaxy phones ($650 each).

Create an A-Box model of the Phonz-Ltd inventory.

 

1. Accountability (version 1.0)

A. Translate the following domain description into a UML class diagram. The underlined nouns should be modeled as classes. Italicized phrases should be modeled as associations. Be sure to include multiplicities and names on the end of your associations. It's probably too early to determine navigability, though.

Roles are played by persons. The important roles in a university are provost, dean, chair, and lecturer. Every lecturer is accountable to a chair. Every chair is accountable to a dean. Every dean is accountable to a provost.

B. Using the previous class diagram as a T-Box model, draw an object diagram (A-Box model) modeling the following scenario:

Lecturer Smith is accountable to chair Jones who is accountable to dean Bean who is accountable to provost Glum.

C.  Translate the diagram from A into Java or C++ class declarations. Create a test harness for your declaration based on the object diagram in B. In other words, create the objects and links that appear in your object diagram. Be sure to print some sort of diagnostic messages to make sure that your test harness is executing correctly.

2. Accountability (version 2.0)

A. Translate the following domain description into a UML class diagram. The underlined nouns should be modeled as classes. Italicized phrases should be modeled as associations. Be sure to include multiplicities and names on the end of your associations. It's probably too early to determine navigability, though.

The members of a domain are entities, events, and roles. An assertion is about two members. Every member is an instance of type. A rule is about two types. Every assertion is an instance of some rule.

B. Redo 1A and 1B as a single object diagram. We can think of 1A as the meta-layer and 1B as the base layer.

Hint: provost, dean, chair, and lecturer should be role types. A statement like "Every lecturer is accountable to a chair" should be interpreted as a rule, R. In this case the statement "Lecturer Smith is accountable to chair Jones" is an assertion that instantiates rule R.

C.  Translate the diagram from A into Java or C++ class declarations. Type and Rule classes should each contain a makeInstance method. This method creates an appropriately typed instance of the type or rule. If rule R is about types t1 and t2, and if subject and object are members of the domain (base layer), then 

r.makeInstance(subject, object)

should return an assertion A about the subject and object only if the type of subject is t1 and the type of object is t2. Otherwise, it should throws a "type mismatch" exception.

How can you prevent users from bypassing makeInstance and simply constructing mistypes members?

Create a test harness for your declaration based on the object diagram in B. In other words, create the objects and links that appear in your object diagram. Be sure to print some sort of diagnostic messages to make sure that your test harness is executing correctly. Also be sure to test that type mismatches are caught.

D. Bad news, Provost Glum has decided to re-organize the university's chain of command. Henceforth, deans will be accountable to vice presidents who will be accountable to provosts. Dean Bean will now be accountable to vice president Agnew who will be accountable to provost Glum. What modifications do you need to make in version 1.0 of your model? What about version 2.0?

3. Chain of Command

A. Translate the following domain description into an object diagram that conforms to the class diagram from #2A.

Meta-layer: Roles are played by persons. The important roles in the army are general, captain, lieutenant, and private. Every private is accountable to a lieutenant. Every lieutenantis accountable to a captain. Every captain is accountable to a general.

Base-layer: Private Glum is accountable to lieutenant Bean who is accountable to captain Jones who is accountable to general Smith.

B. Replace the test harness from #2C with a new test harness based on #3A.

C. Bad news, General Smith has decided to re-organize the army. Henceforth, privates will be accountable to sergeants who will be accountable to lieutenants. Private Glum will now be accountable to Sergeant Bilko, who will be accountable to Lieutenant Bean. What modifications do you need to make in your model? What about version 2.0?

4. Polymorphism

Assume privates, sergeants, lieutenants, captains, and generals can execute an operation called fight. Of course asking a general to execute fight invokes a different method that the method invoked when a private is asked to execute fight.

Extend the model developed in #2A and implemented in #2C so that every instance, t, of Type has a virtual function table (vft). When an instance of t is asked to execute an operation, it asks t to search its vft for the method to be invoked.

Test your implementation on the fight method described above.

5. Organizational Hierarchies (version 1.0)

A. Translate the following domain description into a UML class diagram. The underlined nouns should be modeled as classes. Italicized phrases should be modeled as associations. Be sure to include multiplicities and names on the end of your associations. It's probably too early to determine navigability, though.

Department, Office, League, Team, Division, Conference, Batallion, Corporation, etc. are examples of organizations. An organization can be the subsidiary of another organization.

B. Using the previous class diagram as a T-Box model, draw an object diagram (A-Box model) modeling the following scenario:

The Oakland Raiders and the Kansas City Chiefs are teams in the Western Division of the American Conference of the National Football League.

C.  Translate the diagram from B into Java or C++ class declarations. Create a test harness for your declaration based on the object diagram in B. In other words, create the objects and links that appear in your object diagram. Be sure to print some sort of diagnostic messages to make sure that your test harness is executing correctly.

6. Organizational Hierarchies (version 2.0)

A. Redo #5A and #5B as a single object diagram instantiating the class diagram from #2A.

B. Replace the test harness from #2C with a new test harness based on #6A.