Object-Oriented Analysis Models

Oracle Database Tips by Donald Burleson

Object-oriented Analysis

Object-oriented analysis starts with a traditional structured specification, and adds the following information:

A list of all objects - A list describing the data contents of each noun, or physical entities in the DFD.
A list all system behaviors - A list of all verbs within the process names such as Prepare order summary report, generate invoices, etc.
A list of the associate the primary behaviors (services) with each object - Each object will have behaviors which uniquely belong to the object. Other objects may request the behavior of the object.
A description of the contracts in the system - A contract is an agreement between two objects, such that one object will invoke the services of the other.
A behavior script for each object - A script describes each initiator, action, participant, and service.
A classification for each object and the object relationships - Generate an entity/relationship model and a generalization hierarchy (IS-A) for each object, using traditional E/R or normalization techniques.

Over the past 12 years there have numerous books about different approaches to object analysis bit they all contain these common elements. Now that we see the basic analysis requirements, let's explore the basic methodologies for object-oriented analysis.

Different Models for Object Analysis

Unlike the traditional systems analysis where user requirements are gathered and then specifications are put on the requirements and users are then asked to sign off on the specifications, the object methodologies use a more iterative process where the requirements and specifications are reviewed repeatedly and the users are heavily involved.

Object technology has many different methodologies to help analyze and design computer systems. We will review four of the more popular systems: Rumbaugh, Booch, Coad-Yourdon, and Shlaer-Mellor. In most cases these methodologies are very similar, but each has its own way to graphically represent the entities. To understand and use these four methodologies would become difficult, if not impossible, for all projects. If need be, it is possible to use concepts from one method with concepts from another technique, basically creating your own object development technique. The most important point is to remember is that the final outcome is what really matters, not the choice of one analysis technique over another technique. Remember, it is more important to do proper analysis and design to meet user requirements than it is to just follow a blind, meaningless procedure.

The traditional systems development approach is sometimes referred to as the waterfall method. By waterfall, object analyst's follow a logical progression through analysis, design, coding, testing, and maintenance. Unfortunately system development seldom fits this kind of structured approach. End-users are notorious for changing their minds or identifying some feature that they forgot to identify. These changes in requirements can happen at any phase of system development and the analyst must struggle to accommodate these changes into the system. What it means to the systems analyst is that you have to go back to whatever step in the development life cycle and make the necessary changes that will then cascade these changes through the entire system. For example, suppose that our end-users are in the testing phase when they realize that they need an additional screen. This would require a change to the initial requirements document, which would, in turn, cascade to analysis, design, and so on.

The object-oriented methodologies require a more iterative process with the same five steps. The iterative process either adds new or more clearly defines existing properties, unlike the traditional approach that would re-hash specifications that are already done. The iterative process helps to reduce confusion around what the system is really suppose to do and what the users really want. The object-oriented software development methods make the assumption that user requirements will change. However it doesn't matter which programming language you use, be it FORTRAN or C++. Furthermore, it doesn't matter which system development technique you use, you will follow the same five steps in system development. It is just, how these five steps are applied that will make the difference in your system development project.

The Rumbaugh method

The Rumbaugh method is listed first because it is these authors favorite, and we find it a very friendly and easy methodology. For traditional system analyst's, the Rumbaugh's methodology is the closest to the traditional approach to system analysis and design, and beginners will recognize familiar symbols and techniques. The Rumbaugh methodology has its primary strength in object analysis but it also does an excellent job with object design. Rumbaugh has three deliverables to the object analysis phase; the Object model, the Dynamic model, and the functional model. These three models are similar to traditional system analysis, with the additions for the object model, including definitions of classes along with the classes variables and behaviors. The Rumbaugh object model is very much like an entity relationship diagram except that there are now behaviors in the diagram and class hierarchies. The dynamic model is a "state transition" diagram that shows how an entity changes from one state to another state. The functional model is the equivalent of the familiar data flow diagrams from a traditional systems analysis.

The Booch method

Booch's methodology has its primary strength in the object system design. Grady Booch has included in his methodology a requirements analysis that is similar to a traditional requirements analysis, as well as a domain analysis phase. Booch's object system design method has four parts, the logical structure design where the class hierarchies are defined, the physical structure diagram where the object methods are described. In addition, Booch defines the dynamics of classes in a fashion very similar to the Rumbaugh method, as well as an analysis of the dynamics of object instances, where he describes how an object may change state.

The Coad-Yourdon method

Coad-Yourdon methodology has its primary strength in system analysis. Their methodology is based on a technique called "SOSAS", which stands for the five steps that help make up the analysis part of their methodology. The first step in system analysis is called "Subjects", which are basically data flow diagrams for objects. The second step is called "Objects", where they identify the object classes and the class hierarchies. The third step is called "Structures", where they decompose structures into two types, classification structures and composition structures. Classification structures handle the inheritance connection between related classes, while composition structures handle all of the other connections among classes. The next step in analysis is called "Attributes", and the final step is called "Services", where all of the behaviors or methods for each class are identified.

Following analysis, Coad and Yourdon define four parts that make up the design part of their methodology. The steps of system design are:

The problem domain component - This will define the classes that should be in the problem domain.
The human interaction component - These steps defines the interface classes between objects.
The task management component - This is where system-wide management classes are identified.
The data management component - This design step identifies the classes needed for database access methods.

The Shlaer-Mellor method

Shlaer-Mellor methodology has its primary strength in system design and is considered somewhat weak on analysis. The Shlaer-Mellor methodology includes three models; the information model, the state model, and the process model. The information model contains objects, variables, and all the relationships between the objects, and is basically a data model for the system. The state model records the different states of objects and changes that can occur between the objects. The process model is really not much more than a traditional data flow diagram.

Now that we have covered the basics of the object approach, let's take a look at how a real-world object is created by using these techniques.

��