Object Modeling: Data Models with Behavior


While data normalization was going on in a formal way, the logic of the programs was being "normalized" in a much more informal manner. Once upon a time, programs owned their data, such that there was often one big program for each sequentially organized data file. But since the advent of the database, and the ability for multiple programs to update shared data, we have been dealing with the problem of keeping those updates consistent.

Object Modeling

Object-oriented development involves designing your objects in a process called object modeling. The basic process is a conceptual modeling approach, with one difference: In object modeling you are simultaneously modeling the data and the behaviors allowed on the data (Figure 5.11).

click to expand
Figure 5.11: Object model in a unified modeling language (UML) class diagram.

The "class" is the basic building block of object-oriented design and is a product of the observation that good design packaging follows from modularity. Good modularity emphasizes the following:

  • High cohesion—Attributes and the code that accesses them are packaged close together.

  • Data hiding—Classes do not know the internals of other classes, and communicate through public methods.

  • Loose coupling—Objects interact only through public methods, and therefore there is a known set of side effects if something is changed.

In this example, the key classes are Customer, Order, and Product. In the UML class convention we show the attributes (data) in the top half of the box, and the methods (behavior) in the bottom half.

Object-Based Systems

Objects are instances of classes, created (instantiated) by making a request of a class to create a new object. So the equivalent of a row in a relational database is an object or an instance in an object-oriented implementation.

However, these features alone create only what has been called objectbased systems and not object-oriented systems. It is the addition of inheritance and polymorphism that gives the approach its power and appeal, and also has led to widespread semantic abuse.

Inheritance

Inheritance is a feature that allows the developer of a class to extend the features of an already defined class. The new class inherits attributes and methods from the existing class, which can then be added to.

Figure 5.12 shows an inventory system with a class called Product, which has information about items in the warehouse. After this inventory system was created, the company began dealing in perishable items—parts that have a specific shelf life. So you look at the Parts class and realize that it has most of what you need. It has a part description, a part number, a serial number, methods to issue and receive it, methods to move it to a different location in the warehouse, methods to allow a cycle count, and so on. It has attributes to keep track of the cost of the item and a reference to pricing information.

click to expand
Figure 5.12: Object design in UML with inheritance.

So all you need for your perishable item is a "use by date." This implies that you will need a method to set this date at receipt time, and you may want to change your picking routines to look for and pick first any items that are closest to expiring.

To accomplish this, you use "inheritance" and say "Class PerishableItem ‘isa’ Product." What this means to the system is that any time you ask for a "new" (new();) PerishableItem you will get all the attributes of Part plus all those of Perishable in a single object, with all the methods of both available.

start sidebar

Inheritance: Object-Oriented Programming versus Artificial Intelligence

Object-oriented programming languages and various artificial intelligence (AI) subdisciplines each use "inheritance." However, the two uses are distinct enough to cause considerable confusion. In each system, inheritance means that the child item is a subtype of the parent. The difference is that objectoriented languages create static subtypes. A class inherits from another class at design time, and the new class is compiled and linked as a subclass of the parent. When an instance of the subclass is created, it is an instance of the subclass and of the parent class at the same time. Instances do not change their classes or types during their lifetime.

In most AI disciplines, including ontology building, the inheritance or "isa" relationship is dynamic. As soon as we declare an instance "isa" type, it is of that type (in addition to any other types it "is").

end sidebar

Polymorphism

Polymorphism (literally "many shapes") allows you to treat all the descendants of a class as if they were items of that class. So any method that worked on Product should also work on PerishableItem because PerishableItem is a Product.

This allows you to extend a system without breaking it. So the "onHand();" method on Product might work exactly the same for PerishableItem, because it was inherited unchanged, whereas the "value():" function may return a value, just as in Product, but that value may be $0 if the item has passed its expiration date.

Object/Class Modeling

In summary, object modeling, or class modeling, is an exercise in trying to define a set of concepts that will work well together in your domain and be easy to extend.

In Pursuit of Reuse

Object-oriented design has been caught up in the attempt to foster code reuse. It was believed that reusing code was the Holy Grail of productivity, and that the inheritance feature of object-oriented design could be used to facilitate this reuse. As a result, class libraries became places to put code to "reuse," as opposed to letting the goal of extensibility drive the design. This didn't lead to very good designs, and paradoxically didn't deliver on the reuse. Well-designed object systems used delegation (sending a message to another object) far more than inheritance, and therefore there wasn't any measurable reuse. I use the term measurable reuse because in the late 1980s and early 1990s one of the metrics for object-oriented systems was the degree of reuse, and reuse was measured by inherited reuse (if you reused code from a parent class, you received "reuse" credit; if you reused code from an existing class, via delegation or any other pattern, it did not show up on the reuse metrics). The idea of code reuse through inheritance has fallen out of favor.

Limits to Inheritance

For the aforementioned reason, and several others, rookie object-oriented developers all seemed to overdo inheritance in their conceptual models.

Many of these were inspired by examples in textbooks that used biologic analogies (human is a primate, primate is a mammal, mammal is an animal, etc.). Unfortunately, good inheritance trees are rarely found outside of biology. The reason they work so well in biology is that all the classes and phyla descended from a common set of ancestors, by gradual accretion of features and adaptation. So the fact that we can "inherit" our warm-bloodedness from our mammalian ancestors, and our bipedalism from the primates, is mostly because that is how biologic organisms evolved.

Object-oriented design teams often construct large, deep inheritance graphs for the objects in their domain. In general this makes their designs brittle in precisely those places where designers had hoped it would make them flexible.




Semantics in Business Systems(c) The Savvy Manager's Guide
Semantics in Business Systems: The Savvy Managers Guide (The Savvy Managers Guides)
ISBN: 1558609172
EAN: 2147483647
Year: 2005
Pages: 184
Authors: Dave McComb

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net