Creating the Object Model Oracle Database Tips by Donald Burleson

The object model is one of the three models that is used to describe the complete logical processing in the system.  The object model will include the basic object elements, the objects behaviors (methods), the data attributes (variables), and how one object relates to another object.  The object model is essentially a graphical roadmap for the system and is an extremely useful tool for both the developers as well as the end-user community. (Figure 3.4)  An object's behaviors and variables are listed inside the object boxes, and the object relationships with other objects are designated by the lines connecting the boxes.  The object model can be extremely helpful when questions or concerns arise, because you can visually see the design for the system and how the system is constructed. 

The object model is a close cousin of the entity/relationship diagram.  In fact, the object model is sometimes referred to as an entity/relationship model with the additional constructs of classes and behaviors.  In this example, we will use the object model notation of James Rumbaugh, since these authors find it to be one of the most functional object model diagrams.  Another feature of the Rumbaugh method is that the object model is more generally associated with design, not analysis, so experienced analysts may find it strange to see this document as part of the analysis phase of systems development.

For example, if we are trying to develop an ordering system for a business it might look like the object model in figure 3.4.  This figure is an object model for Earl's Engines, a small manufacturer of engines for riding lawn mowers.

Let's examine the meaning of the symbols in Rumbaugh's object model diagram.  Starting with the rectangles, the rectangle contains three areas; the class name, the data attributes in the class, and the methods that participate in the class.

The core of the object model is the class entities.  For Earl's engines, we see the both the base classes as well as the sub-classes for the model.  The base classes include line-item, order, customer, invoice, and item.  The sub-classes include preferred, international, air_cooled, and water_cooled.  As we might guess, the line-item data attributes would be Item number, Item name, Quantity, and Price.  The class behaviors follow the class attributes, and we see that in the line-item class they are listed as add_line_item(), and delete_line_item(). 

Let's examine the nature of the lines that connect the objects.  The dark circles seen on the lines represent the many side of a one-to-many relationship.  For example, we see that there is a one-to-many relationship between a customer and an order, since a customer may place many orders, but each order belongs to only one customer.  The diamond-shaped symbols represent aggregation.  For example, we see that an order is an aggregation of many line items.  Finally, we see the triangle-shaped junction that represents sub-classes.  For example, we see that a customer has two sub-classes, one for preferred customers and another for international customers.  These sub-classes are used to show the new data items and methods that are unique to the sub-class.

Let's take a closer look at aggregation.  For example, the order-request entity is an aggregate entity made up of many line-items, but each line_item has only one order.  The diamond symbol seen on the invoice class and the object_request class  is used to denote an aggregation of a number of things (aggregations are sometimes referred to as collections, or assembles). Here we see that an order object is made up of an aggregation of many line-items plus one customer object.  An invoice is an aggregation of many line-items plus one customer object. 

Note:  We are deliberately using the terms "class" and "entity" interchangeably.  To the object model they both denote a definition of an object, and the reader should become accustomed to these synonymous terms.

The object model for Earl's Engines also represents is-a class hierarchies between classes.  We use the term is-a because that is how we specify the participation option of sub-classes.  For example, a Dodge minivan is-a van, a van is-a car, and a car is-a vehicle.  For Earl the customer class has two sub-classes, a preferred_customer and an international_customer, each with their own data and behaviors, such that a preferred customer is-a customer and a international customer is-a customer.  We also see a class hierarchy in the item object, where we see air_cooled and water_cooled sub-types for the item class.

Figure 3.4 A Rumbaugh object model for an order processing system

In short, the object model describes all of the relationships between entities, the class hierarchies that exist for each entity and the methods for each class.  Now let's move on to see how the dynamic model works with the object model to provide a more complete description of this system.

 

---