Database Object Analysis and Design Oracle Database Tips by Donald Burleson

The object technology approach to problem solving has several important differences from traditional data processing systems.  The first and most important is the absolute necessity of proper analysis before implementation.  The rules have changed. For example, some of the fourth-generation languages are designed to allow the developer to create their system in an ad-hoc fashion, building screens and database tables without any formal forethought. 

Using this type of approach with object-oriented development is dangerous.  While a properly designed class hierarchy will have very low maintenance, it is not easily modified in an object-oriented environment, especially after persistent objects have been created.  Great care must be taken to properly identify the classes, and the relationships between the classes, and all one-to-many, many-to-many, and ISA relationships must be properly identified.  Most object technology systems do not lend themselves to class modification after coding has begun, and caution must be taken to insure that the initial design is correct.

Object-oriented vs. Traditional Analysis

In software development, there are three main parts:  analysis, design and programming.  Analysis deals with understanding the user requirements and how these user requirements can be met using the appropriate computer technology.

In many cases, systems analysis and design are done poorly and as a result, a system never reaches its real potential.  Maintenance on these systems is always high, and the budget for these systems is always going through the roof because the infrastructure for the system was not properly described.  It seems that many companies want results quickly and the first thing they skimp on is the effort required to perform a complete analysis and design.  Many times what happens is that a system is developed in a vacuum, instead of analyzing how the system will interface with other systems and what will be needed to establish proper interfaces.  In almost all cases, this approach leads to high maintenance costs and slower system development time. 

Many companies have found that while they could get away with a poor analysis and design, proper system analysis and design are an absolute necessity for object databases. (Figure 3.1)

Figure 3.1 The resources used in systems development methods

As an example, think about all of the thousands of hours of work that is required to modify systems to keep them running when the year 2000 gets here.  With proper system analysis and design, much, if not all of this work would not have to be done.  Let's face it, to save a couple of bucks and a little time, many companies used a two digit year instead of a four digit year.  As a result they are now spending billions of dollars to change legacy systems whose life span might only be a few years after the year 2000.  There is no substitute for doing it right the first time.

As we know, in software development there are three major activities; analysis, design and programming.  (Figure 3.2)   Traditional systems use the approach that when a change is needed, they modify only that which is necessary.  Object-Oriented development uses a different approach.  Object-oriented requires a well defined plan before any systems construction may be undertaken.  Regardless of whether you use the traditional approach or the object-oriented approach the gains from doing a "quality analysis" are monumental.  With proper analysis & design, there are many benefits of the object-oriented approach:

• Customers get better systems at less cost.

• Projects are done on time.

• Systems organizations and companies become more competitive.

• Maintenance for these systems is lower.

• Changes can be made to systems faster and with less cost.

Figure 3.2 A high level overview of systems development

One of the basic distinctions between traditional systems and object-oriented systems is the initiator for the processes.  Object-oriented systems are event-driven, and unlike traditional systems where a process is triggered by the change to a data item.  But how does an analyst shift from thinking about systems in the traditional way to thinking about systems as a collection of interacting objects?  To understand the answer, let's take a look at object behavior analysis.  Object behavior analysis is a new method which contains the following steps:

1. Identify a hierarchy of behaviors for the entire system.

2. Identify the "primitive" behaviors, and create a behavior hierarchy.

3. Identify all objects which exhibit the behaviors, and create a class hierarchy.

4. Associate each primitive behavior with each object class.

The first step is to be able to identify the objects.  When isolating the physical objects within the structured analysis document, it is tempting to focus on the nouns within the diagram, and assume that all "things", which represent physical objects, should be modeled as objects.  While this is true, this approach often ignores the intangible objects which have a tremendous bearing on the system. 

The best approach to understanding a system in object-oriented terms is to change the focus from data flows to object behaviors.  Behaviors are events which are generally associated with verbs, such as "Create Order Form", or "Print Service Request".  To properly identify all of the behaviors within a system, it is necessary to take a very top-down approach to system behavior.  At a highest level, the overall system can be said to have a behavior, although it is often quite difficult to give the system a meaningful behavior name.  Often, entire systems can be labeled with names like "Process Inventory", or "Manage Personnel Records", but it is critical to the development of the object-oriented system to clearly identify each component of the system within a behavioral context.

Now that we understand the basic approach and benefits of object-oriented analysis and design, let's move on to discuss some of the more popular approaches to object database development.

 

---