IBM System Object Model--The Wave of the Future (and Now!)

From EDM2
Jump to: navigation, search

Reprint Courtesy of International Business Machines Corporation, © International Business Machines Corporation

By Rick Weaver

Source Code: valet10.zip

How does IBM's System Object Model (SOM) fit in the object world? What does SOM mean to you as a developer? The articles in this issue answer these questions by closely examining SOM's features and framework to show why SOM should be the infrastructure you choose for object development.

This article describes a valet parking object model, which is used by other articles in this issue. Refer to this article when reading the others.

Object-oriented analysis, object-oriented design, object-oriented databases, persistent objects, object-oriented application development... objects are everywhere!

"Objects" is certainly the buzzword of the '90s. You've probably heard about, and perhaps have been sold on, the advantages of objects and object-oriented application development. If you wade through some of the objects hype, you'll find some tangible benefits of using objects, including:

  • Improved design
  • Improved code reuse
  • Improved code maintenance

Because traditional object-oriented development uses languages such as C++ or Smalltalk, there are some inhibitors. At a high level, SOM solves the problems developers using these languages deal with daily:

  • How to share objects among different languages
  • How to distribute class libraries in binary format
  • How to enhance a class library without forcing the class library users to recompile their client code
  • How to distribute and access objects on different platforms

SOM Benefits

With SOM, you can:

  • Allow languages such as Smalltalk, C, and other languages that support SOM to use your SOM classes
  • Develop class libraries and ship only the binary form of the classes, meaning you don't have to ship your source code with a class library
  • Change a class and maintain full backward compatibility, meaning that any client application using your class will not need to recompile

SOM also provides what you would expect from an object-oriented system: objects, messages, classes, inheritance, encapsulation, abstraction, and polymorphism.

As you learn SOM, you should view SOM as an extension to the programming language you currently use, whether it be C, C++, Smalltalk, or OO-COBOL. SOM does not take the place of a language, but extends it. You gain SOM's benefits while developing an object's behavior in your preferred programming language.

The Model

Several articles in this issue use a simple object model for some of the code examples. The object model follows a valet parking system scenario, where cars are parked in and retrieved from a parking garage. The valet parking system works as follows:

A customer drives to a stadium and gives his car to the valet who parks the car in the garage and provides a parking ticket to the customer. Later, the customer returns the parking ticket to the valet. The valet retrieves the car from the garage and returns the car to the customer. All parking is free in the garage, which has a 1,000 car capacity.

The object model (in Booch notation) is illustrated in Figure 1.

Figure 1. Object Model in Booch Notation

The classes used in the valet parking application include: Valet, Ticket, Car, Garage, and TktBookS.

The Garage and TktBookS classes are internal to the Valet, and any clients using the valet parking system are not concerned with these classes.

Valet Class

An attribute is private data that will have SOM automatically generate _get and _set methods. The Valet class has two attributes:

  • valetName - a string
  • valetId - a long integer

The Valet class supports the following methods:

  • parkCar
  • retrieveCar
  • _get_valetName
  • _set_valetName
  • _get_valetId
  • _set_valetId

The two Valet methods are: the parkCar method, which accepts a Car and returns a Ticket; and the retrieveCar method, which accepts a Ticket and returns a Car.

The interface definition language (IDL) is a CORBA-compliant, language-neutral way to define a class in SOM.

The Valet class IDL is shown in Figure 2. Figure 3 shows the object interaction diagram for the parkCar method, while Figure 4 shows the object interaction diagram for the retrieveCar method.

/* Valet.idl */
#include <somobj.idl>
#include <garage.idl>
#include <TktbookS.idl>

interface Car;
interface Valet : SOMObject
{
 attribute string valetName;

 Ticket parkCar(in Car aCar);            /*parkCar method*/
 Car retrieveCar(in Ticket aTicket);  /*retrieveCar method*/
 
 #ifdef __SOMIDL__
 implementation
   {
    Garage aGarage;
    TktBookS aTicketBookSystem;

    passthru C_xh =  "#include \"Ticket.xh\""
                     "#include \"Car.xh\""
		     "#include \"Garage.xh\""
		     "#include ";
    dllname = "Valet.dll";
    releaseorder : _get_valetName, _set_valetName, _get_valetId, 	
	           _set_valetId, parkCar, retrieveCar;
    somDefaultInit : override, init;
    somDestruct : override;
   };
 #endif
}; 

Figure 2. Valet Class Interface Definition Language (Valet.idl)

Figure 3. Object Interaction Diagram for parkCar Method
Figure 4. Object Interaction Diagram for retrieveCar Method

Ticket Class

The Ticket class has two attributes: ticketNum and parkingSlotNum - both of which are long integers. It also has _get and _set methods defined for both attributes.

Car Class

The Car class has three attributes: color, make, and model - all of which are strings. It also has _get and _set methods defined for the three attributes.

Garage Class

The Garage class has one instance variable: garage_lot - a CORBA sequence. An instance variable is private data that has no _get and _set methods generated by SOM. A CORBA sequence is simply an array that will be used for storing cars. The Garage class supports the following methods:

  • storeCar
  • removeCar
  • listCars
  • getCarCount()
  • getAvailableParkingSlot
  • removeAllCars()

The Garage class IDL is shown in Figure 5 below.

/* Garage.idl */
#include <somobj.idl>
#include <car.idl>

interface Ticket;
interface Garage : SOMObject
 {
  exception carMissing
   {
    long errorCode;
    char reason[80];
   };

  const long PARKING_SPACES=1000;

  attribute sequence <Car, PARKING_SPACES> garage_lot;

  void storeCar(in Car aCar, in Ticket aTicket);
  Car removeCar(in Ticket aTicket) raises(carMissing);
  void listCars();
  long getCarCount();
  long getAvailableParkingSlot();
  void removeAllCars();

  #ifdef __SOMIDL__
  implementation
   {
    passthru C_xh_before =  "#include \"Ticket.xh\""
			    "#include \"Car.xh\"" 
			    "#include ";

    dllname = "Garage.dll";
    releaseorder: storeCar, removeCar, getCarCount, listCars, 	
	          getAvailableParkingSlot, removeAllCars;
    somDefaultInit: override, init;
    somDestruct: override;
   };
  #endif
 }; 

Figure 5. Garage Class IDL (Garage.idl)

TktBookS Class

The TktBookS class has one instance variable: nextTicketNum. The only method that the TktBookS class supports is the getTicket method.

The most interesting classes in this model are Valet and Garage. These classes contain the behavior in the valet parking system to store and retrieve cars to and from a garage.